Přejít na obsah|Přejít k hlavnímu menu|Přejít k vyhledávání
Myslím, že s touhle radou už se v životě setkal každý z nás. Tato triviální operace často může vyřešit aktuální problém, ale z hlediska testování software bychom se k ní měli uchylovat až v krajních případech. Co by měl tester udělat před tím, než zmáčkne tlačítko reset? Právě o tom si teď něco povíme.
Systém (nebo aplikaci) si můžeme představit jako uzly, kterými uživatel postupně prochází. Někdy se může dostat do slepé uličky, odkud není návratu. V jiných případech zase může dojít například k zahlcení systému, nebo provedení operace, která systém zacyklí do nekonečné smyčky.
Na uvedeném obrázku vidíme, že uživatel nemá v případě neúspěšného pokusu o přihlášení, možnost vrátit se zpět na přihlašovací formulář. Nezbývá mu tak nic jiného, než se „restartem“ vrátit na úvodní obrazovku.
Opačným extrémem by bylo uživatele na úvodní obrazovku přesměrovat přímo, bez zpětné vazby. Vždy by mělo být jasné, k jaké chybě došlo. V ideálním případě by uživatel měl mít také možnost situaci nějak vyřešit.
Restartování nám může pomoci vrátit systém nebo aplikaci do výchozího stavu. Aplikace si ale často můžou stav před restartem „pamatovat“, takže je důležité těmto situacím předcházet.
Vytvořte si schéma aplikace a při testování zaznamenávejte průchod jednotlivými uzly, obzvláště u exploratory testů. U náhodně objevených chyb vám toto může výrazně pomoci při identifikaci příčin a zároveň můžete vývojářům předat kroky k zreprodukování, což ušetří čas při debugování.
Stejně tak si můžete připravit různé cesty a tím „generovat“ jedinečné testovací scénáře. Myslete na to, že takové schéma je potřeba udržovat aktuální - můžete si například aktualizaci schématu přidat do DoD nebo jako jeden z bodů testovacího scénáře.
Výhodou schématu aplikace je to, že si můžete vizualizovat celou strukturu a objevit „slepé uličky“.
Neošetřené chyby nebo výjimky mohou také způsobit, že se aplikace dostane “do úzkých”. I v tomto případě by ale uživatel měl být o chybě informován a mít možnost situaci vyřešit. Chyba neznamená, že by aplikace měla přestat reagovat na uživatelské vstupy nebo fungovat úplně.
Testování se přeci jenom zajímá o kvalitu softwaru jako celku a použitelnost nebo uživatelská přívětivost je důležitou součástí kvality.
Pokud na prostředí, ve kterém aplikace běží, dojdou systémové prostředky, není moc možností, jak zasáhnout. Proto jsou důležité výkonnostní (zátěžové) testy, které by měly slabiny aplikace nebo systému odhalit ještě před nasazením na “ostré” produkční prostředí.
Systémové integrační testování nám pomůže odhalit nedostatky v interakci jednotlivých komponent, modulů, nebo například služeb třetích stran. Odstavením některé z částí můžeme simulovat výpadek nebo nedostupnost dané komponenty.
Restartem můžeme přijít o důležité informace. Některá data mohou být uložena v operační paměti, nebo můžeme přijít o soubory, které jsou zamčené právě probíhajícím procesem.
Před restartem proto sesbírejte co nejvíce (užitečných) informací, jako jsou logy nebo konfigurace aplikace a prostředí, na kterém běží.
Důležité je také umět popsat kroky, které k dané chybě vedly. K tomu nám může pomocí zápis všech kroků, které provádíme, nebo třeba nahrávání obrazovky.
Děkujeme! Odebírání newsletteru bylo úspěšně přihlášeno.
