Testování - metráková princezna, kterou nikdo nechce

Programátor a tester diskutují o hladině v lahvi. Programátor ji vidí z poloviny plnou. Tester ji vidí z poloviny prázdnou, pokud přehlédne fakt, že kdyby obsah nepřelili před chvílí do menší lahve, byla by prázdná nejméně ze dvou třetin. Jak typické. Jak se vůbec dá s takovým pesimistou pracovat?

To "nejméně" je důležitý detail. Tester ze zkušenosti ví, že láhev nikdy nebyla a nebude úplně plná (program nikdy nebyl a nikdy nebude zcela bezchybný), proto se zdráhá říct, jak moc je lahev prázdná. Ví, že neví.

Tento přístup není populární - ať už z pohledu ostatních členů vývojového týmu, či jejich nadřízených. Ale postoj je to svým způsobem obdivuhodný, když zvážíme, jak osamělou pozici si za to vyslouží, a jak velkým přínosem mohou pro svůj tým být. Často jsou poslední, kdo stojí na straně kvality, tváří v tvář všemožným tlakům. Je těžké mít pravdu proti všem.

Den ztracený na začátku projektu je přesně stejně dlouhý, jako poslední den před uvedením programu do provozu. Častý komentář na konci projektu je: testeři to nestihli otestovat, tak se projekt posunuje o měsíc. Testeři jsou univerzální viníci. Kdy se však první tester dostal k projektu? Zcela vyjímečně při psaní požadavků nebo při návrhu. Jenom by těmi svými věčnými připomínkami zdržovali. Nikdo je nechce vidět dřív, než je možné je zasypat kódem.

Je to iracionální, tisíckrát opakovaná chyba. Přitom testování, pokud jde o čas a náklady, to je těžká váha. Čím dříve se chybu podaří nalézt, tím je lacinější její oprava.

Zdaleka nejlacinější oprava je ve fázi požadavků.

Možná, že už jste slyšeli větu: "Teď už jenom dotestovat a můžeme jít do provozu". Jakou váhu má jenom? Podle Zelkowitze, Showa a Gannona(1979) je rozdělení nákladů na systém přibližně toto:

Co z toho vyplývá? Pokud pomineme to, že náklady na vývoj systému tvoří pouze jednu třetinu celkových nákladů během životního cyklu systému, náklady na testování tvoří 45% nákladů na vývoj. Jinými slovy, v okamžiku dokódování systému a jeho předání do testů jsme těsně za půlkou vývoje(!)

Osobnost testera

Testeři jsou jistým protipólem programátorů, což často vyvolává konflikty. Programátor přistupuje k programu pozitivně - věří, že program nemá chyby a doufá, že testy žádné chyby neodhalí. Tester ví, že program má chyby a jeho největší touhou je co nejrychleji je nalézt a přesvědčivě reprodukovat. Už to je dost dobrý důvod, aby se tyto dvě skupiny neměly rády.

Nejdůležitější pro testera je schopnost věcné argumentace a schopnost dosáhnutí opravy. Pokud je argumentace ze strany testera kontaminovaná kritikou osobnosti programátora nebo jeho schopností, pravděpodobnost opravy chyby se velmi snižuje. Tester musí být nápomocný a to se mu podaří hlavně tím, že odvede kvalitní práci při popisu chyby a její reprodukovatelnosti. Programátoři ocení vzorky dat, které systém spolehlivě "složí", stejně tak, jako popis celkového kontextu chyby (verze programu, globální nastavení, verze prohlížeče, jeho rozšíření, apod.).

Je v zájmu vývoje, aby tester zvážil, kterou bitvu má cenu bojovat, a kdy je rozumné ustoupit. Zvlášť destruktivní jsou eskalace, které mohou nezvratně poškodit produktivitu vývojového týmu. Těmi je zvlášť potřeba šetřit.

Testovací taktika

Výběr testovacích případů a jejich dokumentování je jednou z hlavních činností testera. Dobrý tester má instinkt, který ho vede při vytváření takových podmínek, ve kterých bude program nejspíš nefunkční. Mohou se týkat vstupních dat, periferií, komunikačního prostředí nebo čehokoliv jiného, s čím se bude muset program v provozních podmínkách vyrovnávat.

Tester potřebuje testovat na různých konfiguracích, proto je dobré slevit z korporátních pravidel, které určují, jaký pracovník na jaké pozici může mít notebook a/nebo PC s více monitory. Náklady na hardware jsou v porovnání s náklady na testování zanedbatelné.

Přehled testovací dokumentace se stručným komentářem je sestavený podle standardu IEEE Standard 829–1998 for Software Test Documentation. Cílem testování není vytvoření všech dále uvedených dokumentů. Cílem je co nejrychlejší nalezení co největšího počtu chyb. Cokoliv stojí v cestě tomuto cíli – a takovou překážkou může být i tvorba testovací dokumentace – je potřeba omezit.