Snad každý tester se s touto situací někdy potkal. Testovaná aplikace se chovala jinak, než bylo popsáno v analýze i možná i jinak, než by "zdravý rozum" očekával. Ovšem nahlášená chyba byla zamítnuta s vysvětlením, že jde o vlastnost. Jinak řečeno jde o "fičuru" (z anglického feature). Takové přeměny ale nejsou vždy legální a ne vždy mohou pomoci vyvíjené aplikaci.

Rád bych tu na úvod znovu uvedl jednu ze zásad testování - tester zkoumá soulad reálného chování vyvíjené aplikace s chováním požadovaným, které je buď popsané v analýze nebo je zaznamenáno v podobě požadavků. Tester by se při této své činnosti měl řídit právě těmito podklady a ne pohledem a názory vývojáře, který danou aplikaci vyvíjí, byť by šlo o programátora s mnohaletou zkušeností.

Prohlásit chování aplikace, které není v souladu s očekáváním, za vlastnost, je samozřejmě tím nejjednodušším způsobem, jak danou chybu vyřešit. Testerovi ale takové vysvětlení nesmí stačit. Vždy musí existovat podklad, na základě kterého lze skutečně říct, že tato vlastnost je žádaná a očekávaná.

K situaci, kdy testerem odhalený nesoulad v chování aplikaci je prohlášen za vlastnost, může dojít z různých důvodů. Pár si jich tu uvedeme:

Analýza obsahuje chybu

I analytik je jen člověk a analýza může obsahovat chyby. Vývojář, který podle podobné analýzy aplikaci vyvíjí, může tuto chybu objevit. Mnoho vývojářů v podobné chvíli zareaguje tak, že tuto chybu jednoduše v kódu neudělá (tedy podle chybné analýzy vytvoří správný kód). Bohužel často se stává, že se informace o této chybě ztratí. Často se setkávám s přístupem, že to není v popisu práce vývojáře hlásit a řešit chyby v analýze. Což může být pravda (záleží na použité metodice a nastavení vnitřních procesů), ale potom to ukazuje na nedostatečné zapojení testování do procesu vývoje. Výsledkem samozřejmě je, že tester má k dispozici chybnou analýzu a na jejím základě (pokud nemá v dosahu jiné zdroje informací jako jsou třeba zákaznické požadavky) pak může nesprávně vyhodnotit chování testované aplikace jako chybné.

Vývojář vylepšuje práci analytika

I v případě, že analytik vytvoří analýzu bez chyb, může se stát, že se jí vývojář nebude zcela držet. K tomu dochází obvykle v okamžiku, kdy vývojář použije jiné (ze svého pohledu lepší) řešení situace, která je nějakým způsobem řešena v analýze. Setkávám se s tím obvykle u analýz, které obsahují ne zcela standardní řešení. Vývojáři (obzvláště ti z nich, kteří mají za sebou již vetší množství projektů), jak jsem si všiml, nemají extravagance příliš v oblibě. Proto v takovém případě často volí osvědčený a ověřený postup. Z hlediska testování má taková situace několik stránek. Především tyto změny nejsou ve valné většině případů nikde zachyceny a tester na ně přijde až v okamžiku, kdy se chování aplikace odchyluje od chování očekávaného dle analýzy. Druhou věcí ovšem je, že tato "standardizovaná" řešení, která si vývojáři nosí z projektu do projektu, bývají často méně náchylná na chyby (ty se většinou podaří odladit právě již na předešlých projektech). Jenže s tím se opět pojí další strana a to předpoklad, že analytik měl zřejmě nějaký důvod to své původní řešení do analýzy zařadit. Jeho změnou tak mohou vzniknout chyby, které jsou pak poměrně těžko dohledatelné. Nemusí jít ale jen o reálné chyby v běhu aplikace. Samostatnou chybou by zde mohl být i fakt, že se aplikace jednoduše nechová podle očekávání zákazníka. A k tomu podobným zásahem dojít může.

Tester pochopil analýzu jinak než vývojář

Vůbec nejčastější příčina zamítnutí chyby. Fakt, že všichni tři zúčastnění (tedy analytik, vývojář i tester) pracují prakticky se stejnými údaji rozdílným způsobem, vede často k situaci, kdy si každý vykládá tyto informace jinak. Stává se, že analytik vtělí své myšlenky do analýzy s přesvědčením, že tím zcela jasně vyjádřil způsob řešení požadavků zákazníka. Ovšem toto jeho jasné řešení je pro vývojáře jinak jasné než pro testera. Stává se, že se mýlí pouze jeden z nich, ale může se stát, že se pletou všichni. Vždy záleží na formě a formátu, jakým jsou zaznamenány požadavky zákazníka a v jaké je vytvářena analýza. 

Co s tím?

Když se podíváte na předchozí tři odstavce, zjistíte, že se tam v zásadě opakují stejné příčiny. Jde o nedostatečnou revizi analýzy a špatná komunikace v týmu. Testování analýzy, bohužel, není příliš zvykem. Tester se s ní obvykle potká až v okamžiku, kdy připravuje testy a to je velice často v té samé chvíli, kdy již probíhá vývoj. Analytik pak velice často v okamžiku, kdy odevzdá hotovou analýzu, přechází na další projekt (část projektu, k jinému týmu apod.) a informace, které držel v hlavě po dobu psaní analýzy a které často nemusí být zcela zachyceny ve výsledném dokumentu, se postupem času ztrácí.

Řešení je tedy celkem zjevné. Testování musí být do procesu vývoje zapojeno mnohem hlouběji. Tester by měl mít k dispozici maximum informací, které mu umožní připravit relevantní testy pokrývající chování aplikace, které je skutečně požadováno. Tedy informace jak ze strany analytika (ve smyslu jak a proč se některé problémy v analýze řeší a z čeho toto řešení vychází a zda ho skutečně takto zákazník chce) tak ze strany vývojáře (v podobě kde, proč a jak došlo k odchylce od chování popsaného v analýze).

Zdá se, že v tomto směru lépe fungují agilní metodiky vývoje, kde je na komunikaci a sdílení informací kladen velký důraz. Ovšem já za sebe mohu říct, že chyba obvykle není v metodice ale ve způsobu, jakým je použita. Na papíře vypadá každá metodika ideálně. V praxi je ale většinou ne zcela dobře využívána.