Novinky z testerské komunity: Pro[Test] a Průvodce testováním

Poslední rok byl v komunitě testerů obzvláště rušný a nabitý událostmi. Pořádala se řada setkání profesních test manažerů, test analytiků a testerů (vím o několika desítkách jen v Praze) plus každoroční konference CzechTest. A to jsou pouze ty akce, o kterých vím a kterých jsem se v řadě případů účastnila.

Jsem ráda, že mohu říct, že jsem z části k tomuto přispěla i já:  

• Nejdříve jsem uspořádala dvě setkání test manažerů a dalších příznivců testování v pražských hospodách (Testing pub).
• Na to jsem se seznámila se skupinou test manažerů, kteří na začátku roku 2013 začali pořádat organizované tématické diskuze o testování softwaru a sdílení know-how nazvané pro[Test] (Profesionální Testeři nebo taky "pro testování"). 
• Poté jsem začala s kolegou Petrem Roudenským psát knihu o testování, která vyšla koncem listopadu: Řízení kvality softwaru: Průvodce testováním.
• Zúčastnila jsem se opět CzechTestu, kde jsem měla s Mirkem Rendou prezentaci o využití klikačů v ČSOB. (Pozor, klikač není ještě tester. Netestuje, ale pouze kliká podle scénářů). (Prezentaci najdete v sekci ke stažení.) Nyní už se blíží další ročník konference CzechTest, která bude 26.- 27.6.2014
• A když k tomu přidám práci na projektech týkajících se NFC technologií a hektickém novém občanském zákoníku, byla jsem velmi šťastná, že si na chvilku odpočinu na mateřské.

Více o pro[Test]u

Jedná se o setkání lidí, kteří se zabývají testováním softwaru, zejména test manažerů, ale pořádají i akce pro začínající testery. Kdokoli se může přijít podívat a seznámit se s kolegy z jiných firem. Pokud hledáte informace o tom, jak jsou na tom s automatizací testů v jiných firmách, s jakými problémy se potýkají, jak řeší anonymizaci dat nebo jaké zkušenosti mají s off-shoringem, právě tyto věci se na pro[Test]u řeší.
Pokud máte dotaz nebo hledáte radu, jak řešit nějaký problém, předneste ho na pro[Test]u a zdarma získáte názor několika desítek zkušených test manažerů.

Naopak na akcích protestu nejsou firmy prodávájící své služby nebo nástroje, jen banda lidí, které testování opravdu zajímá a baví natolik, že tomu věnují i svůj volný čas po pracovní době.  

Účast na akcích je vždy zdarma, společně se sice skládáme na občerstvení nebo občas na pronájem prostor, příspěvek je ale dobrovolný a často anonymní, takže nikdo se nebude zajímat, zda jste právě vy přispěli, nebo ne.

Kromě diskuzí test manažerů na konkrétní téma se pořádají i akce, kde si můžete vyzkoušet testování v praxi. Společně si pak cvičíte vytváření test casů, testování a reportování chyb. Nebo se můžete zúčastnit jen mojí nejoblíbenější části a to je povídání v hospodě. Se starými i novými známými pak můžete řešit cokoli Vás zajímá.

Stránky pro[test]u najdete zde nebo na Google plus.  

Více o knize o testování

K projektu psaní knihy mě přizval Petr Roudenský, který hledal spoluautora a přestože jsme se do té doby neznali, slyšel o mě a narazil i na můj blog. Společně jsme vedli řadu diskuzí o testování a co by mělo být v jednotlivých kapitolách. Snažili jsme se vytvořit praktického průvodce celým procesem testování, který by srozumitelně a přesně popisoval praktiky a zákonitosti testování.

Na obsah knihy se můžete podívat zde.
Pokud hledáte něco do své knihovničky nebo do firmy pro nováčky, věřím, že tato kniha bude to pravé.

O Méďovi a testování na mateřské

Syn Medard Havlíček se narodil 14.2. a předevčírem (29.4.) se mnou absolvoval svou první "konferenci" o testování: Pro[Test] Special.    

Nadále tedy zůstávám aktivním účastníkem komunity testerů, poskytuji konzultace, rady a diskutuji s ostatními test manažery. Momentálně zároveň pracuji na něčem novém, čím bych přispěla k rozvoji testování softwaru.

Co si stáhnout a přečíst o testování v roce 2013?

Zde najdete nové materiály o testování softwaru, šablony a další pomůcky, protože v tomto článku Vám přináším to nejlepší, co jsem v minulém roce napsala, přečetla nebo připravila pro sebe, své studenty, testery, test analytiky a test manažery. Všechny odkazované materiály najdete rovněž v sekci ke stažení.

Příručka o testování a tvorbě uživatelské přívětivosti
První materiál, který bych doporučila, není mým dílem, ale výjimečně podařenou bakalářskou prácí od Bc. Filipa Knoppa, který velmi dobře vysvětluje jednotlivé aspekty uživatelské přívětivosti i toho, jak uživatelskou přívětivost testovat. Tento materiál by si měl přečíst každý tester, test analytik, programátor nebo analytik zabývající se zejména weby, ale i jinými aplikacemi určenými pro širokou veřejnost.

• Příručka o testování a tvorbě uživatelské přívětivosti (BP) 

Vysokoškolské práce najdete k dispozici volně ke stažení na stránkách dané vysoké školy. Jejich kvalita se různí a často v nich narazíte na nekvalitní a zavádějící informace, stejně jako na výborné odborné práce, které vykazují rozsáhlé zkušenosti a znalosti. Vyhledávat a stahovat vysokoškolské práce můžete například zde:

• Práce publikované na VŠE
• Práce publikované na Karlově Univerzitě
• Práce publikované na ČVUT

Nové poznatky o testování a kvalitě SW

Další dva materiály Vám představí zajímavé nové poznatky o testování softwaru. Tyto poznatky vycházejí z nově publikovaných informací a průzkumů. Není tam tedy nic, co by jste slyšeli již 10x na nějaké konferenci nebo něco, co by jsi někdo vymyslel na základě vlastních zkušeností. Jedná se pouze o podložená fakta a navíc zbrusu nová!

