Zlepšení procesu testování

V poslední době se setkávám s dotazy kolegů, jak zlepšit proces testování bez velkých nákladů.  Všichni by chtěli zlepšovat, zvyšovat efektivitu, ale investovat do toho čas a peníze - to ne :-)
Problematikou zlepšování procesů obecně se zabývá mnoho metodik, mezi nejznámější patří CMMi, BPI, Six Sigma, ISO9001 a RUP.
Pro testování se nejčastěji uplatňují TMMi a TPI (součást metodiky TMap), základní principy jsou také popsány v syllabu pro certifikaci ISTQB.

Pokud se Vám nechce studovat metodické příručky a hledáte spíš něco praktičtějšího, zde je checklist, který používám pro zlepšení procesu testování:



1. Dám si udělat výpis všech nalezených chyb z "produkce" a u každé z nich si kladu tyto otázky:

• A - Bylo možné tuto chybu zachytit vytvořenými testovacími scénáři (bylo to pokryto, pouze ne dostatečně detailně)?
• B - Měla být tato chyba pokryta chybějícím testovacím scénářem? Vyplatilo by se scénář vytvářet/testovat vzhledem nákladům na opravu chyby? Má se případně takový scénář zařadit do regresní sady testů?
• C - Bylo vůbec možné tuto chybu v testování zachytit? (odlišnosti mezi testovacím a produkčním prostředím, lidská chyba při instalaci finální verze na produkční prostředí...)
• D - Vznikla chyba nesprávnou implementací business požadavků, nebo samotné business požadavky  neodpovídaly potřebám cílových uživatelů?
• E - V jaké oblasti produktu byla nalezena daná chyba?

Z toho vypadne zajímavá statistika, která se dá použít pro zmenšení počtu nalezených chyb "v produkci":

   A - nedostatečná kvalita testovacích scénářů (možná chybí víc kontrolních bodů, nebo scénáře nejsou dostatečně srozumitelné)
   B + E - nedostatečná test analýza (je potřebné změnit rozsah testování, případně se více zaměřit na chybové části produktu)
   C -  tady se nedá z hlediska testingu téměř nic udělat, spíše je to oblast pro řízení kvality napříč celým vývojovým procesem.
   D - problém s kvalitou zadání (zapojit testery do revize zadání ještě před začátkem programování, pokud to je možné)

2. V další fázi zjišťuji kvalitu procesu testování:

• kvalita reportování chyb - kolik bugů bylo vráceno testerům na doplnění informací? (A jaké informace nejčastěji chyběly?) Kolik bugů bylo duplicitních? Kolik bylo ve výsledku ve stavu "není chyba"?
• kvalita testovacího prostředí a testovacích dat - kolik "bugů" bylo vyhodnoceno jako "není bug" z důvodu nevalidních testovacích dat, nebo problémů s prostředím (neběžící webový server...)
• Byly odhady pro náročnost testování relevantní? Nepřesáhl se vymezený rozpočet?
• Jsou průběžné i finální výstupy z testování předávány v očekávaném formátu? (Rozumí jim projektový manažer? Jsou to ty správné statistiky, které potřebuje pro rozhodnutí GO/noGO?)
• Má test manažer vždy k dispozici aktuální stav testů/chyb, aby když ho zastaví projektový manažer s dotazem "jak na tom s produktem jsme", tak mu věděl rychle a relevantně odpovědět? Ví, který tester co testuje (zná jejich vytížení a cíl testů)?
• Mají testeři dostatečné schopnosti ke své práci (dohledávání v databázích atd.)? Testují jen podle podle postupu ve scénáři, nebo umí u toho myslet a otestovat i to, co ve scénáři není explicitně napsáno? (bohužel se občas setkávám i s  výmluvami typu "ale ono to že má být správně >výsledek< a ne >vísledek< nebylo napsáno ve scénáři")
• Nejsou mezi testy "zombie", u kterých nikdo neví, proč tam jsou a co testují? Jsou regresní testy pravidelně revidovány (a doplňovány o nové funkce produktu)?

3. V další fázi zjišťuji, jestli je proces testování, potažmo vývoje někde popsán - formalizován (včetně použitých "templates" například pro denní reporty). Pokud se firma chce ucházet o ISO certifikaci, je to prakticky nutnost. A pokud je proces popsán, dodržuje se i v praxi? Dost často to totiž zůstává jenom na papíře.

4. Poslední fází je zkoumání vztahů uvnitř týmu - pokud lidé spolu nekomunikují nebo mají dokonce k sobě osobní averzi, přes kterou se těžko přenášejí, značně se snižuje efektivita (zažil jsem situaci, kdy si jeden "bug" prohazoval tester s vývojářem 2 týdny a když jsme je donutili spolu komunikovat přes konferenční hovor, problém byl nakonec vyřešen během půl hodiny a to včetně otestování opravy). Hodně pomáhají dobré mezilidské vztahy a důvěra. Je lepší mít partu méně zkušených dobře spolupracujících lidí zapálených "pro věc", než pár zkušených profesionálů a těžkých individualistů, kterým se moc nechce dělit o své know-how (alespoň dle mých zkušeností). Občas pro motivaci a zlepšení komunikace pomáhají i "projektové hospody".

Máte další ověřené tipy? Podělte se s ostatními v diskuzi.
Human knowledge belongs to the world :-)