Quality Assurance (QA), neboli zajištění kvality, je v kontextu IT projektů naprosto klíčový proces. Často je mylně redukováno pouze na „hledání chyb“ (bug hunting), ale jeho role je mnohem širší. Z pohledu projektového managementu je QA hlavním nástrojem pro řízení rizik, validaci rozsahu (scope) a zajištění spokojenosti klienta.
Úkolem QA procesu není jen najít chyby, když už je produkt hotový. Je to sada aktivit integrovaných do celého životního cyklu projektu, jejichž cílem je zajistit, aby dodávané řešení odpovídalo definovaným požadavkům – jak těm funkčním (co má systém dělat), tak těm nefunkčním (jak rychle a bezpečně to má dělat).
Klíčové role v procesu Quality Assurance
- QA Manager (Manažer kvality, vedoucí testování)
- Z pohledu projektového řízení je to partner projektového manažera.
- Je zodpovědný za testovací strategii a plán testování (Test Plan), který definuje co, kdy, jak a kým bude testováno.
- Alokuje zdroje (testery), sleduje průběh testování, reportuje stav projektu (kolik chyb bylo nalezeno, kolik opraveno, jaká jsou rizika) a finálně doporučuje (ne)přechod do produkčního prostředí (go-live).
- Tester (testovací analytik)
- Je výkonnou silou testovacího týmu.
- Na základě požadavků (specifikace, user stories) vytváří testovací scénáře (test cases).
- Provádí samotné testy, pečlivě reportuje nalezené defekty (bugy) do sledovacího systému (např. Jira) a po opravě znovu testuje (re-testuje), zda byla chyba odstraněna a zda oprava nezpůsobila novou chybu (regresní testování).
- Developer Team (dodavatelský tým, vývojářský tým)
- Ačkoliv je jejich primárním úkolem vývoj, jsou první linií QA.
- Jsou zodpovědní za opravy nahlášených chyb.
- Musí provádět základní testování vlastního kódu (viz vývojářské testy) předtím, než jej předají testerům, aby se šetřil čas a zdroje celého týmu.
Typy testování v projektu
Testování není jednorázová akce, ale probíhá v několika fázích, které na sebe logicky navazují. Každá fáze má jiný cíl a používá jiné metody.
- Developer Tests (vývojářské testy)
- Functional Tests (funkční testy)
- Integration Tests (integrační testy)
- Stress Tests, Performance Tests (zátěžové, výkonnostní testy)
- User Acceptation Tests (UAT; akceptační testy)
Developer Tests (vývojářské testy)
Toto je základní kámen kvality. Provádí je dodavatelský (vývojový) tým ještě předtím, než je funkčnost předána QA týmu. Vývojářský tým je nutno motivovat k provedení těchto testů především proto, aby ověřili, že kód lze vůbec spustit.
- Cíl: Ověřit, že napsaný kód dělá na té nejnižší úrovni to, co má.
- Příklad: Nejčastěji jde o tzv. Unit Testy (testy jednotek), kdy vývojář testuje izolovaně malou část kódu (jednu funkci, metodu nebo třídu) a ověřuje, zda pro daný vstup vrací očekávaný výstup.
- Přínos pro PM: Dramaticky snižuje počet základních chyb v pozdějších fázích, čímž šetří čas a náklady projektu.
Functional Tests (funkční testy)
Zde přebírá odpovědnost QA tým (testeři).
- Cíl: Ověřit, že jednotlivé funkčnosti systému odpovídají byznys požadavkům a specifikaci.
- Příklad: Testuje se, zda se uživatel může zaregistrovat, zda tlačítko „Uložit“ skutečně uloží data, zda formulář správně validuje chybně zadané IČO apod. Testuje se „black-box“ metodou (testera nezajímá, jak je to naprogramované, ale co to dělá).
Integration Tests (integrační testy)
Jakmile jsou jednotlivé moduly funkčně otestovány, je třeba ověřit jejich spolupráci v návaznosti.
- Cíl: Odhalit chyby na rozhraní mezi různými částmi systému nebo mezi systémy samotnými. Testují se celé procesy.
- Příklad: Samotné tlačítko „Přidat do košíku“ (funkční test) funguje. Samotný platební systém (funkční test) funguje. Integrační test ověří celý proces: Uživatel přidá zboží do košíku, přejde k pokladně, je přesměrován na platební bránu, zaplatí a systém e-shopu správně přijme informaci o zaplacení a vytvoří objednávku.
- Příklad: vytvoření návazných objektů v rámci nákupního procesu: poptávka – objednávka – dodávka – faktura – platba – zpracování bankovního výpisu. V praxi většinou každý krok provádí jiný uživatel: poptávku vytvoří zaměstnanec, který chce něco nového koupit; objednávku tvoří zaměstnanec oddělení nákupu; dodávku vytváří zaměstnanec, který zboží obdržel; fakturu účtuje zaměstnanec účtárny; příkaz k platbě zadává zaměstnanec účtárny nebo se tvoří automaticky na základě platebních podmínek; v bankovním výpise se potvrdí provedení platby – zpracovává opět účtárna.
Stress Tests, Performance Tests (zátěžové, výkonnostní testy)
Tyto testy se zaměřují na nefunkční požadavky. Jsou kritické pro budoucí stabilitu řešení. Vzpomeňte na prakticky jakékoliv uveřejnění nové aplikace pro široké použití v ČR (Online sčítání lidu 2021, systém nedostupný prakticky po celý první den 27. března; e-shop pro dálniční známky 2020, 1. prosince 2020 systém prakticky nedostupný; Centrální registr vozidel, apod.) – zde všude bychom mohli hledat příklady nedostatečných zátěžových testů.
- Cíl: Ověřit, jak se systém chová při extrémní zátěži (stress test) nebo při očekávané reálné zátěži (load test). Měří se rychlost odezvy, stabilita a spotřeba zdrojů.
- Příklad: Nástroj simuluje 1000 uživatelů, kteří se v jednu chvíli snaží přihlásit do systému. Spadne systém? Jak dlouho trvá odezva při 500 souběžných nákupech?
- Přínos pro PM: Řídí riziko selhání systému v klíčových momentech (např. při spuštění marketingové kampaně nebo na Black Friday).
User Acceptation Tests (UAT; akceptační testy)
Toto je finální fáze testování před nasazením do produkce (go-live).
- Cíl: Finální potvrzení zákazníkem (nebo koncovými uživateli), že dodané řešení odpovídá jeho očekáváním a byznys potřebám.
- Proces: Testy již neprovádí QA tým ani vývojáři, ale přímo zástupci klienta nebo vybraní koncoví uživatelé. Ti proklikávají systém podle svých reálných scénářů použití.
- Přínos pro PM: Jsou formálním milníkem projektu. Jejich úspěšné absolvování a podepsání akceptačního protokolu je podmínkou pro „go-live“ a často i pro finální fakturaci.
Výsledky UAT mohou být teoreticky tři:
- produkt je bez chyb, je podepsán akceptační protokol a produkt může být používán
- produkt je bez vážných chyb, součástí akceptačního protokolu je výčet chyb, které dodavatel vyřeší ex-post (bez další úhrady), produkt může být používán tak, jak je (chyby budou vyřešeny v blízké budoucnosti)
- produkt obsahuje vážné chyby a nemůže být používán (No–Go)