• Prezentace z konference CzechTest 2012: "Does Software Quality Matter? Theory Versus Practice"
• Vnímání testování a kvality softwaru v českých softwarových společnostech (článek v angličtině)

(Bohužel obojí je v angličtině, ale i pokud jste s tímto jazykem na štíru, zkuste se mrknout aspoň na prezentaci. Google Vám při překladu jistě pomůže.)

Co otestovat: seznamy testovacích nápadů pro testery a test analytiky

Pro testery a test analytiky jsem začala vytvářet seznamy testovacích nápadů. Zatím mám pro Vás jen obecný seznam nápadů na otestování webové aplikace. Tento seznam vznikl jako 15 minutové cvičení, které jsme dostali za úkol na jednom tréningu Bug huntingu. (Byla to taková trochu soutěž, kde se mi podařilo objevit nejvíce chyb a vyhrát krabici sladkostí. :)  Aspoň jsem si trochu odpočinula od Test managementu a osvěžila svoje testovací dovednosti.)

• Seznam nápadů pro testování webové aplikace

Plánuji připravit ještě další seznamy, např. na otestování textového pole, celočíselného pole, objektu osoby (objekt s jménem, rod. číslem, adresou). Tyto seznamy později dodám do tohoto příspěvku i do sekce ke stažení.
  

Šablony pro test manažery
Pro test manažery jsem v průběhu minulého roku zveřejnila jednoduchou šablonu test plánu a test reportu, kterou běžně používám při výuce testování nebo řízení kvality softwaru nebo menší projektíky:

• Jednoduchý test plán pro malé projekty
• Jednoduchý test report pro malé projekty

Přeji hladké, úspěšné ale i zábavné testování!

A pokud máte taky nějaké dokumenty, o které by jste se chtěli podělit, tak pošlete! 

Arsenál manuálního testera

V současné době existuje velké množství lehce dostupných nástrojů pro testování softwaru. Automatizované, ať už funkční nebo zátěžové testy, by dokonce bez nástrojů nemohly existovat. Bezpečnostní testování se rovněž neobejde bez různých nástrojů, které se nacházejí v arsenálu bezpečnostních testerů. Jaké nástroje a pomůcky ale může používat tester ke zvýšení efektivity své práce při manuálních testech? Co vše může pomoci ke zrychlení a zkvalitnění těchto testů?

Smyslem testování je získávat informace o kvalitě produktu. Jaké informace si přeje zákazník či manager získat ohledně kvality výrobku, to určuje cíle testování souhrnně označované jako testovací mise. Mise tedy určuje, co je cílem konkrétního cyklu testování. Dejme tomu, že manager hledá odpovědi na otázku, zda je produkt připraven na nasazení. Konkrétně ho zajímá, jaká je chybovost jednotlivých modulů aplikace, nakolik jsou splněny požadavky a jestli produkt obsahuje nějaké závažné nedostatky.

V této situaci bude seznam cílů obsahovat následující body:

-  odhadnout chybovost jednotlivých modulů aplikace

-  zkontrolovat soulad aplikace s požadavky

-  pokud existují, tak najít závažné chyby bránící nasazení aplikace

Jasná definice cílů umožní testerovi zaměřit se na ně a zpracovávat úkoly s efektivnějším vynaložením úsilí a času. Jinými slovy nenechat se rozptylovat činnostmi, které rovněž mohou být součástí testování, ale cílům současné mise nepřispívají vůbec nebo méně než kdyby tester vynaložil svůj čas jinak. Znalost a porozumění cílům testování je tedy nástrojem k lepšímu řízení vlastních zdrojů.

Protože při tvorbě efektivních testů a hledání chyb je pro co nejlepší výsledek důležitý důvtip a kreativita, je vhodné mít po ruce vždy alespoň jednu pomůcku pro jejich povzbuzení. Mezi jednu z nejspolehlivějších pomůcek patří seznam už dříve použitých zajímavých nápadů nebo testů, které v minulosti často odhalily nějakou chybu. Tento seznam se označuje jako heuristika a je součástí know-how testera.  Heuristika slouží jako studnice nápadů a inspirace, která může pomoci objevit velké množství chyb ve velmi krátkém čase. Tester si přečte jeden dva nápady, a i když třeba na současný produkt nejdou přímo aplikovat, inspirují ho k tomu, podívat se na software z pohledu, který ho předtím nenapadl. Tester začne přemýšlet způsobem: „Hmmm, co by se asi stalo, kdyby došlo k tomuto.“

U manuálního testování tester často narazí na chybu, u které je obtížné najít podmínky, za kterých je chyba vyvolána. Pro usnadnění hledání těchto podmínek se používají různá zařízení pro sledování činnosti uživatele. Ty mohou mít podobu softwaru zaznamenávajícího stisky kláves a kliknutí uživatele spolu se snímáním obrazovky nebo třeba webové kamery namířené na monitor a klávesnici. Ve složitějších případech, kdy výpis logu testerovi z nějakého důvodu nevyhovuje nebo není dostupný, je užitečné se vyzbrojit nějakým nástrojem pro sledování interních stavů aplikace, například vypisujícím zásobník volání.

Nástroje sledující akce uživatele využívají testeři nejen k odhalení podmínek vyvolání chyb, ale taky ke sledování chování budoucích uživatelů například při testech uživatelské přívětivosti.

Při testování toho, jak se aplikace vyrovnává s chybovými situacemi, kdy narazí na neočekávaný problém, často ruční zadání problematických vstupů nestačí. V tomto případě je potřeba použít nějaký nástroj k vyvolání chybových stavů uvnitř aplikace. Takovýto simulátor chyb je velmi užitečný například při testování více vláknových aplikací. Tam může docházet k problémům typu race condition, kdy dojde ke špatnému zpracování sdílených dat. Problémy, které nejsou vyvolány přímo zadáním neočekávaných dat, může tester bez vhodného simulátoru chyb jen těžko vyvolat. Je třeba tedy použít pro konkrétní aplikaci vytvořený nástroj nebo provést některou z technik odborného pročítání kódu.

