Dnes si dovolím spíše filozofickou úvahu a to na téma, za co všechno je vlastně odpovědný tester. Může se stát (a stává se), že po odevzdání hotové a otestované aplikace zákazníkovi jsou v ní dále nacházeny chyby. Bez ohledu na závažnost těchto chyb se zároveň s nimi objeví také otázka, kdo za ně nese odpovědnost.

Ta nejjednodušší úvaha, která člověku vyskočí v mysli je, že tester žádnou z těch chyb nezpůsobil a odpovědnost za ně tedy padá přímo na hlavy konkrétních vývojářů. Jenže tak jednoduché to není. Už jsem tu psal, že tester nese odpovědnost za kvalitu výsledného produktu. Jinak řečeno, tester musí být schopen (s určitou mírou přesnosti samozřejmě) říci, zda produkt funguje tak, aby bylo možné jej vydat. Někdy je nutné předat aplikaci zákazníkovi i přesto, že obsahuje chyby. Ty označujeme jako "známé chyby" a zákazník na ně může být upozorněn. Každopádně tyto známé chyby musí být zaznamenány a musí být jasné, že aplikace je vydávána včetně nich. Odpovědnost za vydání takové aplikace je mimo bedra testera. Obvykle ji má Project manager a on také musí zvážit riziko podobného kroku.

Pokud se ale v aplikaci objeví chyba, která je mimo tyto známé chyby, pohledy všech pak obvykle směřují nejdříve na testera. Častá otázka pak je "Jak jsi to testoval?" Ale je to fér? Chybu zcela jistě způsobil vývojář, tak proč je výtka směřovaná na testera? Řekněme si tu jasně, ano je to fér. Každá chyba, která se u zákazníka projeví, není jen chybou vývojáře, ale také selháním testera. Chyby v testování se obvykle projeví právě nezachycenými chybami v aplikaci. 

Samozřejmě se dá argumentovat například omezeným časem na testování (častý problém při vývoji softwaru), nedostatečnou úrovní analýzy, nedostupností relevantních dat pro testování atd. Toto a ještě mnoho dalších mohou být faktory, které dokáží negativním způsobem ovlivnit kvalitu testování. Pro testera by ale měl  platit princip "krytí zad". Jinak řečeno každá podobná překážka, snižující vypovídací schopnost testů, by měla být včas a řádně nahlášena a ideálně také zdokumentována. Nemá žádný smysl v okamžiku, kdy jsou v aplikaci (která byla v testech označena jako vhodná k odevzdání) nalezeny chyby, se zaštiťovat problémy, které byly známy již v průběhu testování (a často i před ním). 

Testera  by se obecně neměl zaměřit jen nalézání chyb v aplikaci. V zájmu testera je zvyšování kvality kvality procesu vývoje. Čím lépe tento proces funguje, tím větší je pravděpodobnost, že aplikace bude fungovat tak jak má. Samozřejmě pokud budeme upřímní, víme, že tester obvykle není v pozici, že by mohl přímo ovlivnit nastavení procesů ve firmě nebo v týmu. Ale právě formou dokumentování problémů znesnadňující testování je možné minimálně upozornit na fakt, že ne vše je ideální.

Nicméně zpět k tématu. Testeři by si měli uvědomit, že jejich prací není najít co nejvíce chyb. Jejich skutečným úkolem je zabezpečit, že k zákazníkovi (uživateli) se dostane aplikace, která funguje jak má. Proto musí zvolit takovou strategii testování, připravit takovou sadu testů, testovací data a testovací nástroje aby po skončení testů mohl s čistým svědomím říci, že taková aplikace skutečně je (případně není a proč).

A na závěr jen krátce - vím, že každá aplikace obsahuje i po otestování nějaké chyby a že snad žádnou aplikaci (kromě tech extrémně triviálních) není možné otestovat celou. Proto tu nechci razit myšlenku nulové chybovosti. Tester ale musí zvolit takové techniky testování, aby riziko výskytu chyby po testování minimalizoval. Závažné chyby a chyby znemožňují pracovat s aplikací způsobem, k jakému je určena, nejsou přípustné snad v žádné firmě nebo týmu.