Velké množství firem aktuálně přechází, plánuje přechod nebo již přešlo na agilní vývoj. Často ale nevědí jak v agilním vývoji zajistit kvalitu SW, a tedy jak testovat. Není již totiž možné, aby celý tým a testeři pracovali stejně jako ve vodopádu. Firmy si často tento problém ani neuvědomují, spíše frustrovaně sklízejí následky tohoto problému:
  • pozdní dodání zákazníkům
  • zásadní chyby v releasech
  • konflikty v týmu
  • zákazníkům produkt „nevyhovuje“
Ti, kteří si to uvědomují, zase nevědí, co s tím. A tak je v obou případech výsledek stejný: dělá se to blbě. Pojďme se na celou situaci podívat detailně.

Proč firmy přechází na agile?

Některé firmy to dělají proto, aby si mohly do svých marketingových letáčků přidat moderní zaklínadlo AGILE. To je asi ten nejhorší důvod. 🙂 Většina rozumných firem ale už pochopila, že agilní vývoj je nutností dnešní rychlé doby. Požadavky se nám totiž mění každou chvíli, a tedy plánovat na roky už není reálné. Je třeba fungovat ve krátkých sprintech (iteracích). Plus dodávat produkt postupně (inkrementálně), což zákazníkovi přináší hodnotu. A to je ten pravý agile.
Zároveň se tím dostáváme k podstatě našeho problému. Pokud sprint trvá 14 dní, jak stihnout vše řádně otestovat… Jak zvládnout unit testy, integrační testy, regresní testy, automatizovat testy, vytvářet testovací scénáře, rozvíjet se v exploratory testech atd. Copak tohle vše mohou testeři stihnout?

Firmy nevědí jak testovat

Pokud se na problém díváme optikou vodopádu, tak to samozřejmě stihnout nemohou. To ale neznamená, že to nejde. Problém je ve způsobu, jakým se firmy a týmy na celou situaci dívají. Nedávno jsem byl ve firmě školit kurz Testování v agilním prostředí – jednalo se o klasickou střední IT firmu, která dodávala především software pro internetové služby a mobilní aplikace. Firma tvrdila, že jedou agilně. Mají stand-up meetingy, sprinty, dema atd. Během kurzu jsem se dozvěděl, že testeři čekají na vydání release kandidáta a teprve potom začnou testovat a tedy testování je pro ně fáze. Požadavky na testování dostávají především od vývojářů a 80 % veškerého testování je manuální. Potýkali se s velkým počtem chyb v produkci, protahováním termínů dodání atd. Tohle není agilní testování. Přijde vám něco z toho povědomé? 🙂 Tenhle případ totiž není vůbec ojedinělý, ba naopak.

Co s tím?

Jak řekl Dalajláma „Štěstí není něco, co k člověku přijde jen tak. Přichází spolu s našimi činy.“  Tak pojďme dělat činy. 🙂 Je třeba změnit přístup, jakým se na testování díváme. Je třeba chyby nejen hledat, ale také jim předcházet. Testování prostě není fáze!  Tj. nemít testera na konci řetězce, ale umožnit mu zapojit se již na úplném začátku, při plánování, nebo dokonce při vyjednávání se zákazníkem. Důležité je také zapojení testerů v průběhu celého vývoje. Zde hodně pomůže mít testery dohromady s vývojáři. Testování ale není jen o testerech. Na kvalitě výsledného produktu se podílejí všichni členové týmu. A i ti by měli vědět jak testovat a zajišťovat kvalitu. Požadavky musejí testeři dostávat včas, minimálně ve stejnou dobu jako vývojáři. Jedině tak budou schopni na ně včas reagovat a připravit se na testování.

Co dál? Vhodné je začít s hledáním odpovědí na následující otázky:

  • Kdo všechno se podílí na kvalitě a jak?
  • Jaké testovací metody jsou pro vás efektivní?
  • Kdy a kde se testeři dostanou k požadavkům?
  • Kde se má testovat?
    • GUI, API, komponenty, funkce, objekty?
  • Kdo je zodpovědný za automatizaci?
  • Jak komunikují testeři s vývojáři?

Bez automatizace to nepůjde

Dalším častým problémem, s nímž se ve firmách setkávám, je, že se nestíhá testovat. Je to pochopitelné, pokud každý sprint přidáváte novou funkcionalitu a tu pak zařadíte do regresních testů. Je jich stále více a více. Jenže počet lidí na testování máte stále stejný. Co tedy s tím? Ano, odpovědí na problém je automatizace. Výhodou automatizovaného testování jsou právě nulové náklady na pouštění a vykonávání testů. Zda test spustíte 1 x nebo 1000 x je vám vlastně jedno – náklady jsou stále stejné.

BONUS: Jak poznáte, že váš tým netestuje agilně?

  • testuje se hlavně poslední den sprintu – tzv. mini-waterfall
  • testerům se nadává, že nestíhají
  • časté konflikty mezi vývojáři a testery
  • testeři nevědí, co a kolik toho mají testovat
  • tým neví jak ověřit kvalitu a kde je to vhodné místo pro start automatizace
  • testeři nejsou zapojeni do jednání o požadavcích na produkt
  • vývojáři se nezajímají o kvalitu a netestují

Závěr

Cílem toho článku není stěžovat si, ani kritizovat firmy, které nevědí jak na to. Cílem je upozornit na problém a nastínit řešení. To není jednoduché a často je třeba získat více znalostí. Díky návštěvám desítek firem po celé ČR – kterým pomáhám s testováním – vím, že každá funguje jinak a univerzální řešení tedy neexistuje. Existují ale univerzální principy, které vám pomohu dostat se z problémů. Pokud vás agilní testování zajímá více přečtěte si článek o agilním testování nebo nějakou knihu o agilním testování, případně můžete navštívit kurz nebo najmout experta, který potřebné agilní know-how má.
A nezapomeňte – někdy je lepší zůstat v pondělí v posteli než celý týden ladit pondělní kód. 🙂