V některých situacích má tester za úkol provádět i takzvané testování bílé skříňky, kdy je mu k dispozici ke zkoumání i zdrojový kód aplikace. V takovém případě se mu na internetu otevírá celá škála volně dostupných nástrojů založených na inspekci kódu. Tyto nástroje jsou určené spíše vývojovému týmu pro hledání obvyklých chyb. Pokud by se však tester ocitnul v situaci, kdy by bylo efektivní tyto nástroje využít, byla by škoda na ně zapomenout a buď chyby neodhalit, nebo je odhalit jiným časově náročnějším způsobem. Tyto nástroje dokáží odhalit špatně inicializované proměnné, nedostatečné ošetření vstupů, ale některé z nich se specializují například na bezproblémový chod webových stránek na různých prohlížečích.

Zejména v případě nedostatku času pro otestování aplikace mohou být užitečné nástroje simulující více méně náhodné klikání myší a vyplňování textu. Tester může takový nástroj spouštět při odchodu z práce a druhý den ráno jen kontrolovat, jaké chyby nástroj objevil a reportovat je. Takové testování zkušeného testera nemůže nahradit, ale může být užitečnou a levnou pomůckou, která je volně dostupná na internetu často i se zdrojovými soubory.

Arsenál nástrojů a pomůcek testera v boji, jehož cílem je nalezení chyb a určení kvality produktu, může být rozsáhlý. Výše zmíněný přehled je jen drobnou ukázkou, že nástroje patří i do manuálního testování. Je škoda, pokud si tester svoji výzbroj nerozšiřuje a netříbí. Jestliže existuje způsob, jak okamžitě zvýšit produktivitu testera, je to právě použitím nějaké vhodné pomůcky. Tyto nástroje nemají známé konkrétní zástupce, jako tomu bývá u automatizovaných testů, kdy většina lidí v oboru názvy konkrétních předních nástrojů zná. Testeři sice u některých skupin nástrojů vědí, že takové pomůcky existují, ale v situacích, kdy je možné využít předností těchto nástrojů, volí často zbytečně časově náročnější a nevýhodnější metody. To je jeden z důvodů, proč jsou někteří manuální testeři a testovací týmy výrazně efektivnější než jiné.

Tester by se tedy rozhodně neměl bát věnovat čas na seznamování se s novými nástroji a přístupy, které mohou zvýšit jeho výkonnost. Snaha o zlepšování svého vzdělání, pokud není na úkor aktuálních pracovních výkonů, je určitě ve všech softwarových firmách vítaná.

Vybavení testera/ test analytika:

-          Připravený seznam testovacích nápadů (univerzální nebo dle typu softwaru)

-          Freenástroj pro rychlou automatizaci funkčních testů či přípravu dat (např.Selenium)

-          Nástroj na nahrávání obrazovky do formy videa (Můžete si stáhnout nějaký freeware nebo je dobré použít webkameru)

-          Nástroj pro náhodné testování dané aplikace (lze jednoduše vytvořit, máte-li seznam objektů, nebo pokud je umíte identifikovat)

-          Validátory HTML, XML, ...

-          Nástroj pro automatickou inspekci kódu

-          A další nástroje dle zaměření testera a typu dané aplikace  

Vybavení test manažera:

-          Šablona test plánu

-          Sada metrik pro různé příležitosti (např. pro měření kvality softwaru, účinnosti testovacích technik nebo testování, postupu oproti plánu)

-          Šablona reportu pro projekt manažera

-          Sada motivačních historek a myšlenek pro zapamatování si toho, co je skutečným cílem a pro hledání nových způsobů zlepšování kvality, pokud nemáte takové prostředky, jaké byste potřebovali.

-          Seznam otevřených otázek a úkolů

-          Nástěnka s aktuálními informacemi o termínech, plánu a výsledcích

  

Ekonomické principy testování – proč testovat, co a jak dlouho

Tento týden mi přišel email, ve kterém dotyčný položil následující otázky:

1. Jak se vlastně přesně určuje kritičnost a nekritičnost funkčností? Na základě vazby na nějaké obchodní obraty?
2. Vezměme situaci cca. 40 systémů, cca. 800 rozhraní, a násobky x1000 funkčností.
   Jak lze v takovémto množství efektivně řešit kritičnost jednotlivých funkčností a jejich vazeb? Existují na to nějaké závislostní algoritmy?
3. Lze definovat ukončení testů na základě kritérií, že pokud klesne počet chyb za den pod nějaký práh, tak lze přejít do produkce, nebo se do produkce musí přejít až s počtem chyb 0 na všechny komponenty?

Jelikož všechny tyto otázky se točí okolo ekonomického pochopení testování, uvědomila jsem si, že jsem se zde ještě nevěnovala vysvětlení základních principů.

Testujeme, dokud se nám to finančně vyplatí

V byznysu každý krok, který děláme, děláme s vidinou budoucího zisku. Pokud nabízíme zaměstnancům různé výhody, děláme to proto, abychom nalákali kvalitnější zaměstnance a snížili náklady způsobené jejich fluktuací. Pokud investujeme do kvalitnějších výrobků, děláme to proto, že navýšení kvality je pro nás finančně výhodné. Ať už díky tomu, že nebudeme muset vynakládat vysoké částky na nápravu chyb objevených zákazníky, nebo proto, že nám to přinese více spokojených zákazníků.

To souvisí i s tím, že testujeme tak dlouho, dokud se nám to finančně vyplatí. Pokud jsou náklady na objevení a opravu chyby v dané fázi větší, než jaké jsou předpokládané náklady plynoucí z neopravení chyb, nemá smysl pokračovat. Rovněž se může manažer dostat do situace, kdy je aplikace vysoce chybová, testování je velmi efektivní a bylo by dobré ještě dva tři měsíce v něm pokračovat a opravovat chyby, ale z jistých, například právních důvodů, je přesto finančně výhodnější nasadit aplikaci do provozu.

Za znalost celkové situace a rozhodnutí o nasazení je zodpovědný zákazník, typicky manažer té části podniku, která aplikaci požadovala a bude ji využívat. Test manažer je zodpovědný za to, aby mu poskytl dostatek informací pro toto rozhodování, zejména ho seznámil s riziky, která ještě nebyly odstraněny. Pokud spolehlivě funguje pouze 20 % funkcí, 10 % je natolik chybových, že je není možné využívat, a zbytek aplikace není ještě otestovaný, jaké jsou konkrétně rizika nasazení?

