Software testing očima nováčka, díl I.

Rozbiju to, či nerozbiju, to je oč tu běží… Nebo ne?

Opravdu je testování jen o hledání chyb, potažmo škodolibé snaze rozbíjet vývojářům jejich dítka? Opravdu je to jen vstupní krok do světa IT pro lidi, kteří neumí programovat? Opravdu to může dělat každý (a nejspíš to ani není potřeba)?

Softwarové testování je poměrně specifický tím, že je s ním na jednu stranu spojena spousta mylných, leč hluboce zarytých představ, a na stranu druhou si pod tímhle pojmem spousta lidí nedovede vlastně lautr nic představit. Když jsem na pozici testera nastoupil já, v kruhu svých známých jsem odpovídal častěji na „A co teda jako děláš?“ než na gratulace. No, a upřímně bylo často jednodušší odpovědět některým z oněch klišé, protože jakkoliv nad nimi lidi „od fochu“ rádi obracejí oči v sloup, rámcovou představu laikovi zkrátka dají. Bez ohledu na to, že je naše každodenní pracovní realita často všechno, jen ne tak triviální. IT je dnes ale obrovské téma a jsou do něj vyloženě vábeni i lidé z úplně jiných – včetně netechnických – oborů. I mezi mými přáteli se tak našli tací, kterým ledabylá odpověď o hledání chyb nestačila. Takže… co teda jako dělám?

Pokud se o toto téma už nějakou dobu zajímáte a pojmy ze světa vývoje softwaru vám nejsou cizí, o roli testera ve Scrum týmu se skvěle rozepsal už Honza. Nicméně já, jakožto člověk, který měl ještě před pár měsíci pojmy jako Scrum, Agile či regresní testy v (samo)studijních osnovách, bych s dovolením udělal pár kroků zpět. Znovu tu naši práci definuji trochu víc po lopatě a tento cyklus článků věnuji především lidem, kteří o kariéře ve vývoji softwaru teprve uvažují.

Bráno kol a kolem, tester je ve své podstatě kontrolor kvality, který se zároveň přímo podílí na její finální úrovni. V širším kontextu jde o dohled nad tím, že výsledný software odpovídá představám zákazníka. V dílčích detailech se nám pak výše zmíněná definice rozpadá do jednotlivých procedur a kompetencí spadajících do různých fází životního cyklu softwaru. Hodí se říct, že to nechvalně proslulé šťouchání do programu se zdánlivě nekalým úmyslem jej rozbít je pouze jedním z mnoha úkonů, které máme na starost, a mezi kroky, které mu předcházejí či ho bezprostředně následují, je to často ten méně zásadní. Ono je to šťouchání totiž přínosné pouze tehdy, když vím, do čeho šťouchnout, proč šťouchám zrovna do toho a hlavně – když chápu, co takové šťouchnutí (ne)má vyvolat. Jinak řečeno, tester musí v prvé řadě analyzovat, jaké byly vstupní požadavky na funkcionalitu, kterou testuje, aby mohl dojít k závěru, zda její reálná implementace tyto požadavky splňuje.

Samotné testování pak není v žádném případě změť nahodilého „tajtrlíkování“ po uživatelském prostředí daného softwaru, ale přímo vychází z formálních testovacích scénářů, které si tester na základě výše zmíněné analýzy vytvořil. Ideální je pak stav, kdy do vývojového procesu vstupujeme před započetím psaní kódu a validujeme už samotné požadavky a akceptační kritéria dané funkcionality (či „fičury“, chcete-li), aby nedošlo k tomu, že programátor bude sedět u úkolu, který je buď vyloženě nesplnitelný, nebo jeho implementací mohou vzniknout problémy jinde.

Stejně jako při testování z nějakých formálních dokumentů vycházíme, i závěry naší práce musí být pochopitelně nějakým způsobem zaznamenány. Za nejvýmluvnější příklad takových výstupů lze brát reporty o případných nalezených chybách, které musí být přesně tak obsáhlé, konkrétní a srozumitelné, aby daný problém na jejich základě mohl vývojář lokalizovat a opravit. Testerovou prací není poznat, kde je chyba v kódu, taková kouzla mají pod palcem vývojáři. My máme za úkol identifikovat, že daná funkcionalita (případně celá aplikace obecně) se z pohledu koncového uživatele nechová v souladu s očekávaným výsledkem a tento rozkol náležitě zaznamenat.

Rozsah, typy a zaměření testů se plánují na základě analýzy požadavků projektu (ať už technických či personálních) a rizik s nimi spojených, což jsou záležitosti, které kompetenčně připadají spíše seniorům až test manažerům. Není ale neobvyklé, že se i od řadového testera může vyžadovat součinnost. Velké téma samo o sobě je pak tvorba a údržba automatizovaných testů – obor, který ve většině případů (ne však vždy) vyžaduje alespoň základní znalost programování.

Tím se dostáváme k často zmiňované tezi, že pojem „tester“, byť naprosto standardně používaný a rozhodně nikterak pejorativní, je vůči nám lehce nefér, poněvadž svým způsobem bagatelizuje, co naše práce obnáší. Minimálně interně se proto často používají spíše pojmy typu software quality (assurance) engineer a já doufám, že předchozí odstavce dostatečně ilustrují, že to opravdu není jenom proto, že to vypadá líp v životopise.

Nuže, máme zběžnou představu o tom, co práce SQA obnáší „papírově“, tak se můžeme začít bavit o tom, co se (nejen) od nováčků očekává, co ve své pozici mohou očekávat a bez čeho se v práci rozhodně neobejdou.

O tom ale až příště.