Testovacia stratégia a audit

Exploratívne testovanie: čo samotná automatizácia nenájde

Automatizovaný test spoľahlivo opakuje kontrolu, ktorú sme mu zadali. Nevie však sám posúdiť všetko, čo používateľa zaskočí, pôsobí nejasne alebo vznikne v kombinácii stavov, s ktorou autor testu nepočítal. Práve tam má miesto exploratívne testovanie: tester sa počas práce učí o produkte, navrhuje ďalšie pokusy a okamžite ich vykonáva.

Nie je to náhodné klikanie bez prípravy. Dobre vedené exploratívne testovanie má cieľ, časový rámec, poznámky a záverečné vyhodnotenie. Dopĺňa automatizovanú regresiu, nenahrádza ju.

Prejdená regresia ešte neznamená dobrý produkt

Predstavte si checkout, pri ktorom automat skontroluje pridanie produktu, adresu, platbu aj potvrdenie objednávky. Všetky asercie prejdú. Človek si však môže všimnúť, že tlačidlo na mobile prekrýva klávesnica, chybové hlásenie nehovorí, ktoré pole treba opraviť, alebo návrat z platobnej brány vytvorí v košíku neistý stav.

Automat neurobil chybu. Overil presne to, čo obsahoval scenár. Problém je v hranici vopred známej kontroly: ak nikto nenapísal aserciu na zrozumiteľnosť hlásenia alebo scenár s návratom cez tlačidlo prehliadača, výsledok „passed“ o nich nič nehovorí.

Čím je aplikácia dynamickejšia, tým viac záleží na poradí krokov, dátach, oprávneniach a predchádzajúcom stave. Formálne správna odpoveď môže byť pre používateľa stále nezrozumiteľná. A požiadavka môže byť implementovaná presne, hoci samotná požiadavka nepokrýva dôležitú situáciu.

Čo znamená testovať exploratívne

Pri skriptovanom teste poznáme kroky a očakávaný výsledok ešte pred spustením. Pri exploratívnom teste máme vopred určenú misiu, nie celý zoznam kliknutí. Misiou môže byť napríklad: „Preskúmaj zmenu doručovacej adresy po návrate z platby a hľadaj stavy, v ktorých používateľ nevie, či objednávka vznikla.“

Tester potom pracuje v krátkej, sústredenej relácii. Pozorovanie z jedného kroku ovplyvní ďalší krok. Ak aplikácia po dvojitom odoslaní zobrazí nezvyčajný stav, tester ho preskúma, skúsi návrat, obnovenie stránky, inú rolu alebo prerušenie siete. Takéto vetvenie by v pevnom scenári nebolo, kým by ho niekto výslovne nenavrhol.

ISTQB v sylabe Advanced Level Test Analyst opisuje relácie riadené testovacou chartou a následným zhrnutím výsledkov. Charta udrží pozornosť na riziku, ale ponechá testerovi priestor reagovať na nové informácie.

Oblasti, kde pripravený automat často nestačí

Exploratívny pohľad prináša najväčšiu hodnotu tam, kde správnosť nie je iba jedna porovnateľná hodnota.

• Nejasná používateľská skúsenosť. Funkcia technicky pracuje, no názvy, poradie krokov alebo spätná väzba vedú človeka k nesprávnemu rozhodnutiu.
• Neočakávané poradie udalostí. Používateľ otvorí dve karty, vráti sa späť, obnoví stránku, zmení údaje uprostred procesu alebo pokračuje po vypršaní relácie.
• Kombinácie rolí, dát a stavov. Samostatné pravidlá fungujú, ale ich súbeh vytvorí konflikt. Príkladom je zľava, čiastočne vrátená objednávka a účet s obmedzeným oprávnením.
• Slabé alebo chýbajúce požiadavky. Automat vie potvrdiť zhodu so špecifikáciou. Ťažšie odhalí, že špecifikácia nerieši prerušenie procesu alebo používateľovi neponúka bezpečnú cestu späť.
• Vizuálne a obsahové nezrovnalosti. Vizuálna regresia porovná obrázky, no človek lepšie posúdi význam nešťastne zalomeného textu, zavádzajúci popis alebo neprimeranú hierarchiu informácií.
• Nové riziká po zmene. Redizajn, nový spôsob autentifikácie alebo zmena integrácie môže priniesť správanie, ktoré historické testy vôbec nemajú vo svojom modeli.

Niektoré z týchto kontrol možno neskôr automatizovať. Explorácia však najprv pomôže zistiť, čo má zmysel kontrolovať. To je iná úloha než rýchlo opakovať už známe očakávanie.

Ako pripraviť užitočnú testovaciu reláciu

Praktická relácia môže trvať 45 až 90 minút. Dlhší blok zvyšuje únavu a sťažuje presné poznámky. Pred začiatkom stačí pripraviť šesť vecí:

1. Riziko a misiu. Namiesto „otestuj profil“ určte, čo chcete zistiť: napríklad správanie rozpracovaných zmien pri strate pripojenia.
2. Rozsah. Pomenujte roly, zariadenia, prostredie a časti produktu, ktoré do relácie patria. Rovnako dôležité je uviesť, čo je mimo nej.
3. Vhodné dáta. Pripravte bežné, hraničné aj neúplné údaje. Ak tester polovicu času čaká na účet alebo objednávku v správnom stave, relácia stráca sústredenie.
4. Orákulum. Určte, podľa čoho budete správanie hodnotiť: požiadavka, obchodné pravidlo, predchádzajúca verzia, porovnateľná funkcia alebo rozumné očakávanie používateľa.
5. Spôsob záznamu. Stačia stručné poznámky s časom, použitými dátami, prostredím a dôkazom. Pri zlyhaní pridajte kroky, log, snímku alebo sieťovú požiadavku podľa typu problému.
6. Záverečný debrief. Po relácii oddeľte potvrdené chyby, otázky k požiadavkám, nápady na ďalší test a oblasti, ktoré sa nestihli preveriť.

Výsledkom nie je počet kliknutí. Je ním lepšia mapa rizík a rozhodnutie, čo opraviť, čo ešte overiť a čo zaradiť do opakovateľnej regresie.

Ako spojiť exploráciu s automatizáciou

Tieto prístupy sa posilňujú. Automatizácia môže pred reláciou vytvoriť účet, naplniť košík alebo dostať aplikáciu do zložitého stavu. Tester potom neplytvá časom opakovaním známej prípravy a sústredí sa na nové správanie.

Opačným smerom putujú stabilné zistenia. Keď explorácia odhalí dôležitú chybu a tím vie jednoznačne opísať očakávaný výsledok, vznikne kandidát na automatizovaný regresný test. Nie každé zistenie treba automatizovať: jednorazová kozmetická odchýlka alebo kontrola vyžadujúca ľudský úsudok môže zostať v manuálnom rozsahu. Pomôže výber toho, čo sa neoplatí automatizovať.

Rozumný rytmus môže vyzerať takto: krátka automatizovaná kontrola pri každej zmene, cielená explorácia novej alebo rizikovej funkcie pred releasom a občasná širšia relácia nad miestami, ktorých sa bežná regresia dlho nedotkla. Frekvencia závisí od rizika a tempa zmien, nie od univerzálneho kalendára.

Kto má exploratívnu reláciu viesť

Exploráciu nemusí robiť iba človek s pracovnou pozíciou tester. Vývojár pozná technické hranice a vie cielene skúšať súbeh udalostí. Produktový človek rozumie obchodným výnimkám. Dizajnér si skôr všimne nejasnú spätnú väzbu a pracovník podpory pozná situácie, s ktorými sa zákazníci reálne trápia.

Skúsený tester prináša testovacie techniky, odstup a schopnosť systematicky meniť jednu podmienku. Veľmi účinná preto býva párová relácia: tester s vývojárom, doménovým expertom alebo dizajnérom. Jeden človek ovláda produktový kontext, druhý vedie experiment a dokumentuje zistenia.

Roly sa oplatí striedať. Autor funkcie môže nevedomky opakovať zamýšľaný postup a prehliadnuť alternatívu, zatiaľ čo človek bez kontextu nerozpozná dôležité obchodné pravidlo. Krátky úvod k riziku a následný debrief spoja oba pohľady bez toho, aby sa relácia zmenila na neorganizovanú skupinovú kontrolu.

Pri opakovaných reláciách zdieľajte aj použité heuristiky a nezodpovedané otázky. Ďalší človek tak nezačne od nuly, no stále má priestor preskúmať produkt inou cestou a spochybniť predchádzajúce predpoklady.

Čo exploratívne testovanie nenahrádza

Explorácia nie je dôkaz úplného pokrytia. Dve relácie vedené rôznymi ľuďmi nebudú totožné a bez poznámok sa zistenie ťažšie reprodukuje. Výsledok závisí od znalosti domény, zvedavosti aj schopnosti klásť dobré otázky.

Nenahrádza ani špecializované meranie výkonu, bezpečnostné posúdenie, kontrolu prístupnosti či právne hodnotenie. Môže na problém upozorniť, no na potvrdenie sú často potrebné vhodné nástroje a odborný postup. Pri pravidelných regresiách zase automatizácia poskytuje rýchlosť a konzistentnosť, ktorú manuálna relácia nedokáže hospodárne zopakovať.

Preto má mať explorácia vlastníka a výstup. Ak tím iba povie „niekto to prekliká“, aktivita sa pri časovom tlaku stratí a jej kvalitu nemožno posúdiť.

Praktický prínos pre tím

Dobre zacielená relácia dá tímu informácie, ktoré pred pripravením testu nepoznal. Môže odhaliť medzeru v požiadavke ešte predtým, než sa z nej stane séria chybných implementácií, alebo upozorniť na používateľský problém, ktorý technické metriky neukazujú.

Zároveň spresňuje automatizačný backlog. Namiesto rastu sady podľa počtu dostupných testovacích prípadov tím pridáva kontroly tam, kde už vidí konkrétne riziko. Takáto kombinácia znižuje falošný pocit istoty z vysokého počtu zelených testov a dáva testovacej stratégii spätnú väzbu z reálneho používania.

Ďalší krok

Vyberte jednu nedávno zmenenú alebo používateľsky citlivú funkciu. Spíšte pre ňu jednoriadkovú misiu, vyhraďte 60 minút a po relácii rozdeľte zistenia na chyby, otázky, nové riziká a kandidátov na regresiu. Už prvá dobre zdokumentovaná relácia ukáže, čo vaša dnešná automatizácia overuje — a o čom zatiaľ nič nehovorí.