Tester tedy nestanovuje kritéria a nerozhoduje o tom, kdy může aplikace přejít do produkce. O tom rozhoduje vždy zákazník a je na něm, jaké množství chyb a jaké závažnosti bude tolerovat, nebo zda rozhodujícím kritériem pro něj nebude naopak vnější vliv, například situace na trhu.

Sledujeme efektivitu testování, co se týče počtu objevených chyb

Jak již výše uvádím, testujeme tak dlouho, dokud se nám to finančně vyplatí. Co to znamená? Že je potřeba s testováním přestat v okamžiku, kdy by nalezení a oprava chyb objevených dalším testováním byla už dražší, než netestovat a riskovat jejich objevení a opravu v budoucnu. Určení takového okamžiku ale není triviální. Nehledě na to, že je třeba pracovat s pravděpodobností, je také nutné mít dostatečně podrobné informace o nákladech, které většina firem na této úrovni nesleduje a nemá je tedy ani k dispozici.

Méně přesnou, ale zato jednoduchou a rozumnou alternativou je sledování počtu nalezených chyb v čase. Následující obrázek ukazuje typický příklad počtu objevených chyb za určitou dobu testování.

Zpočátku testovací tým nachází velké množství chyb. Postupem času je objevováno stále méně chyb a zdá se, že další testování už nemůže přinést žádná překvapení. V tomto bodě nezkušený test manažer ukončí testování s tím, že produkt je již připraven. Zkušený test manažer pokračuje, protože ví, že testování běžně popadne druhý dech a počet objevených chyb opět začne růst. Zda se jedná o růst skokový nebo postupný, jak ukazuje křivka trendu, ovlivňuje zejména to, zda test manažer podpoří růst počtu chyb obměnou testů. Nicméně i bez této obměny se navýšení dá očekávat. Ukončení testování je pak vhodné až v druhé nebo třetí prohlubni (lokálním minimu).

Testování je investice. Peníze je třeba dát tam, kde to bude mít největší efekt

Vhodné zaměření úsilí je důvodem pro určování kritičnosti nebo priorit při testování. Co je jak důležité pro byznys určuje opět zákazník. Většinou bývá v rámci složitých systémů kritičnost aplikací a byznys procesů dobře známa a pro její zjištění se stačí obrátit na manažera spravujícího rizika a krizové plány. Pokud takovéto rozdělení v podniku ještě není provedeno, je možné při určení důležitosti aplikace vycházet z toho, jaké dopady by měla její nedostupnost či špatné fungování. Například se odhadnou ztráty z jednodenní nedostupnosti aplikace, vytvoří se rozmezí ztrát a ty se přiřadí jednotlivým označením důležitosti.

Co se týká přidělení důležitosti jednotlivým testům, zde se čerpá zejména z důležitosti uživatelských případů (use-casů). Zákazník určuje své priority již ve fázi sběru požadavků a specifikaci. Při určení priorit je možné vycházet z toho, kolik lidí danou funkci využívá, zda pracuje s kritickými zdroji (penězi, osobními údaji, atd.) nebo jak podstatné jsou byznys procesy, které funkce zpracovává.

Často však zákazník zejména u menších projektů určuje důležitost spíše pocitově a na přání dodavatele určí např. 20% nejdůležitějších funkčností. Oblíbené a pro zákazníka dobře pochopitelné je přiřazení tří stupňů důležitosti:

Critical to quality (Kritické pro kvalitu produktu) – Bez funkcí, kterým je přiděleno toto označení, by produkt nebyl použitelný a nesplnil by ani ty nejzákladnější potřeby zákazníka.

Good enough quality (Dostatečná kvalita) – Funkce s tímto označením zaručují potřebné, ale ne nezbytné činnosti.

Nice to have (Bylo by hezké toto mít) – Funkce, které jsou třešničkou na dortu, mohou usnadňovat práci uživatelům nebo být další možností, kterou by někdo mohl v budoucnu potřebovat.

Odpovědí na všechny tyto tři otázky je: „zeptejte se zákazníka, co by si on přál“. Protože on je ten, kdo investuje a on je ten, kdo bude hodnotit návratnost své investice.

Jak je důležité umět prezentovat své nápady

Před dvěma týdny jsem se účastnila konference CzechTest a byla to úžasná zkušenost, jelikož mezi přednášejícími byla řada zahraničních odborníků s 10 a často i 20 lety zkušeností v oblasti testování softwaru. Takových lidí je u nás žalostný nedostatek, nemám pravdu? Největší dojem na mě ale udělal Lloyd Roden, konzultant z Velké Británie, který mimo jiné přednáší taky na konferencích, jako jsou STARWest, STAREast, AsiaSTAR and EuroSTAR.

Čím se tento muž lišil od ostatních řečníků, nebyly jeho myšlenky a obsah jeho prezentací, jelikož jsem potkala řadu chytrých a zkušených lidí, ale jeho komunikační a prezentační dovednosti. Po jeho příspěvku, nejen opravdu přemýšlíte nad tématem, ale hlavně se cítíte nabytí energií a těšíte se, až tyto myšlenky vyzkoušíte v praxi. To, že Lloyd umí lidi kolem sebe přesvědčit a nadchnout je pravděpodobně i jedna z věcí, které ho dělají výborným test manažerem. Protože testování a zejména test management je především o komunikaci.

Rik Marselis, jeden z dalších řečníků, nám položil otázku, zda je testování technický obor nebo spíše humanitní. Já zastávám názor, že je to obojí, jelikož technické znalosti se zde snoubí s komunikačními dovednostmi, asertivitou a diplomacií.

Existují dobří testeři, kteří si rozumí více s počítači než s lidmi, a to je v pořádku, ale pouze do té doby, pokud jsou v týmu s testery, kteří mají velmi dobré komunikační schopnosti a rozumí potřebám stakeholdrů (= uživatelům a ostatním osobám na projektu).
Schopnost efektivní komunikace je nejdůležitější vlastností manažerů a všech osob, které si přejí být vyslyšeny. A já ještě nepotkala testera, který by si nepřál být vyslyšen a nesnažil se prosazovat kvalitu ve své organizaci.

