Je testování, Quality Assurance brzda vývoje v agilním prostředí? Dovolím si být trochu kontroverzní a řeknu, že ano. Proč tomu tak je a jak se této nálepky zbavit?
V dnešním konkurenčním prostředí je kvalita software zásadní pro získání a udržení spokojených zákazníků. Ačkoli agilní metodiky přinášejí mnoho výhod, jako je rychlejší dodání produktu a lepší přizpůsobení se změnám, mohou také představovat výzvy pro testování a QA. Jak se vypořádat s těmito výzvami?
V tomto článku se ponoříme do problematiky agilního testování a QA, prozkoumáme hlavní výzvy a představíme osvědčené metody, které vám pomohou posunout váš tým na novou úroveň efektivity a spokojenosti zákazníků.
Agilní vývoj
Než se ponoříme do problematiky testování v agile, pozastavím se nad tím, jak agilní vývoj funguje a jaké jsou jeho cíle.
Agile, ať už jako scrum, kanban, SAFe či jiné přístupy mají za cíle:
- Zrychlit dodávání software
- Spokojenost klienta
- Rychlejší reakce na konkurenci
- Kontinuální zlepšování a komunikace
- Flexibilita
Těchto cílů se dosahuje pomocí iterativního vývoje.
Jeden cyklus běžně trvá od 1 dne zhruba po měsíc. Nejběžněji to ale u nás bývá 14 dnů.
Tlak na dodávání je obrovský. Čím rychlejší dodávka produktu, tím lépe.
Testování jako brzda
Co toto má společného s testováním?
Veškeré činnosti v rámci SDLC (Software Development Life Cycle) se tomuto tlaku přizpůsobují.
Úkoly bývají menší v porovnání s Waterfall, komunikace je preferována osobní namísto e-mailové, dokumentace je stručnější…
A testování? Běžně bývá stále stejné, jako ve waterfall.
Co to znamená? Testeři v agilních týmech často čekají na to, až jim vývojáři dodají vyřešený úkol.
Následně se začíná testovat, opravovat bugy, spouštět regresní testy.
Dochází ke kombinaci Agile a Waterfall:
Watergile
Vytváří se posloupnost. Jedna oblast čeká na druhou, dělají se postupně.
Tímto bohužel dochází ke kombinaci dvou světů agilního a waterfall.
Vzniká pojem, který rád popisuji jako Watergile.
Znamená to ale problém. Hlavní důvod je ten, že vývojáři často odevzdávají své úkoly těsně před plánovaným ukončení iterace.
Testeři následně mají málo času na otestování, nahlášení chyb, exekuci regresních testů.
Tento fenomén můžeme nazvat neagilní testování.
Jak to může na projektu vypadat? Na to se můžete podívat na obrázcích níže.
Dopady
Nemají do čeho píchnout.
Frustrace testerů, momentální nedostatek zdrojů, zpomalení dodávek a snížení kvality jsou častými dopady neagilního testování.
Demotivace je zapříčiněna tím, že na začátku iterace testeři/QA inženýři nemají “do čeho píchnout” a na konci iterace jsou přetížení.
To způsobuje frustraci, která může vést například ke konfliktům v týmu nebo dokonce k odchodu testera.
Tím, že tester nemá dostatek času dokončení testů vznikají 2 situace:
- Nutnost přesčasů
- Přesun úkolů do další iterace (spillover)
Ani jedna z nich pro tým není ideální.
Všechno toto následně vede k přímým dopadům na projekt a to jak nesplněním termínů, tak poklesem kvality.
Jak z toho ven?
Jednoduchá odpověď? Začít testovat agilně.
Co to vlastně znamená? Z mého pohledu je to zapojení testera nebo QA Engineera v celém sprintu, ne jen na konci. Jak toho ale docílit?
Ve hře je několik možností, jak testování můžete udělat více agilní.
Jsou to zejména oblasti:
- Shift-left testování,
- Automatizace testování,
- Optimalizace procesů,
- Rozšíření zodpovědností v týmu
Shift-left testování
Posouvání testování doleva je myšlenka, která říká, že by se testovat mělo co nejdříve ve vývojovém procesu.
Znamená to dřívější testování jak z dynamického, tak statického testování.
Tester se aktivně účastní všech ceremonií v týmu, vývojové úkoly se rozpadají na co nejmenší části, aby byly dříve dokončeny vývojáři a tedy i dříve testovatelné.
Já tuto myšlenku rozvíjím ještě dále, protože kroky popsané výše jsou dle mého názoru nedostatečné.
Jak tedy můžeme testování posunout doleva ještě více?
Pair-testing
Je možná větší spolupráce v týmu, například mezi vývojářem nebo testerem.
Vývojář může již při vývoji s testerem provádět takzvaný pair-testing. Vývojář a tester při vytváření nové funkcionality sedí spolu. Tester dává vývojáři okamžitou zpětnou vazbu.
Cíl je dávat zpětnou vazbu co nejdříve.
Tímto způsobem se sníží riziko výskytu chyb, tester se seznámí se zadáním.
Dokonce i opravy jsou rychlejší, protože vývojář nemusí investovat čas do zpětného seznámení se s kódem.
Další, co může pomoci je testování na lokálním prostředí.
Lokální prostředí
Často je pro testování vyžadováno stabilní prostředí.
To znamená, že vývojáři do něj neinstalují rozdělanou práci.
Z toho následně vyplývá, že tester musí čekat, až vývojář svůj kód dokončí.
Na projektech se mi vyplatilo umožnit testovat i na lokálních nebo DEV prostředích.
Vývojář nám může nahrát rozdělanou práci a my mu následně můžeme dát zpětnou vazbu dříve.
Automatizace testování
To, že je automatizace testování důležitá, dnes již téměř nikdo nepopírá.
Z mé zkušenosti se ale často agilní týmy perou s tím, že na automatizaci není čas.
Tester musí v tomto případě vše testovat ručně.
A to chce čas… spoustu času.
Typický vývoj end to end automatizace manuálních testů trvá dlouho a je těžko udržitelný zejména v rychle se měnícím prostředí.
Řešení mohou být atomické testy, které se zaměřují na jednotlivé elementy a jejich funkčnost, než na celý business proces.
Optimalizace procesů
I když by v agilním vývoji měla vznikat jednoduchá dokumentace, u testování je často nadále vyžadováno vytvářet detailní test plány, test analýzu, testy.
To zabírá čas, který poté může chybět někde jinde.
Také vývojový proces je občas neefektivní. Dělají se velké úkoly, které zaberou někdy i mnoho dnů na dokončení.
Rozdrobení úkolů na menší části totiž není jednoduché a spoustě lidem se do toho nechce.
Končí to pak přesně tou situací, kdy tester čeká celý sprint na to, až bude moci něco testovat.
Náprava je v tom, že se procesy zefektivní. Ubere se administrativy, schůzek a dalších činností, které berou náš drahocenný čas
Rozšíření zodpovědností v týmu
Tester/QA Engineer je v týmu proto, aby zajišťoval kvalitu.
Pokud se objeví problém, je na testerovi aby ho odhalil.
V extrémních situacích vývojáři nezkusí ani spustit svůj kód.
Pokud je zodpovědnost kvality pouze na QA týmu, poté opět vznikají situace, které mohou způsobovat neefektivnost.
Za kvalitu by měl být zodpovědný celý vývojový tým nejen QA/tester:
- Vývojář si testuje svůj kód.
- Analytik udělá revizi dokumentace.
- Product owner ověří, že jeho myšlenka dává smysl, atd.
Co z toho plyne?
Odpověď na počáteční otázku: „Je QA úzké hrdlo v Agile?“ často zní ano.
Není to nic výjimečného. Setkal jsem se s tím na projektech mnohokrát.
V tomto článku jsem se pokusil vyjmenovat způsoby, jak tuto situaci napravit.
Není však možné věci generalizovat. V některých týmech mé doporučení zafungují, v některých nikoliv.
Pokud však trpíte fenoménem neagilního testování. Doufám, že vás tento článek alespoň trochu inspiroval.
Cílem nás všech by totiž mělo být nejen dodávání kvalitního software rychle, ale také naše osobní spokojenost na projektu.
Zdroje a inspirace
- Shift-left testing – techtarget.com
- Real agile bottleneck – Forbes
- Removing delivery bottleneck – functionize
- 2021 Global Survey – Gitlab
- Agile Testing Guide Screen – Digital-government.co.uk
Grafika
Za ikony děkujeme webu https://www.flaticon.com/
