Zvyšte kvalitu svého SW vývoje – QA checklist, bez kterého to nepůjde

Jak si pohlídat kvalitu softwarového řešení? Spoléhat se pouze na testing se nemusí vyplácet. V závislosti na náročnosti projektu je totiž potřeba mít pod kontrolou hned několik kritických kroků a aktivit. Ty zastřešuje quality assurance – přístup, který je v IT světě stále diskutovanější. Zabývá se mimo jiné definováním standardů kvality u projektu, přípravou relevantní dokumentace, risk managementem, ale hlavně zajišťuje, že jsou veškerá očekávání klienta splněna. 

Správný přístup k zajištění kvality ve své podstatě není žádnou alchymií, řada manažerů, testerů či projektových manažerů v něm však tápou. Pokud je to i váš případ, jste tu správně – v článku se podíváme na všechny kroky, které je potřeba v rámci QA vykonat. Ty se odráží od checklistu, který vytvořil Filip Kadlec, Quality Assurance Competence Manager & Delivery Manager v INVENTI a Jakub Wasilewski, Test Manager & Product Owner of Release, Commerzbank.

Shromažďování a sběr požadavků

To je prvním krokem, který by neměl opomenout žádný tým vyvíjející software. Vždy je potřeba od zadavatele zjistit, co vlastně chce získat. Když přijdete do prodejny automobilů a řeknete, že chcete nový vůz, můžete klidně dostat trabant i přesto, že jste chtěli bavorák. To se stává, když s vámi prodejce neprojedná, jaké auto vlastně chcete a co má umět. 

Přesně tak to funguje i u digitálních řešení. Když se zadavatelem neprodiskutujete jeho očekávání, můžete vyvíjet něco, co ani nechtěl. Pro zajištění maximální výsledné kvality je potřeba ověřit, že máte všechny funkční i nefunkční požadavky a také že je váš tým pochopil správně. 

Se sběrem požadavků pak souvisí i sepsání veškerých rizik včetně jejich dopadů, priorit, pravděpodobnosti a návrhu jejich řešení. Ať už chcete nebo ne, rizika se nevyhýbají žádným projektům. Buďte na ně připraveni hned v začátcích, a získáte významnou strategickou výhodu. 

V neposlední řadě je potřeba zajistit strategii, roadmapu a plán pro sledování kvality a kontrolu požadavků. Chaotičnost je častou příčinou prodlev ve vývoji a někdy dokonce celkového pádu projektu.

Design

Jakmile máte shromažďování a sběr požadavků za sebou, můžete se pustit do designu. V této fázi se navrhuje architektura, řešení a způsob, jakým se bude projekt dodávat. Také je třeba zvalidovat, že sestavený tým dokáže zakázku dobře odbavit. Jen máloco komplikuje vývoj více, než když v polovině projektu zjistíte, že chybí pracovní síly. 

Zrevidujte návrh architektury, strategii a plán vůči požadavkům od zadavatele. Také překontrolujte roadmapu projektu, zda zahrnuje všechny kroky, které bude nutné učinit. V této fázi by měl být také vyhotovený diagram toku dat.

Implementace

Fáze implementace se prolíná s předchozím bodem, protože mimo jiné souvisí se správnou informovaností celého týmu – všichni musí mít stejnou vizi, vidět ten stejný cíl a vědět, kdy se co bude dodávat. Pakliže se ve světě vývoje softwaru pohybujete dlouhodobě, jistě jste už i vy zažili, že front end tým měl hotovou nějakou funkcionalitu, ale dlouho se ještě čekalo na to, než ji dodá i back end. A to je důsledek selhání implementace.

Jednotliví členové týmu musí být také seznámeni se svými rolemi a odpovědností, aby mezi nimi nevznikaly třenice. Odpovědnosti tedy vždy definujte dopředu. 

Dále by mělo proběhnout nastavení entry/exit kritérií napříč týmem. Definují specifické podmínky pro zahájení a ukončení určitých fází projektu. Entry kritéria mohou souviset například s dosažením specifické úrovně kódu nebo dokončení nezbytné dokumentace, zatímco exit kritéria s mírou pokrytí pomocí testů, absencí chyb nebo splnění specifických výkonnostních metrik. 