Tester je nejlepší přítel programátora. 

Já učím svoje studenty, že tester je nejlepší přítel programátora. Skeptici jistě nesouhlasí: jak může být někdo, kdo neustále nachází chyby v něčí práci jeho nejlepší přítel?
Jedině díky taktu, respektu k programátorovi a poskytování informací, které programátorovi ulehčují jeho práci.
Ale moment! Tohle je přesně to, co znamená být dobrým testerem. Tester poskytuje informace. Není to skvělé?!

Programátor je pouze další osobou, které pomáháme poskytováním potřebných informací. Pokud se dobře staráme o programátory a pomáháme jim rychle nacházet a opravovat problémy poskytováním relevantních informací, často se stáváme dobrými přáteli.
Programátoři nám neposkytují službu opravování chyb, my jim poskytujeme službu dodávání potřebných informací. Samozřejmě nejsou jediní, komu tuto služby poskytujeme, ale jsou skupinou, kterou často zanedbáváme. Pokud někomu nevěnujeme pozornost, kterou si zaslouží, nebo i hůř na něj nadáváme, není se co divit, že pak vztahy nejsou ideální. Špatný vztah mezi testery a programátory je pak znakem špatných testerů a managementu, který problém ignoruje.

Tester poskytuje informace. Dobrý tester poskytuje ty správné informace.

Z tohoto důvodu bych Vás všechny chtěla vyzvat: Běžte za programátory. Seznamte se. Zjistěte, jak by jste jim mohli pomoct. Zeptejte se jich, jaké informace by chtěli mít v reportu chyby, co jim na reportech vadí. Zeptejte se na jejich další problémy s kvalitou a žádejte je o zpětnou vazbu pravidelně.
Toto je dovednost, kterou musíme neustále pilovat: jak poskytovat ty správné informace a jak je správně komunikovat.

A pokud byste chtěli se hned do toho pustit, zde je pár tipů, jak začít.

Tipy:

• Zlepšete své reporty chyb: crash course on reporting bugs
• Zlepšete svoje přesvědčovací schopnosti: coaching testera how to email and influance stakeholders
• Zlepšete své prezentační schopnosti: Pokud můžete, zaplaťte si soukromé lekce a pokud ne, přečtěte si pár základních tipů pro dobrou prezentaci (Presentation Magazine) a podívejte se na pár tutoriálů na Youtube (Effective Presentation Skills)
• Cvičte své schopnosti, kdykoli máte příležitost: uTest bug battle

Studie o testování softwaru

V rámci grantu VŠE jsme spustili dotazníkovou studii o testování softwaru v České republice. Prosím ty z Vás, kteří přijdou v práci do styku s testováním, jste se zůčastnili a vyplnili dotazník na stránce studiekvality.vse.cz
Přispějete k tím k analýze situace v testování softwaru v České republice a k jejímu rozvoji.
Děkuji.

------ Nyní k dispozici výsledky!!! --------

Výsledky naleznete na stránkách: studiekvality.vse.cz
Článek ke studii vyjde v odborném časopise Systémová integrace.

Proč bychom měli testovat?

Tento příspěvek je určen nejen testerům, ale i managerům, které zajímá, co by jim testování softwaru mohlo přinést a možná nepřináší. Proto začnu definicí dvou pojmů, které dále často používám:

Zajišťování kvality (Quality Assurance) – plánované a systematické procesy jejichž cílem je zajištění vhodnosti produktu k jeho zamýšlenému účelu.

Testování - proces sběru a třídění informací získaných skrze zkoumání produktu, součást obecněji pojatého zajištění kvality.

Pokud máme pocit, že testování a zajišťování kvality není věnován dostatek pozornosti a společnosti tuto stránku vývoje softwaru podceňují, možná za to do jisté míry může i to, že se nám nedaří přesvědčit ostatní o důležitosti testování a jeho odborného řízení.

Jaké jsou tedy přínosy testování softwaru a zajišťování kvality? Které body bychom měli zmínit při prezentaci přínosů?

Proces zajišťování kvality ovlivňuje tři manažersky významné oblasti:
- Marketing
- Risk management
- Snižování nákladů

Marketing

To, že kvalitní produkt dodaný zákazníkovi má pozitivní vliv na pověst firmy, zatímco vysoce chybový nespolehlivý software pověst ničí, je jednoduchý logický závěr. Těžší je už odhadnout nebo si jen uvědomit míru tohoto vlivu. Vliv nekvalitního produktu na pověst firmy totiž přichází ve vlnách. Některé z nich jsou okamžité a rychle mizí, některé negativně ovlivňují firmu i po několik let.

První vlnou odezvy je reakce bezprostředního zákazníka, který na základě spokojenosti rozhoduje o následné spolupráci.

Druhou vlnou je reakce konečných zákazníků. Ti v případě nepříznivého přijetí produktu mohou způsobit řadu nepříjemností. Jejich neustálé stížnosti a reportování chyb může způsobit neočekávané prodražení projektu, takže z původně ziskového projektu se stane projekt prodělečný. Dále jejich nepříznivé přijetí produktu může změnit názor managementu zákazníka na dodavatele, nebo se dostat mezi širokou veřejnost prostřednictvím novinového a televizního zpravodajství.

Třetí vlnou je reakce současných zaměstnanců a dalších lidí z oboru výroby IT. Kvůli neustálé fluktuaci zaměstnanců se pověst softwarové firmy šíří dále a po mnoho let přetrvává. Schopní zaměstnanci firmu, která nedokáže dodat kvalitní software, opouštějí, protože nechtějí být spojováni s dalším neúspěchem nebo protože je jednoduše nemotivuje se zlepšovat. Tam, kde chybí objektivní měřítka kvality, tam je vždy nedostatek snahy o zlepšení. Ze stejných důvodů se firmě vyhýbají potencionální schopní zaměstnanci. Slyšeli o ní negativní věci ze strany bývalých či současných zaměstnanců.

