Testování s chybou v hlavě (ne softwarového druhu)

Při práci v QA často slyším v hlavě hlas: "Jsi si jistý, že jsi všechno zkontroloval?" Někdy je to užitečné šťouchnutí, ale pokud to nezaškrtnete, začne to být problém. Níže budu mluvit o této otravné vnitřní chybě a jak se projevuje.

V tomto článku se chci podělit o své myšlenky a poznatky, které jsem získal při studiu tohoto fenoménu. Doufám, že vám budou užitečné, a rád bych slyšel váš názor na to v komentářích. Zpětná vazba je totiž jedním z nejlepších způsobů, jak se vidět zvenčí a zlepšovat se.

Větší stránky vnitřního brouka: "Jste si jistý, že jste zkontrolovali všechno?"

Nutí vás přistupovat i k těm nejjednodušším úkolům opatrně a s důrazem na detail.

Jednou, po přepínání mezi úkoly a již dokončení testování, jsem se rozhodl vše zkontrolovat pro každý případ. Tehdy jsem si všiml malého, ale zásadního detailu. Úloha neobsahovala vzorec pro výpočet, který měla nová funkce provádět. Zvědavě jsem si znovu přečetl popis úkolu i epos a k mému překvapení nebyl nikde uveden vzorec pro výpočet. Jak jsem to tedy počítal?

Je to trapné přiznat, ale používal jsem a ověřoval jsem výpočty pomocí vzorce z jiného úkolu. Zatímco tyto dva úkoly spolu souvisely, vzorce měly fungovat nezávisle. Uvědomil jsem si toto nedopatření, rychle jsem požádal o správná pravidla výpočtu, znovu otestoval úlohu a zjistil, že vývojář udělal stejnou chybu. Také oni použili vzorec z druhého úkolu.

Tato otravná malá chyba mi umožňuje najít netriviální chyby a učinit produkt spolehlivější

Jakmile projdu plánem testování, tento malý potížista začne chrlit nápady jako: „Co když klient používá větší velikost písma nebo zastaralý OS?“

Díky ní své testy dokumentuji důkladněji a do zpráv často zařazuji videa a screenshoty

To je neuvěřitelně užitečné, když je testování hotové, funkce je aktivní a najednou se objeví chyba. Poté, co je identifikován a opraven, zkontroluji své testovací záznamy, abych zjistil, zda jsem problém přehlédl během testování, nebo zda byl zaveden později ve výrobě. Někdy vidím, že se chyba skrývá na očích na mých snímcích obrazovky nebo nahrávkách. Když se to stane, pátrám v tom, proč jsem to přehlédl a proč neexistoval testovací případ, který by to zachytil.

V této sebereflexivní poznámce přejděme k nevýhodám tohoto Vnitřního hlasu

Dělá mi to větší úzkost, často bez dobrého důvodu

To se někdy stane po nějakém zmatku, ale jsou také chvíle, kdy se hlas Broučka ozývá nevyprovokovaný. Při několika příležitostech mě to nenechalo v klidu ani poté, co jsem šel spát, a nakonec jsem si dělal poznámky o tom, co bych měl ještě zkontrolovat.

Často mě to nutí ztrácet čas na velmi spletité testovací případy

To je přímý důsledek prvního bodu: úzkost plodí v mé hlavě ty nejpodivnější a nejděsivější scénáře. Momentálně se zdají být kritické, ale když se podíváme zpět, často se ukáže, že jsou něco jako: "Co když drozd zahvízdá v borovici pod měsícem?"

Brání mi to soustředit se na jiné úkoly

Někdy i po přesunutí úkolu do dalšího stavu a zahájení něčeho nového mě myšlenky na tyto testovací případy pronásledují a brání mi soustředit se na nový úkol. V takových případech může být obtížné vypnout úzkostný Checker-Bug.

Jak tedy lze využít tohoto Buga ve svůj prospěch a jak zabránit tomu, aby převzal vládu?

První věc

to, co se mi objevilo v hlavě, když jsem psal o nevýhodách – a něco, co opakuji jako mantru – je toto: Vyčerpávající testování je mýtus. Chyby budou vždy.