Implementace zahrnuje také domluvu na pravidelných synchronizačních interních i externích schůzkách. Pro zajištění maximální kvality vyvíjeného řešení je komunikace napříč týmem naprosto klíčová, pro více informací si přečtěte článek Jak na quality assurance v SW vývoji. Také na pravidelné bázi prioritizujte, ať všichni ví, čemu je v aktuálních fázích třeba dávat pozornost. 

V neposlední řadě je nutné mít nastavený reporting na základě domluvy interního týmu i zadavatele a kontrolovat výstupy a další kroky pravidelných QA auditů.

Nasazení

Ve fázi nasazení si posviťte na to, že máte nastaven proces release managementu. V opačném případě se totiž můžete dostat do problému v rámci nedostatečné kvality softwaru, komunikace a dokumentace. Nehledě na to, že mohou vzniknout i bezpečností rizika.

Také zajistěte podporu po nasazení. Pokud tak neučiníte, po spuštění můžete zjistit, že je v aplikaci chyba, ze které už může být mimořádně obtížné vykličkovat

Dalším tématem jsou release notes. Tyto poznámky se zpravidla neřeší u projektů, kdy je klient zasazen do týmu. Když je však projekt formálnější, jsou velmi důležité a může se jednat o obsáhlé dokumenty, ve kterých jsou do detailu popsané funkcionality.

Poslední dvě otázky v rámci nasazení, které najdete v checklistu, jsou „Jak řešíme uživatelské testování a testování po nasazení?“ a „Jak pracujeme se zpětnou vazbou?“ Ty se do jisté míry prolínají s dalším bodem. QA zahrnuje i testování, někteří však mezi těmito dvěma obory nedělají rozdíl. Existuje tedy? Přečtěte si naše stanovisko zde.

Testování

Prvním bodem v rámci testování je testovací dokumentace. Ta se by se neměla vyhnout žádnému projektu, je však otázkou, jak moc je projekt formální. Vždy je lepší detailnější dokumentace i přesto, že je náročnější na údržbu. Když totiž máte dlouhý projekt, na jeho konci můžete dospět k tomu, že nebudete mít lidi. Dobře zpracovaná testovací dokumentace vám umožňuje lidi pohodlně onboardovat za procesu. A nemusí se jednat pouze o testery, mohou to být i klasičtí uživatelé, kteří vám pomohou například s regresními testy.

Také musí být nastaven a realizován defect management. Je důležité zjistit, proč defekty vznikají a vrhnout se do prioritizace a práce s riziky. Každý tester by pak měl ovládat základní metodiky risk managementu. Samotný management rizik je však spíše záležitostí projektových manažerů.

I u testování je potřeba pracovat se zpětnou vazbou od samotného zadavatele projektu, ale i reálných uživatelů. Ta vás totiž může pravidelně směrovat k optimálnímu výsledku. QA sahá až do reportingu, který by měl být zpracováván v dostatečném detailu a frekvenci.

Údržba

Posledním bodem na seznamu je údržba. V projektu by vždy měl být někdo, kdo ji bude plánovat. Jedním z úkolů QA manažera je domluvit se s jednotlivými členy na tom, jak se údržba bude dělat – a to hned na začátku projektu.

Do tohoto bodu se pak prolíná také již zmiňovaný reporting, práce se zpětnou vazbou a zajištění supportního týmu, který by měl mít dostatečné znalosti, aby se projekt z dlouhodobého hlediska udržoval kvalitně.

Celý QA checklist doporučujeme stáhnout pod odkazem níže. Jsou v něm přehledně vypsány jednotlivé kroky, které si můžete odškrtávat. Ať už budete řešit QA pro jakýkoli projekt, vždy ho mějte u sebe – tak vkročíte na cestu za opravdu kvalitním softwarem, který si jeho uživatelé zamilují.