Čtvrtou vlnou, která ovlivňuje softwarovou firmu s největším zpožděním, je neochota dalších zákazníků nebo jiných softwarových firem s ní spolupracovat. Před zaměstnanci firmy nelze zatajit nedostatek snahy o zajištění kvality a špatné nastavení procesů. Pokud tito zaměstnanci jsou přesvědčeni o tom, že by si sami svojí firmě nikdy nedali zakázku na vývoj softwaru, pak této firmě nebudou ochotni dát zakázku ani za několik let, kdy budou takováto rozhodnutí dělat z pozice manažerů a ředitelů. Stejně se zachovají i všichni, kteří se o špatně nastavených procesech dověděli od svých nových kolegů či kamarádů.

V těchto čtyřech vlnách působí každý projekt dle své kvality a dopadů v pozitivním či negativním směru na marketing.

Risk management

Testování je nástrojem k získání objektivních informací o stavu vyvíjeného softwaru. Tyto informace jsou pak nejdůležitějším vstupem pro řízení rizik spojených s vývojem softwaru. Testování se prolíná celým procesem vývoje. Už od samého počátku tedy kontroluje soulad vývoje s představami zákazníka, srozumitelnost, jednoznačnost a logiku výstupů. Včasným informováním o nedostatcích a chybách zabraňuje nedorozuměním a zbytečnému plýtvání zdrojů na špatné verze. Řízení kvality pak navíc definuje a hlídá postupy vývoje z hlediska zajištění jednoduchosti, srozumitelnosti, správnosti, přesnosti, rychlosti a dalších kvalitativních měřítek. Díky tomu dochází jak k výraznému snížení pravděpodobnosti vzniku problémů s kvalitou během i po vývoji, tak k omezení dopadů při vzniku problémů.

Testování výrazně předchází problémům s zákeřnými chybami. U softwaru z finančního, lékařského nebo jinak kritického sektoru, mohou ztráty způsobené dopadem jedné jediné zákeřné chyby několikanásobně převyšovat celý rozpočet na vývoj tohoto softwaru.

Bez testování zůstávají firmě jen dvě nepříjemné možnosti, jak s omezit riziko spojené s vývojem softwaru:
- zajistit si subdodavatele, který riziko do jisté míry převezme za ně
- pokud to jde, pojistit se proti některým typům problémů

Snižování nákladů

Přestože jednou z nejčastějších manažerských chyb je při snižování nákladů obětování kvality, právě efektivně nastavené zajišťování kvality přináší největší úspory. Z ekonomického hlediska by testování mělo trvat tak dlouho, dokud předpokládaná průměrná cena nalezení a opravy chyby objevené v příštím cyklu testů je menší než průměrné náklady na chybu objevenou zákazníkem vynásobené pravděpodobností objevu chyby. Zjednodušeně, testovat by se mělo tak dlouho, dokud je to finančně výhodnější než netestovat. Zajišťování kvality se navíc snaží nastavit procesy tak, aby docházelo k co nejmenšímu počtu chyb a ty byly co nejlevněji odstranitelné. Zajištění kvality je investice a je tedy vhodné sledovat její návratnost.

Problém je v tom, že je velmi obtížné zvládat řízení kvality tak, aby bylo maximálně efektivní a aby minimalizovalo náklady. Takový úkol vyžaduje zkušenosti, cit a výborné znalosti zkušeného odborníka. Proto, když už testujeme, je třeba to dělat dobře.

Jak začít?

Nastavit efektivně proces testování není jednorázová věc, ale vzniká neustálým dolaďováním na základě různých rozumně zvolených měřítek, které varují, pokud není vše v pořádku a na kterých lze sledovat zhoršení či zlepšení efektivity.

Pochopení klíčové role řízení kvality při vývoji softwaru, stanovení měřítek, procesu řízení kvality a vyhledání vynikajících odborníků s praxí přímo v testování dává dohromady dobrý základ pro každé oddělení řízení kvality softwaru.

Problémy s pokrytím kódu

Jednou z důležitých technik je sledování nakolik je aplikace pokryta testy. Můžeme sledovat kolik případů užití máme porytých, kolik zákazníkových požadavků, ale nejpřesnější alespoň co se týče pokrytí funkčnosti je pokrytí kódu.
Při zjišťování pokrytí kódu se zaznamenává, jaký kód byl při testování spuštěn a jaký naopak otestován ještě nebyl.

Nejjednodušší ale zároveň nedostačující a zavádějící je pokrytí příkazů - řádků.

To pouze kontroluje, zda daný příkaz, řádek, byl proveden v průběhu testování, pro pokrytí podmínky tak může stačit její libovolné vyhodnocení.

Formálně: T splňuje kritérium pokrytí příkazů pro daný kód K, jestliže pro každý příkaz p náležící kódu K existuje test t z množiny T, že při provedení t bude spuštěn příkaz p.

Pro testera nebo programátora není problém dosáhnout velmi vysokého (i 100 %) pokrytí příkazů programu plného chyb aniž by jediný test selhal, aniž by byla objevena jediná chyba. Přesto, že tato metrika je takto zavádějící, pro svou jednoduchost je i tak oblíbená.

O stupeň pokročilejší je pokrytí hran – rozhodnutí.

Formálně: Představme si graf, kdy příkazy tvoří uzly a možné přechody mezi nimi hrany. Pak za sebou provedené příkazy tvoří hranu a podmínka uzel, ze kterého vedou dvě hrany, jedna pro true a jedna pro false hodnotu. Pak množina testů T splňuje kritérium pokrytí hran pro daný kód K, jestliže pro každou hranu h výše popsaného grafu existuje test t z množiny T, že při provedení t projde výpočet hranou h.

Jednoduše řečeno u pokrytí hran je každá podmínka uzlem, ze kterého vedou dvě hrany.

Například:

Máme kód se třemi podmínkami, z nichž jedna je vnořená.



Graf pokrytí hran pak vypadá následovně:



Přitom modré kolečka představují podmínky, zelená ostatní příkazy.

Při jakýchkoli složitějších podmínkách je ale i toto pokrytí nedostatečné.

Další stupeň představuje pokrytí podmínek.

Formálně: Množina testů T splňuje kritérium pokrytí podmínek pro daný kód K, jestliže splňuje kritérium pokrytí hran a pro každou složenou podmínku platí, že pro každou její část p existují testy t, u z množiny T, že při provedení t se p vyhodnotí kladně a při provedení u záporně.

