Vývoj softwaru s testerem nebo bez?

Je tester jako role ještě potřeba? Jak vypadá vývoj bez testera a co poradit vývojářům na takovém projektu? A co si z něj naopak odnést na projekt s testery?

Ptal jsem se šesti našich vývojářů, kteří mají bohaté zkušenosti s testováním softwaru, ať už s testery anebo bez nich. U obou způsobů byli schopni najít výhody i nevýhody a zamyslet se, jak by se dala tato cesta zlepšit.

Vývoj bez testerů = cesta k větší zodpovědnosti?

"Kvalita je odpovědností každého”, říká slavný citát W. E. Deminga. Když je to odpovědnost každého, co mám ale konkrétně dělat já? Nestará se o to tedy někdo jiný? A platí to samé i pro testování softwaru jako kontrolu kvality? Je to také odpovědnost každého?

Od našich vývojářů jsem se dozvěděl, že i když odstraníte software testera jako roli, potřeba testování s ním nezmizí. Přechází tak více na samotné vývojáře. Ti motivaci k větší zodpovědnosti vnímají jako hlavní výhodu vývoje bez testerů. Když vám nikdo nekryje záda, jste více motivováni k tomu, abyste si po sobě vše pořádně otestovali sami, případně využili více automatické testování a celkově odevzdávali kvalitnější práci. Naopak na projektu s testery se může stát, že se na ně vývojář bude spoléhat a místo vlastní aktivity bude jen čekat, jestli mu tester práci vrátí k přepracování nebo ne.

Vývoj s testery = ztráta času?

Na projektu bez testerů často neprobíhají žádné release testy. Vývojáři testují aplikaci průběžně a většinou tam není žádné velké testování, než může jít ven. Dalo by se tedy říci, že je o jeden článek méně a “time to market” se zkracuje. Zároveň odpadá problém s koordinací a načasováním, protože se nemůže stát, že by tester dostal všechnu práci na otestování až těsně před releasem a pak nestíhal, což na projektu s testery bývá obvyklá výzva. Pokud navíc tester pracuje na více projektech najednou, může být vytížen jinde a vývojář může obdržet bug se zpožděním a ztratit kontext toho, co dělal. Když se najde bug při vývoji bez testerů, může ho vývojář rovnou řešit. Tester také přichází se spoustou okrajových problémů, ve kterých se dá snadno zabřednout.

Pak jsou zde i činnosti, které jsou pro vývojáře prostě jednodušší. Například si něco namockovat, pokud je to pro testování potřeba. Testerovi se musí vyrobit namockovaný build, nebo mu s mockováním alespoň pomoci. Zároveň vývojář už ví, na čem pracuje, a má větší vhled do toho, co testovat, tudíž mu to zabere méně času. To se však může jednoduše převrátit v nevýhodu, protože testování ztrácí svou nezávislost.

Doporučení vývojářů pro vývoj s testery

Sami vývojáři se pak zamýšlejí, co je správně a z toho vzniká jejich doporučení pro projekty s testery.

• Nepřebírejte odpovědnost až ve chvíli, kdy vám nic jiného nezbývá. I když je na projektu software tester, nespoléhejte se stoprocentně jen na něj a snažte se udělat co nejvíce na své straně. Pište unit testy, zaměřte se na porozumění zadání, mějte povědomí o konkrétní sadě akceptačních testů pro danou funkcionalitu a proveďte základní testování již jako součást code review.
• Co nejvíce s testery kooperujte. Nejlépe mějte dedikované testery jen pro daný projekt. Dohodněte se s nimi, jak probíhá celý cyklus a zahrňte je do procesu přípravy úkolů a vývoje. Mohou například připravovat akceptační kritéria. Důležitá je i správná prioritizace oprav a nových feature. Také je dobré nechat testery více nahlédnout pod pokličku samotného vývoje. Když tester pochopí, jak vývojáři nad konkrétními věcmi uvažují, může na základě toho odhalit potenciální rizika. Zároveň se mohou naučit zvládat sami techničtější úkoly, například nastavit projekt a vytvořit build lokálně a mockovat věci přímo v kódu.

Vývoj bez testerů a nezávislé testování

Jak už jsem naznačil, když není na projektu tester, jeho role se neztrácí, nýbrž přechází z části na vývojáře. To s sebou nese ale i nevýhody. Vývojář přesně ví, jakou změnu provedl, předjímá možné chyby a testuje jen přesně tuto změnu, nesahá nikam jinam. Mohou mu tak uniknout vedlejší efekty změny nebo chyby, které přímo se změnou nesouvisí. Ty dokáže odhalit jen nezávislé testování.

Výhodou testera je, že vidí aplikaci hlavně jako black box. To vede k tomu, že k ní přistupuje více jako uživatel a testuje i věci, které se vývojáři zdají jako samozřejmost. Navíc tester má přece jen o testování více znalostí a má pro něj vybudovaný cit. Také většinou testuje Android i iOS a může tak obě platformy porovnat, což mu opět pomáhá najít více případných problémů.

