Nestíhám to otestovat - co teď?

Kolem prioritizace testů se již popsalo hodně článků a metodik - od těch jednoduchých až po vědecké přístupy. Přesto má řada test manažerů problém, jak správně prioritizovat testy a obecně řešit krizové situace v testování.
Nejdřív základy:


1. Nemůžete otestovat vše. To ani nejde.
2. Odhadnete náročnost na proces testování na 100 mandays. Pokud si myslíte, že těch 100 MD reálně dostanete, máte buďto velmi hodného (a tudíž neefektivního) projekťáka, nebo patříte mezi naivní optimisty.
3. Ve fázi testování se naleznou tak závažné chyby, že se musí předělat architektura, termín komerčního spuštění se ale neposune (třeba kvůli již zahájené reklamní kampani). S tím prostě musíte jako test manažer počítat.
4. Vypadne vám lidský zdroj - třeba testera sejme auto dva dny před začátkem testů a nemáte šanci sehnat náhradu. S tím také musíte počítat.

Způsob řešení těchto malérů záleží na fázi, kdy zjistíte, že nestíháte.

Pokud to víte před začátkem testovacího úsilí (klasická situace, kdy test manažer žádá ve fázi plánování projektu o 100 MD, projekťák se zamyslí a řekne - ne, 70 MD), nezbývá nic jiného, než omezit rozsah testování. Čili říct "To nestihneme, takže tohle, tohle a tohle otestujeme v plánovaném rozsahu, tamto jenom základní funkce a na jiné nebude čas". No a pak po domluvě s projektovým manažerem tento nástřel plánu poupravit, aby byly obě strany spokojené (teda spíš ten projekťák, u test manažera stačí že se to dá za nových podmínek zvládnout).

Horší případ nastává, když to zjistíte až v průběhu testování. Důvodů může být více - od "interních testerských" (podstřelené odhady, přílišná byrokracie v procesu testování...) až po "testeři v tom jsou nevinně" (náhlá změna architektury, přidávání dalších nevyhnutelných funkčností, na které se jaksi zapomnělo...)
Tady se mi osvědčil následující postup.

Jako první věc musíte vědět, co jsou pro projekt "kritické" funkčnosti (tzv. no-go nebo showstoppery), "zásadní" funkčnosti (velmi nepříjemné pokud se nedodají včas) a "ostatní" (business to potřebuje, ale přežije týdenní odklad). Podle toho stanovte priority - pořadí jednotlivých scénářů v jakém se budou testovat. Nejkritičtější věci musí být testovány jako první, aby byla případná chyba odhalena a opravena co nejdříve (a pokud případná oprava rozbije i to co neměla, aby bylo kdy to dát zase do pořádku).

Pokud zjistíte, že nestíháte ve fázi test analýzy nebo designu, hodně času se dá ušetřit tím, že "osekáte" popis scénářů na nejnutnější minimum (pokud si to můžete dovolit - audit, metodika...) - když stačí na popis scénáře "objednejte přes e-shop pračku pro zákazníka v Praze a ověřte že je objednávka správně zpracována", nechte to tak a nerozepisujte to do kroků - budete ztrácet drahocenný čas, zvlášť pokud je test analytik/designér současně testerem a tudíž ví co má dělat.
Stejně tak nemusíte nutně do scénářů přidávat vhodná testovací data (je to také velký žrout času), ať si je tester iniciativně najde sám (musí to ovšem umět).
Zkracováním scénářů sice ztrácíte kontrolu nad detaily testování a musíte více věřit svým testerům, že se s tím poperou, ale můžete ušetřit opravdu značné množství času.

Pokud nestíháte až ve fázi probíhajících testů, tak není jiná možnost, než jít striktně po prioritách scénářů - nejkritičtější věci testovat první, pak ty méně kritické... kolik stihnete, tolik stihnete (případně test manažer může málo kritické scénáře co se určitě nestihnou otestovat "vyloučit" z testování, aby mu to nezkreslovalo statistiky).
Co se nestihne otestovat, test manažer musí reportovat vyšší instanci. Nicméně ne stylem "z funkčnosti objednávání spotřebičů jsme nestihli otestovat 30% scénářů priority 2", to je zadavateli platné jak mrtvému zimník. Musí se to pěkně detailně - např. "nestihli jsme otestovat objednání více stejných druhů praček na jedné objednávce, stejně tak proces neuznané reklamace pračky". S tím už stakeholder může nějak naložit (třeba na tu situaci připravit uživatele aplikace nějakými "krizovými" pracovními postupy).
Ve fázi testů nicméně NIKDY nezkracujte hlášení o nalezeném incidentu ("nemám čas přiložit log, ať si to vývojář dohledá sám") - neušetříte nic, většinou pak řešení trvá ještě déle, než když to děláte pořádně.

Na závěr pár tipů z praxe.

Je fajn, pokud počáteční priority scénářů stanoví již test analytik (třeba "základní scénáře" odliší od "exotických scénářů" jinou prioritou).

Jestli budete mít priority scénářů "Critical", "Major", "Minor" nebo 1,2,3, nebo A.B,C je prakticky jedno - jen si dejte pozor na to, aby té prioritě všichni rozuměli (1 je nejvyšší, nebo nejnižší priorita?). Stejně tak doporučuji nepojmenovávat priority stejně, jako jsou severity chyb (pokud bude náhodou Critical chyba nalezena v Minor scénáři, tak se na to business bude koukat hodně divně).

Seznam možných priorit nemějte moc velký - tak maximálně 3, nebo 4 možné hodnoty a u každé mějte nějakou "definici" , třeba priorita 1 = kritické funkčnosti. Setkal jsem se na jednom projektu s 21 prioritami, to sice bylo srozumitelné ve smyslu "test s prioritou 11 otestuj dřív než test s prioritou 12", ale chyběla tam vazba na rizika (jak moc je to problém, když neprojde test s prioritou 12)?