Pokud se vynechá část, že pokrytí podmínek musí splňovat pokrytí hran, tak k nepokrytí hran a pokrytí podmínek dochází v případě, že pro všechny možné vstupy je vždy celá podmínka vyhodnocena jako pravdivá nebo nepravdivá.

Vylepšení pokrytí podmínek spočívá v tom, že se berou v úvahu všechny možná vyhodnocení podmínky, nejen to, zda je pravdivá, či nikoli.

Například:

Mějme složenou podmínku if (a>0 || b>0).
K pokrytí hran by stačili tyto testy: {a = 5; b = -2}, {a = 0; b = 0}
K pokrytí podmínek by tyto testy nestačili, protože část b > 0 je v obou případech nepravdivá. Pokrytí podmínek lze však dosáhnout jinými dvěma testy: {a = 5; b = 2}, {a = 0; b = 0}

U této verze je už těžší najít chybu, kterou bychom plným pokrytím podmínek neodhalili, i když jisté typy chyb stále budou i v plně pokrytém kódu zůstávat.

Nejvyšší stupeň pokrytí je pokrytí cest, které sleduje všechny možné průchody kódem a proto představuje opravdu podrobné otestování.

Formálně: Množina testů T splňuje kritérium pokrytí cest pro daný kód K, jestliže splňuje kritérium pokrytí podmínek a pro každou cestu C v grafu kódu spojující vstupní a výstupní uzel grafu a obsahující nejvýše n cyklů existuje test t z množiny T, že při provedení t projde výpočet cestou C.

I když ne všechny chyby jdou odhalit pouze z kódu, pokrytí cest poskytuje jistotu, že byly otestovány všechny možnosti běhu. Problémem je praktická nepoužitelnost tohoto pokrytí, jelikož jeho složitost způsobuje exponenciální růst počtu testů.

Otázka 1: Kolik testů (průchodů kódem) je potřeba, aby měla metoda code_coverage pokryty příkazy; hrany; podmínky; cesty?



Otázka 2: Kolik testů (průchodů kódem) je potřeba, aby měla metoda code_coverage2 pokryty příkazy; hrany; podmínky; cesty?

Murphyho zákony. Proč jsou pravdivé?

Program je dobrý, když je bezchybný – což je nemožné.

Jsou lidé, kteří nevěří v existenci bezchybného softwaru a lidé, kteří si myslí, že testování bezchybnost zaručí. (Jsou i jiné skupiny lidí, z nichž nejhorší jsou ti, které kvalita nezajímá. Ale ty teď ponechme stranou.)
Bezchybné programy existují, ale pouze ty triviální. Například pokud jediné, co daný program má umět, je vypsat na obrazovku "Ahoj světe!" a skončit.
Čím je program složitější, tím těžší je i zkontrolovat jeho bezchybnost.
Nakonec i jednoduchý program o pár řádcích může mít tolik různých cest kódem, že bychom je všechny neotestovali ani za deset let.
Proto u jakéhokoli netriviálního programu, tím spíš složitých aplikací a systémů, je nutné počítat s tím, že ať na testování věnujeme sebevíc času, vždy bude obsahovat chyby.

Neviditelných chyb je nekonečné množství, oproti viditelným chybám, kterých je už z definice konečné množství.

Tento zákon je pouhým důsledkem Dijkstrova axiomu, že testování je vhodné k dokázání přítomnosti chyb, ale nevhodné k prokázání jejich nepřítomnosti.

Každý program obsahuje jeden chybný řádek.
Každý program jde zkrátit o jeden řádek.
Z toho plyne, že každý program jde zkrátit na jeden řádek, který je chybný.

K tomu téměř není co dodat. Snad jen, že je to jako sebenaplňující se proroctví. Čím více do kódu člověk zasahuje, tím je větší pravděpodobnost, že do něj zanese chybu.

Fungující program má pouze neobjevené chyby.

Tento zákon by ve skutečnosti měl znít, že software, na který si nikdo nestěžuje, má pouze neobjevené chyby a to proto, že ho nikdo nepoužívá.
Tak to funguje ve skutečnosti. Cílem testování je dosáhnout určitého (nejlépe vysokého) stupně kvality, ne dosáhnout toho, aby zákazník nenahlásil jedinou chybu.

Stačí, když zákazník bude mít z produktu dobrý pocit, protože nebude narážet na chyby často a ty nebudou mít žádné vážné důsledky. A ty chyby, na které narazí, budou rychle vyřešeny

Počet chyb vždy překročí počet řádek v programu.

Toto je spíše zobecněné pozorování. Často je tento zákon pravdivý, protože během životního cyklu vývoje dojde k tolika změnám v programu, že i když konečný program má x řádek, programátoři jich napsali mnohonásobně více.

Šance, že program dělá to, co má, je nepřímo úměrná počtu řádek v programu.

To je snadné pochopit. Čím je program složitější, tím je těžší se v něm vyznat, na něco nezapomenout a neudělat chybu.

Nehledě na to, kolik zdrojů máš, nikdy to není dost.

Netriviální program nemůžeme nikdy kompletně otestovat a nemůžeme zjistit, kolik dosud neobjevených chyb obsahuje. Je tedy možné testovat do nekonečna.
Důležité je dokázat s přidělenými zdroji co největšího efektu. Což je pravé umění nejschopnějších manažerů. Pokud objevení chyby a její oprava stojí více než kdyby jí objevil až zákazník, pak je na čase testování ukončit.

Patch je kus softwaru, který nahrazuje starou chybu novou.

I když je patch relativně malý kus softwaru, je nutné ho otestovat. Spoléhat na to, že vše poběží, jak má, aniž by to někdo opravdu vyzkoušel, je spolehlivým receptem na katastrofu.

Chyby se objeví v jedné části fungujícího softwaru, pokud další zdánlivě nesouvisející část je modifikována.

Jsou dva důvody, proč i když je změna pouze v jedné části programu, se mohou najednou objevit chyby tam, kde předtím žádné nebyly.
První důvod je, že tyto části spolu nějakým způsobem souvisí, ale nikdo si to neuvědomil.
Například jedna část volá funkci, ve které se nachází nadbytečné volání jiné funkce, která byla touto změnou zrušena.
Druhý důvod je, že přestože obě části softwaru spolu nesouvisejí, používají stejné zdroje. Může se tak projevit chyba, která v softwaru byla už nějakou dobu. Například špatně ošetřené sdílení paměti nebo ukazatel, který ukazuje na náhodné data.

