QA metriky, které pomáhají rozhodovat – a ty, které bez kontextu klamou
Metriky zajištění kvality (QA) mají týmu pomoci rozhodnout, kde ztrácí čas a kde vzniká největší riziko pro uživatele. Samotný počet testů, chyb ani procento úspěšných běhů to neukážou. Užitečný přehled proto spojuje výsledek v produkci, rychlost zpětné vazby a zdraví testovací sady.
Proč může zelený přehled zakrývat problém
Tým může mít tisíce automatizovaných testů a úspěšnost 99 %, jediný neúspěšný test však může patřit platbě nebo přihlášení. Jiný tým vykáže mnoho nalezených chyb, přestože velká část z nich má malý dopad a kritická chyba unikla do produkce. Čísla nejsou chybná, jen bez kontextu odpovídají na jinou otázku, než jakou potřebuje firma vyřešit.
Problém vzniká také tehdy, když se z metriky stane cíl. Pokud se tým hodnotí podle počtu napsaných testů, přirozeně přibývají jednoduché kontroly. Musí-li dosáhnout stanoveného procenta pokrytí kódu, může doplnit testy, které řádky vykonají, ale neověří důležité chování. Metrika potom roste rychleji než jistota před releasem.
Začněte výsledkem pro uživatele
Nejprve sledujte, co se děje po nasazení. Tyto údaje ukazují, zda testování a celý vývojový proces chrání důležité funkce:
- Chyby uniklé do produkce: počítejte je podle závažnosti a zasažené funkce, ne pouze jako jedno celkové číslo. Výpadek platby a překlep v patičce nemají stejný význam.
- Podíl neúspěšných nasazení: kolik nasazení si vyžádalo okamžitou opravu, návrat k předchozí verzi (rollback) nebo jiný zásah. DORA jej označuje jako change fail rate a doporučuje jej posuzovat spolu s rychlostí dodávání.
- Doba obnovy po neúspěšném nasazení: měřte dobu od selhání po obnovení služby. Kratší doba nemusí znamenat méně chyb, ukazuje však, jak rychle se tým dokáže z problému dostat.
- Selhání kritických cest: samostatně sledujte nákup, přihlášení, registraci nebo jinou cestu, na které produkt závisí. Jeden incident v kritické cestě může být důležitější než desítky menších nálezů.
DORA dnes používá pět metrik dodávání softwaru a seskupuje je do dvou oblastí: průchodnost změn (throughput) a nestabilita (instability). Nejsou náhradou za QA metriky, dávají jim však obchodní kontext: kvalita nemá pouze snižovat počet chyb, má umožnit bezpečně dodávat změny.
Měřte čas do důvěryhodného výsledku
Automatizovaný proces sestavení a kontroly (pipeline), který se rozsvítí zeleně až po dvou hodinách, poskytuje zpětnou vazbu pozdě. Průměr navíc může zakrýt pomalé běhy, proto je užitečné sledovat medián i vyšší percentil, například p95 – čas, do kterého se vejde 95 % běhů. Do měření započítejte čekání ve frontě, samotný běh i přípravu prostředí.
Praktické metriky jsou:
- čas od změny kódu po první spolehlivý výsledek,
- délka rychlé kontroly při návrhu na sloučení kódu (pull requestu) a celé regrese,
- čas od selhání testu po určení pravděpodobné příčiny,
- podíl běhů, které bylo nutné opakovat kvůli problému prostředí nebo testu.
Tyto údaje pomohou odhalit, zda zpětnou vazbu brzdí příliš mnoho end-to-end testů, pomalá příprava dat nebo nedostatek kapacity. Testovací pyramida pak není abstraktní obrázek, ale způsob, jak vhodné kontroly přesunout do rychlejší vrstvy.
Sledujte zdraví automatizované sady
Testovací sada může růst a současně ztrácet důvěryhodnost. Proto potřebuje vlastní provozní metriky:
- Podíl nestabilních testů (flaky rate): podíl testů nebo běhů, které při nezměněném kódu jednou projdou a jindy selžou. Zvolte jednu definici a mezi reporty ji neměňte.
- Falešné poplachy: selhání způsobená testem, daty nebo prostředím, nikoli chybou produktu.
- Karanténa a přeskočené testy: počet dočasně vypnutých kontrol spolu s jejich stářím a vlastníkem. Přeskočený test nesmí v souhrnu vypadat jako úspěšný.
- Čas údržby: kolik práce tým věnuje opravám testů ve srovnání s tvorbou nového užitečného pokrytí.
- Diagnostikovatelnost: u kolika selhání lze z reportu určit problém bez opakovaného lokálního běhu.
Nestabilitu je nutné měřit z historie, ne podle dojmu z posledního běhu. Praktický postup popisujeme v článku jak měřit flaky testy.
Která čísla bez kontextu zkreslují
Počet testů neříká, jaká rizika pokrývají. Deset přesných kontrol kritického výpočtu může být hodnotnějších než stovky opakujících se UI scénářů.
Procento úspěšných testů směšuje kritické a nepodstatné kontroly. Vždy je doplňte seznamem selhaných kritických cest, přeskočených testů a známých falešných poplachů.
Pokrytí kódu ukazuje, kterým kódem test prošel, nikoli zda správně ověřil výsledek. Google Testing Blog upozorňuje, že vysoké procento samo o sobě nezaručuje kvalitní testy. Pokrytí je užitečné především pro hledání neotestovaných míst, ne jako samostatný důkaz připravenosti k releasu.
Počet nalezených chyb na testera motivuje k dělení nálezů, soutěžení o jednoduché chyby a trestá lidi, kteří problémům předcházejí. Kvalita je výsledkem práce produktu, vývoje, provozu i QA, nikoli individuální bodovací soutěž.
Procento automatizace nemá univerzální cíl. Některé scénáře je levnější a užitečnější ponechat člověku; důležité je, zda automatizace zkracuje zpětnou vazbu a chrání opakovaná rizika. Pomůže rozlišení, co se nevyplatí automatizovat.
Malý dashboard je užitečnější než desítky grafů
Na začátku obvykle stačí šest pohledů: kritické chyby uniklé do produkce, podíl neúspěšných nasazení, doba obnovy, p95 času zpětné vazby, flaky rate a počet dlouho přeskočených kritických testů. U každého si dohodněte definici, zdroj dat, vlastníka a rozhodnutí, které má číslo vyvolat.
Porovnávejte hlavně trend jednoho produktu v čase. Žebříček týmů bez zohlednění odlišné architektury, rizika a frekvence releasů snadno vede k nesprávným závěrům. Když se metrika zhorší, má následovat otázka a konkrétní zásah; když pouze svítí na obrazovce, hodnotu nepřináší.
Co tím získáte
Dobře zvolená sada metrik ukáže, zda se snižuje riziko pro uživatele, zda tým dostává zpětnou vazbu včas a zda automatizované testy zůstávají důvěryhodné. Pomáhá také odlišit problém produktu od problému testovací sady nebo pipeline. Výsledkem není univerzální skóre kvality, ale podklad pro rozhodnutí, co opravit jako první.
Další krok
Vyberte jeden produkt a poslední tři až šest měsíců. Sepište, která rozhodnutí dnes děláte pouze podle pocitu, a ke každému přiřaďte jednu výsledkovou a jednu procesní metriku. Pokud údaje nemají jasnou definici nebo vlastníka, nejprve opravte sběr; teprve potom nastavujte cíl. Širší pohled na proces a slepá místa může doplnit QA audit.