Quality Assurance (QA) a Scrum

Scrum je agilní přístup k vývoji softwaru. Soustředí se na dosažení cílů v krátkých vývojových iteracích (2–4 týdny). Scrum týmy jsou charakteristické zejména ve dvou věcech – jsou multifunkční (obsáhnou všechny nezbytné dovednosti potřebné pro svou práci) a jsou samoorganizující (očekává se, že tým sám přijde na to, jak nejlépe dělat svou práci. Jaká je role QA v Scrum? Je to mnohem více než jen psaní testovacích případů a oznamování chyb týmu.

QA někdy těžko nalézá svou roli v Scrum. Velmi záleží na pozici a roli QA ve struktuře firmy, hodně je důležité zahrnutí QA / testování do plánování sprintů („lze ukusovat jen tolik, kolik za sprint ukousnout lze“), případně vytváření menších úkolů, které míří k jasnému cíli. Každé Scrum QA / testování je jedinečné a odvislé od kultury firmy. Je těžko srovnatelé se Scrum QA / testováním jiné firmy.

Aktivity v Scrum jsou vykonávány v pořadí, v jakém je aktuálně zapotřebí (tj. asynchronně). Na rozdíl od syncrhonních činností např. vodopádového modelu. V tradičních modelech vývoje je role QA vesměs jasně definovaná, jasná, unifikovaná. Agilní metody vývoje si s unifikací příliš nerozumí a protože mnoho QA specialistů se do agilního vývoje dostává se zkušenostmi převážně s tradičním vývojem, setkávám se s dotazem, jak QA efektivně zapojit do Scrum sprintu. Jakou úlohu zajišťuje „zajištění kvality (jakosti)“ v agilním Scrum vývoji?

Nejen psaní testovacích případů

U tradičního vodopádového modelu vývoje se zapojuje QA / testování převážně až na samém konci projektu – jakmile je programování „dokončeno“. QA / testování v takovém případě poměrně direktivně lpí na dodržení na začátku vývoje definovaných požadavků. Nicméně v Scrum QA / testování nehraje roli jen při procházení a hodnocení testovacích případů vytvořených na základě specifikaci požadavků (resp. User Stories) a v ohlašování nalezených chyb.

V Scrum týmu se QA podílí na plnění různých povinností ve spolupráci s ostatními členy týmu. Do projektů jsou zapojeni od samotného začátku, kdy úzce spolupracují s business analytiky i vývojáři. QA se v mnoha ohledech prolíná s business analytiky, mají mnoho stejných úkolů, potřebných dovedností i cílů. Obecně se nedá ve Scrum zajištění kvality přenést jen na vymezené oddělení – z tohoto pohledu má velice blízko k TQM (Total Quality Management / Komplexní management jakosti) systému řízení jakosti, tj. úplnému zapojení všech zaměstnanců (od marketingu až po servis, včetně administrativy, ostrahy, recepce, …) do zajištění kvality narozdíl od tzv. štíhlé výroby (Lean Production), která je vhodná spíše pro sériovou výrobu (nemohu však říci, že podstatu štíhlé výroby nelze využít i při vývoji SW; jen jsem zatím nenalezl vhodné best bractises; rozhodně oceňuji hlavní myšlenku „Cena – Náklady = Zisk“, zatímco mnoho SW firem tvoří podle modelu „Náklady + Zisk = Cena“). Očekává se, že tým v Scrum je multifunkční – business analytici, vývojáři, testeři, … všichni spolupracují a podílejí se na tvorbě kvality. V Scrum členové QA mohou již od začátku projektu připomínkovat, dělat rozhovory s cílem objasnit požadavky, hrát roli koncového klienta (majitele, uživatele, …) apod.

Odhad možných scénářů

Analytici QA jsou velmi dobří při vytváření scénářů, testovacích případů na základě požadavků uživatelů. Oproti vývojářům vynikají mj. v identifikaci negativních scénářů. Vývojáři mají častěji sklon scénáře vnímat pozitivněji a odpoutávají se od negativních scénářů. QA tak může přispět realističtějším pohledem, neboť je vhodné, když jsou zohledněny jak pozitivní, tak negativní scénáře.

Jedním z hlavních úkolů QA může být testováním poskytnout zpětnou vazbu zákazníkovi. A samozřejmě získávat zpětnou vazbu o zákazníků. Tím se předpokládá úzká spolupráce s Product Ownerem – člověkem jenž zodpovídá za priority a za to, co se bude v příštím sprintu implementovat. QA sice neříká, co se bude implementovat v příštím sprintu, ale významně přispívá k tomu, aby Product Owner o něčem takovém mohl přijmout vědomnější rozhodnutí. Je však možné, že QA tým bude požádán, aby zastupoval Product Ownera.

QA a vývojáři by měli sedět a spolupracovat s vyvojáři společně jako tým, aby lépe pomohli zlepšit kvalitu projektu. Může dojít ke spárování QA s vývojáři při psaní případů pro unit testy a kriterií přijatelnosti. Čím více tyto role spolupracují, tím jasnějšími se stávají společné požadavky. QA svými podněty může vývojářům zvýšit efektivitu a úsporu času, který vzniká v důsledku nepochopení požadavků anebo opomenutí důležitých skutečností.

V Scrum i vývojáři mohou pomoci QA / testerům. Protože celý tým hraje na jednom hřišti, vzájemně si pomáhají na základě potřeb a dostupnoti členů. Nejenže se tak urychluje tempo práce, ale také se vytváří rovnováha v týmu a společná odpovědnost za úspěšné dokončení projektu.

Zpětná vazba vývojářům

Cyklus build – test – fix tradičního vodopádu nutí týmy donekonečna opakovat spoustu další, často zbytečné, práce. Toto je mnohem jednodušší v Scrum, pokud QA a vývojáří spolupracují v průběhu celého procesu. Vývojáři mohou s QA konzultovat o kriteriích přijatelnosti a o očekáváném chování každé funkce z pohledu uživatele. Tím se testuje a opravuje průběžně během cyklů.

Automatizace regresního testování

Zejména u Scrum projektů platí, že pokud můžeme regresní testy automatizovat, automatizujme. Automatizované regresní testování posyktuje opakovatelnost, konzistenci a lepší pokrytí testů. O to více to platí u krátkých cyklů (2–4 týdny), protože v tak krátkém cyklu QA má málo času na otestování aplikace. Během krátkého období musí testeři otestovat funkčnost nových funkcí a samozřejmě provést regresní testy funkcí, které byly implementovány dříve. Automatizované testy mohou snížit celkový časový tlak na QA.

Automatizované testy jsou vhodné k získání zpětné vazby např. při implementaci CI (Continous Integration). Při každém novém buildu mohou být provedeny automatizované testy, které poskytnou prakticky okamžitou zpětnou vazbu o tom, které funkce nefungují správně. Pokud QA nemá testy automatizované, musí provádět testy ručně, což může být jednak monotónní a jednak náchylné k přehlédnutí chyb. Automatizované testování umožňuje věnovat více času průzkumu okrajových případů nově vyvíjených funkcí a provádět testování mnohem efektivněji a účinněji.

Obrázek: Při implementaci CI jistě využijeme open-source nástroje Jenkins, jenž je schopen automaticky buildovat, spouštět automatické testy, reportovat aj.]