Bez ohledu na to, jak důkladní jste, je nemožné předvídat každou kombinaci akcí a scénářů, což znamená, že nemůžete zachytit každou jednotlivou chybu dříve, než ji odhalí vaši uživatelé.

Zvláště v neustále se měnícím světě.

To je něco, co prostě musíte přijmout a jít dál.

To, co mi pomohlo se s tím smířit, byla analýza hlavních příčin produkčních chyb – to, co někteří lidé nazývají posmrtné zprávy . Jde o to, když mluvíte se všemi zúčastněnými, abyste zjistili, jak k chybě došlo a co můžeme udělat, abychom zabránili jejímu opakování.

A dozvěděl jsem se, že vážné závady byly častěji způsobeny jednoduchými přehlédnutími: někdy nebyly zkontrolovány testovací případy s prázdnými hodnotami, což vedlo k tomu, že se některé produkty v obchodě nevystavovaly; jindy chyběla lokalizace, což vedlo k prázdnému titulku obrazovky.

Přesto nebe nepadlo. Práce pokračovaly a všichni jsme věnovali větší pozornost oblastem, kde jsme předtím uklouzli.

Druhá věc

Kdysi jsem utišil otravný Checker-Bug, který implementoval techniky návrhu testů: rozhodovací tabulky a diagramy přechodu stavu.

Ty vám pomohou vizualizovat aplikační logiku a získat jasnější obrázek o možných testovacích případech, což znamená, že si můžete být jistější, že je nepřehlédnete.

Pokud potřebujete osvěžení, rozhodovací tabulka je tabulka, kde zadáváme podmínky a pravidla do sloupců a řádků. Jakmile určíme možnosti pro všechny podmínky a pravidla, vyplníme očekávaný výsledek.

Diagram přechodu stavu se používá, když máme objekt s různými stavy a objekt mění svůj stav na základě určitých podmínek. Ne vždy se to hodí, ale bylo to super užitečné, když jsem pracoval na vývoji účetní služby; objekty v těchto diagramech byly věci jako zprávy, aplikace nebo digitální podpisy.

Třetí,

lék na ten otravný Vnitřní Bug si mě vlastně našel sám. Ukázalo se, že jde o peer review testovacích případů a komunikaci po zpackaných situacích.

Jednoduché, možná i zřejmé, ale funguje to jako kouzlo.

A čtvrtý

způsob, jak uklidnit svůj mozek, bylo posouzení účinnosti a rizik. Když mi Inner Bug začal šeptat do ucha: „Zkontroluj několik dalších testovacích případů,“ vzpomněl jsem si na vedoucího svého týmu a položil jsem tři otázky:

• jak dlouho to bude trvat?
• Jaký bude přínos?
• Jaká je pravděpodobnost, že to odhalí něco důležitého?

Ano, někdy má smysl testovat na více verzích OS, s různými jazykovými nastaveními, tmavými a světlými motivy, zvětšenou velikostí písma a podobně, ale častěji jsou tyto kontroly zbytečné.

Představte si, že při provádění takových testů najdete chybu: Jakou prioritu by měla? Vzhledem ke specifickým krokům k reprodukci může být i havárii přiřazena menší priorita.

Jak dlouho budou tyto kontroly trvat? Pět až deset minut – nic moc, ale ani ten čas není vždy k dispozici. Za tu dobu jste si mohli přečíst popis průměrně velkého úkolu.

Zabalím (doufám)

Jako každý nástroj může být i váš otravný vnitřní brouk požehnáním nebo prokletím. Naučit se, jak něco efektivně používat, často vyžaduje zkušenosti a čas. A doufám, že vám tento článek pomůže rychleji zkrotit vašeho vnitřního kritika, ušetřit vám nervy a zvýšit vaše sebevědomí.

Chci vám jen poskytnout určitou podporu a možná místo toho, abyste s tím bojovali, dokud nebudete vyčerpáni, najdete způsob, jak s tím malým zvířetem pracovat a udělat z něj svého spojence.