Existuje rozdíl mezi quality assurance a testingem?

Koncepty quality assurance a testingu jsou mnohdy vnímány jako synonyma. Vždyť přece oba mají ten stejný cíl – zajistit kvalitu výsledného produktu. Navíc v jejich rámci často probíhají ty stejné aktivity a využívají se totožné nástroje. Nenechte se však zmást, je mezi nimi totiž rozdíl, který vám může markantně ušetřit náklady. V článku si jej osvětlíme na konkrétním příkladu.

Častý, avšak neefektivní proces

Většina projektů začíná stejně – na začátku dostanete skvělý nápad, který podrobíte produktové či byznysové analýze. Necháte si jej validovat ve smyslu životaschopnosti a cost-benefit analýzy a následně jej přesouváte do analytické fáze.

Proběhne návrh projektové roadmapy, odhad budgetu pro vývoj a následné sestavení týmu. Na začátku projektu je tým seznámen s analýzou a tím, co má dodat, a vývoj může začít. V lepším případě je k plánování přizván i člověk, který bude odpovědný za testing. Častější je však zapojení testerů až ve chvíli, kdy mají vývojáři něco hotového. 

Nyní nastává scénář, který mnozí z nás bohužel dobře znají. Vývoj nestíhá, požadavky jsou neúplné a nejasné a navíc se v čase z různých důvodů odklonily od analýzy. V momentě, kdy se projekt překlopí do fáze testingu, je aplikace nejen úplně jiná, ale současně plná bugů. Následuje stresující období pro celý tým – neustále se mění priority, shání se další finanční prostředky a posouvají se termíny. Pokud jste něco podobného zažili, věřte, že nejste sami.

Jde to jinak? Lépe?

Rozhodně ano, ale budete muset změnit svoje myšlení a přístup k celému procesu. V první řadě je potřeba si uvědomit, že ani sebelepší produkt na trhu neuspěje, pokud jeho výsledná implementace nebude odpovídat potřebám koncového uživatele. Kvalita vždycky bude mít navrch oproti kvantitě – zaměřte se na ni a dosáhnete skutečně efektivního řešení, které bude zákazníkům přinášet přidanou hodnotu.

Kvalita našich výstupů je pro nás na samotném vrcholku žebříčku priorit. Jak jí dosahujeme?

Na výsledku se vždy podílí celý projektový tým, včetně testingu. Participace všech členů je pro nás nesmírné důležitá již při úvodní analýze a startu projektu. Abychom byli více detailní, kontrolujeme pak například:

• Validaci výstupů produktové analýzy.
• Validaci výstupů technické analýzy.
• Existenci systémového návrhu, C4 modelu aj.
• Dohodu týmu na potřebných vstupech a výstupech analýzy, vývoje, testování či DevOps.
• Existenci projektové roadmapy a zda ji každý člen týmu zná.
• Znalost povinností a odpovědností každého člena týmu.
• Jasné definování správného zadání.
• Existenci obousměrné provazby mezi issue, unit testy, tradičními testy a produktovou analýzou.
• Nastavená pravidla pro testování pokrytí kódů.
• Jasné stanovení přístupu k unit testům vývoje.
• Existenci reportů z unit testů.
• Nastavená pravidla pro verzování.
• Nastavená pravidla a procesy pro releasování.
• Účast každého člena týmu při tvoření odhadů.
• Pravidelnou validaci rizik na všech úrovních vývoje projektu.
• Plány pro řešení rizik.

Testingové činnosti jsou samozřejmou součástí procesu. V rámci quality assurance však dohlížíme na vše jak před samotným testováním, tak po něm. Zajišťujeme tak:

1. že se nevyvíjí něco, co cílový uživatel nechce či nepotřebuje,
2. že během vývoje nedochází k postupům, které by později projekt mohly zbrzdit nebo zkomplikovat, což vede ke zvýšení nákladů.

Vývoj i testing pak řídíme podle přesně definovaných a zvalidovaných požadavků. Čas každého člena týmu je cenný a nechceme, aby kdokoliv dělal cokoliv neefektivně.

Tradiční přístup vs. přístup s QA

Zdá se vám, že zajistit všechny body z předchozího odrážkového seznamu představuje spoustu práce a zbytečné protahování projektu? Srovnejme si tradiční přístup vs. přístup s QA, abychom znázornili časovou a finanční úsporu, kterou druhý přístup přináší.

Tradiční přístup

• Analytik sepíše nejasné zadání.
• Vývojáři vymyslí řešení podle své zkreslené představy.
• Tester neví, co a kde testovat kvůli nejasnému zadání.
• Tester se domluví s analytikem.
• Tester najde chybu, protože implementace nebyla v souladu s požadavkem.
• Vývojář musí řešení přepracovat.
• Opětovné testování.
• Nasazení k UAT/produkci.
• Požadavek se vrací, protože neodpovídá požadavkům zákazníka.
• Analytik upřesní zadání.
• Vývojář opět přepracovává.
• Opětovné testování.
• Opětovné UAT.
• Release.

Spočítejme si celkovou standardní časovou investici tradičního přístupu:

• příprava ze strany analytika:  4 hodiny,
• domýšlení vývojáře:  1 hodina,
• programování vývojáře:  4 hodiny,
• psaní scénářů:  1 hodina,
• schůzka s analytikem:  30 minut,
• testování:  30 minut,
• řešení chyb:  15 minut,
• oprava vývoje:  2 hodiny,
• testování:  30 minut,
• kompletní proces nasazení:  1 hodina,
• UAT:  30 minut.