Ty nejpřehlédnutelnější chyby způsobí ty největší problémy.

Malé a nenápadné chyby mají buď malé nebo žádné dopady (například logo je pixel posunuté mimo určenou pozici) nebo velmi závažné důsledky (V jednom ze sta případů dojde ke špatnému zaokrouhlení částky, což může mít za následek ztráty několikanásobně větší, než byla cena softwaru). Pokud chyba je nápadná, uživatel si jí hned všimne a pokud její dopady jsou závažné, tak je možné hned situaci napravit, aby se už neopakovala. Pokud ale chyba uniká pozornosti, její důsledky se hromadí, až se lavina protrhne a může dojít k velmi vážným problémům.

Softwarové chyby je nemožné detekovat kýmkoli kromě koncového uživatele.

Přestože testeři při testování odhalí velké množství různých chyb, některé chyby je těžké odhalit pro kohokoli než koncového uživatele. To proto, že i když se tester snaží na software dívat z pohledu uživatele, tak běžným uživatelem není, a chybí mu znalost chování uživatele.
Jediný způsob, jak zjistit reakce uživatelů na software, je vidět je s ním pracovat.

Jakoukoli chybu nehledě na její složitost, lze objevit pouhým pohledem.
Důsledek: Otravující kolemjdoucí s nevítanými radami ji spatří okamžitě.

Pokud už tester vyčerpal všechny nápady a objevil svým trénovaným okem všechny chyby, je potřeba k nalezení dalších chyb změnit přístup nebo i třeba zkusit větší odstup.

Chození po vodě a vývoj softwaru podle specifikace je snadné pouze pokud je obojí zamrzlé.

Každá změna specifikace přináší do vývoje rizika:
• O změně se nedozvědí všichni, kdo o ní potřebují vědět
• Změna bude nejasná a špatně pochopena
• Je třeba zahodit už otestovanou část a napsat novou, která je potenciálně plná chyb
• Složitost toho, co si vývojář musí pamatovat, se zvyšuje a je lehčí udělat chybu
• ...

Nejlepší způsob, jak obejít bezpečnostní prvek, je posadit za počítač třináctiletého.

Ve snaze zabezpečit software před nevítanými vetřelci mají lidé občas tendenci se soustředit na nejčastější a nejznámější způsoby průniku a budování sofistikované obrany proti nim. Přitom mohou přehlédnout nepřímou ale jednoduchou cestu dovnitř. Dalo by se říct, že tento zákon je důsledkem toho, když někdo přes samé stromy nevidí les.

Murphyho zákony byly převzaty z Murphy's computers laws, přeloženy a popřípadě mírně upraveny.

Základy testování

Protože literatury ohledně testování je v češtine velmi málo, rozhodla jsem se zveřejnit část svojí příručky o testování, která vznikla v rámci diplomové práce a která se zabývá základy testování.
Doufám, že se Vám bude líbit.

Tuto příručku a další materiály naleznete v sekci ke stažení. 

Zamyšlení nad testovací misí

Manažer by měl ...

... být vůdčí osobností

... jasně vysvětlit ostatním členům týmu projektovou misi a cíle

... umět nadchnout pro úkol

... podpořit přijetí projektových cílů zaměstnanci za své

... podporovat spolupráci a aktivitu

... motivovat ke zlepšování

S takovýmto přístupem jsem se setkala v přednáškách o managementu škole, v moudrých knihách jako je např. Měření v systémech managementu jakosti od Jaroslava Nenadála a bohužel poněkud méně často v praxi.

Atmosféra spolupráce, nadšení a odpovědnosti za dosažení cílů je jistě v mnoha oblastech plus, ale v testování softwaru je přímo magickou ingrediencí.

Definice cílů a snaha o jejich dosažení je oním počátkem cesty, jak se stát z průměrného testera, který jen sleduje scénáře a návody opravdovým expertem na testování.

Test manager nebo projektový manager definicí testovacích misí a nadchnutím testerů pro jejich dosažení vytváří prostředí, které testery inspiruje ke zlepšování a řada z nich pak začne růst ve vynikající odborníky.

Je to ale cesta, kterou neujdete po pár hodinách nebo dnech. Je to cesta, po které můžete jít tak dlouho, dokud vám vydrží motivace.

Protože dokud budete mít důvod se chtít zlepšovat, prostor ke zlepšení vždy najdete.

Mise testování určuje, co je momentálním cílem testerovy práce, a definuje kritéria, která hodnotí, zda a nakolik misi splnil. Je tak možné lépe řídit práci testera, je-li mu řečeno, jakých cílů má testování dosáhnout, s jakým záměrem má testovat.

Cíle testovací mise mohou být různé: odhadnout chybovost jednotlivých modulů aplikace, připravit reprodukovatelné testy, odhalit co nejvíce chyb, nebo třeba jen rychle odhalit závažné chyby, bránící nasazení aplikace.

Často testování sleduje více záměrů zároveň a mise tak má více cílů.

Smyslem definice misí, je uvědomit si záměr testování a schopnost posuzovat jejich výsledky.

Splnili jsme svou misi? Nakolik? Proč jsme selhali? Existuje prostor pro zlepšení? Co jsme se naučili? Je možné dosáhnout jiným přístupem lepších výsledků?

Definice konkrétních cílů dané iterace testování je mocným nástrojem. Manažerům umožňuje efektivní řízení zdrojů, testery vede pak k tomu, jak dělat svou práci co nejlépe.

Nejužitečnější cíle jsou definované tak, aby byly měřitelné.

Dvě skupiny otestují stejný produkt, jak rozhodnout, která je lepší?

Pokud nevíme, nakolik jsme dobří a nakolik splňujeme naše cíle, chybí prostor pro zlepšování. Chybí dostatek motivace a firma místo odborníků a efektivního testování bude mít jen samé průměrné klikače a ne moc dobré ale za to drahé testy.