Analýza uživatelských požadavků

QA je svým způsobem zastoupením klienta (majitele, uživatele, …). QA může být vynikajícím zdrojem business požadavků, protože jeho členové s produktem do kontaktu přicházejí z pozice koncového uživatele a z tohoto pohledu lépe vnímají jejich možné požadavky. Tím mohou být užitečným zdrojem informací zejména pro Product Ownera.

DoD – Definition of Done

V Scrum je velmi důležité mít jasno, kdy je hotovo (tzv. DoD – Definition of Done). DoD není nic jiného, než jednoduchý seznam týmem definovaných kriterií dokončení. Obvykle tento seznam obsahuje věci, jako např. psaní kódu, unit testování, funkční a regresní testování, schválení Product Ownerem apod.

Ačkoliv definování DoD není výhradní odpovědností QA, může QA mít povinnost sledovat týmovou práci a zajistit, aby každý dokončil User Story. Tým není záležitost statická, ale vyvíjí se v průběhu času podle potřeb vývoje, proto QA může členům týmu poskytnout pomoc s porozuměním User Story v případě, že člen si není jist. QA může také kontrolovat, zda členové týmu opravdu chápou, co chápat mají.

Závěr

QA se nejen úzce zaměřuje na psaní testů a ohlašování chyb, ale zastupují mnoho dalších rolí a odpovědností v týmu. Je velmi důležité, aby se v rámci týmu na projektu podíleli od samotného začátku.