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.
Jak ke quality assurance přistupovat?
Kvalitu projektu i finálního produktu ovlivňuje aktivita každého člena týmu. Je velmi důležité mít dobře nastavené standardy, procesy a dohlédnout na to, že je každý svědomitě naplňuje. Z praxe je totiž zřejmé, že ne vždy tomu tak je. Doporučujeme mít dedikovanou osobu – QA Engineera – který bude celou aktivitu zaštiťovat. Jinými slovy by tato role měla hlídat, aby experti z daných oblastí tyto standardy a procesy nastavili správně, a následně by měla zajistit proškolení potřebných osob. V dalším kroku je pak zapotřebí dohlížet na dodržování těchto procesů.
Níže uvádíme konkrétní kroky, které je potřeba v rámci Quality Assurance vykonat napříč SDLC. O ty by se měly postarat odpovídající role a QA Engineer pak poskytnout podmínky pro to, aby tomu tak bylo.
Na konci článku pak najdete odkaz ke stažení QA checklistu, abyste jej mohli mít na cestě za zvýšením kvality SW vývoje neustále po ruce.
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í.
Pojďme přivést vaše nápady do digitálního světa.
Budete překvapeni, co spolu dokážeme vytvořit.