Téměř všichni vývojáři se tak shodují na tom, že okrajové nebo regresní problémy dokáží zachytit jen náhodou, do produkce se tak dostává více bugů a dochází k degradaci kvality produktu. To jim připadá nefér vůči uživatelům a spoléhat na to, že jim uživatelé chyby nahlásí nebo systém zachytí pády aplikace, rozhodně není ok.

Doporučení vývojářů pro vývoj bez testerů

A co tedy s tím? Jak si poradit s vývojem bez testerů, aby se tyto problémy eliminovaly? Přijmout testery :) To byl spíše vtip, ale celkově převládá názor, že vývojář nikdy nebude mít zcela pohled zvenčí. I tak se ale dají udělat určité kroky, aby se situace zlepšila.

• Jedna cesta je ještě více testování automatizovat. Využívat unit testy i nějaké automatizované integrační a UI testy. Testera sice nenahradí, ale určitě pomůžou s větším pokrytím. Především je dobré pokrýt ty části aplikace, které přinášejí největší hodnotu uživatelům a klientovi tak generují nejvíc peněz.
• Vývojáři se také shodují, že by bylo dobré se dovzdělat v QA a jeho procesech. Být ještě více pečlivý a důsledný, nevynechat žádný use case, i když se může zdát triviální. Akceptační testování by se mělo stát přímo součástí code review - prostor pro akceptační kritéria může být již v šabloně pull requestu.
• Zároveň vývojáři z jedné platformy mohou testovat funkcionalitu druhé platformy, aby se tak podchytily rozdíly. Také je dobré mít dané “definition of done” a vědět, v jaké kvalitě lze považovat věc jako hotovou.
• A v neposlední řadě nenechat všechno jen na vývojářích a zahrnout i specifické testovací skupiny - interní alpha track, externí beta track apod.

Který přístup nakonec zabere více času?

Teď si možná říkáte, že když tohle všechno bude vývojář dělat, stráví na projektu tolik času, jako kdyby pracoval s testery, ne-li více.

Možná se ušetří na tom, že se nedělají release testy, ale vývojáři se shodují, že samotný vývoj se o dost protahuje, a to právě kvůli opatrnosti. Vývojář si po sobě vše třikrát překontroluje a třikrát protestuje, další vývojář, který mu dělá review, věc také překontroluje a otestuje, a pak s každou další změnou se to celé opakuje.

Narůstající rutina vždy zvyšuje i šanci, že projde skrz nějaký bug. Navíc tím, že nikdo neprochází pravidelně celou aplikaci, se stává, že jsou i obrazovky, o kterých už neví nic ani žádný vývojář - jak v současnosti fungují, natož jak mají fungovat správně. A podobné je to i s ušetřeným časem, kdy vývojář nemusí vysvětlovat testerovi, jak a proč věci naprogramoval. Přijde tak totiž o takzvaný Rubber duck debugging efekt, kdy si sám může přijít na chybu nebo na něco, co opomenul.

Problémem samo o sobě pak je, že se často ani nepočítá s tím, že vývojáři tím pádem potřebují na vývoj více času, protože musí i testovat. Vývojář je tak plně vytížen a jakmile se dostane do časového presu, testování softwaru je to první, na čem se bude šetřit, protože je to přece jen až sekundární náplň práce vývojáře, tou primární je programování.

Vývojáři se shodují, že aby testování za něco stálo, tak je potřeba mu dát dostatečnou porci času. A nejlíp s tím počítat již dopředu a zařadit ho do plánování projektu (ať už v agilním přístupu nebo při waterfallu), domluvit se s projekťákem, aby je pak nemusel honit. To, jestli vývojáři chtějí testováním opravdu trávit víc času, je zase úplně jiná otázka.

Co vyhovuje vývojářům?

Mezi našimi vývojáři jasně vyhrál vývoj s testery. Pouze jeden zmínil, že když je dost času, tak si klidně zatestuje, ale jakmile čas tlačí, volí také vývoj s testery. Základní důvod je jednoduchý, vývojáři prostě rádi programují. S testerem za zády na to mají více času. Z vývoje bez testerů by si odnesli důraz na kvalitu kódu hned od začátku, protože bez testera si vývojář spíš nedovolí odevzdat špatný kód. Jinak ale testery vnímají jako záchrannou síť, díky které mají více prostoru dělat to, co mají rádi. Zároveň vnímají, že tester má v této činnosti více zkušeností, znalostí a nezávislý pohled. Jsou tedy klidnější, když ví, že někdo takový projde celou aplikaci a pohlídá funkčnost hlavních komponent.

A jak se na vývoj s testery a bez testerů díváte vy?