Přejít na obsah|Přejít k hlavnímu menu|Přejít k vyhledávání
Scrum je bezesporu jednou z nejpoužívanějších agilních metod pro řízení vývoje software. Z mého pohledu má většina, především začínajících týmů, potíže s tím, jak přistupovat k testování. Jak se testuje ve Scrumu, jaké jsou role členů týmu a kam zařadit testera, zkusím popsat v tomto článku.
Ve Scrumu existují tři hlavní role: product owner, Scrum master a vývojář. Role testera definována není. Proč tomu tak je, vyplývá se samotné definice Scrumu; za doručení funkcionality je zodpovědný celý tým. V ideálním světě by to znamenalo, že každý vývojář by měl být schopen splnit veškeré kroky, které s doručením souvisí. Těžko ale budeme hledat takového, který je zběhlý ve frontendu, backendu i testování. A z toho důvodu ve Scrumu mluvíme o specializaci vývojářů. Testera bychom tedy měli nazývat spíš vývojářem se zaměřením na kvalitu.
Když už tedy máme jasno, jakou roli tester ve Scrumovém týmu má, možná by jsme měli přestat používat slovo tester a nahradit ho obecnějším software quality engineer (SQE). Tester je, podle mě, někdo, kdo vykonává samotné testování, což je ale jenom malá část toho, co ve skutečnosti děláme.
Myslím, že i z psychologického pohledu, je označení SQE lepší, protože dává najevo, že umíme trochu víc, než jen klikat na tlačítka. Měli by jste raději ve svém CV jako pozice uvedeno "tester" nebo "software quality engineer"? Z výsledků Twitterové ankety od Nicol Lindgren můžeme vyčíst, že název pozice je důležitý pro 56,4 % respondentů (z celkového počtu 156 hlasů).
Číslo to není vysoké, ale anketa se zabývá názvem pozice obecně. Osobně bych si tipl, že kdyby byla anketa konkrétnější, zaměřená jen na vývojáře, bylo by číslo vyšší. Dokonce bych se vsadil, že v případě názvů pracovních inzerátů, bude mít samotný název velký vliv. Osobně bych na pozici "tester" možná ani neodpověděl. "Software quality engineer" podle mě dává najevo, že firma si je vědoma toho, jak to s testováním je a že nehledají jen "klikače", ale člověka, který dokáže pokrýt mnohem širší spektrum činností.
Jak bylo výše napsáno, za doručení funkcionality je zodpovědný celý tým. To znamená, že tým táhne za jeden provaz, spolupracuje tak, aby jeho členové co nejlépe využili svoji specializaci a v případě potřeby pomohli tam, kde je třeba. Tým funguje jako celek a každý člen by měl přiložit ruku v dílu ve všech fázích vývoje.
Často se setkáváme s tím, že "testeři" působí jako samostatná jednotka a k testování se dostanou až v době, kdy už je vše hotovo a vývojáři pracují na dalších úkolech. V takovém případě ale tým nemůže efektivně fungovat, protože se jedná o dva týmy s rozdílnými cíli. To zákonitě vede k prodlužování doby dodání funkcionalit. Priorita testování může být jiná, než priorita doručení. V praxi to potom může vést ke snížení kvality produktu:
SQE má samozřejmě slovo i při groomingu a plánování a při hodnocení jednotlivých user stories má stejný hlas jako ostatní vývojáři. Hodnocení musí zahrnovat i testování. Je možné, že z tohoto důvodu budou mít ostatní vývojáři na konci sprintu "volné ruce", ale jak už bylo napsáno - za doručení je zodpovědný celý tým a v případě časové nouze je prostě potřeba přiložit ruku k dílu. Dobrý vývojář by měl být schopný i testovat.
Důležité je, aby SQE začal co nejdříve s přípravou testovacích scénářů a přípravou testování tak, aby bylo testování nachystané i na variantu, že testovat bude někdo z vývojářů. Koneckonců, i samotný testovací scénář je součástí produktu.
Pokud má testování připravené, ale zatím není co testovat, je spousta dalších činností, kterým je vhodné se věnovat pravidelně:
U posledního bodu, regresního testování, stojí za zmínku, že Scrum s ním vlastně moc nepočítá. Na konci sprintu by měl tým doručit kompletní a otestovaný produkt. To by ale znamenalo, že regresní testování by se mělo dělat na konci každého sprintu. V praxi se toto ale neděje a většinou se regresní testování provádí jen před větším releasem. Záleží ale samozřejmě na tom, o jaký produkt se jedná. V případě mikroservices je to možné, ale u velkých monolitických produktů to v podstatě reálné není. Z vlastní zkušenosti ale můžu říct, že je dobré si "malou regresi" udělat po každém sprintu. Zaměřit se především na části aplikace, které byly změněny a k tomu přidat pár obecnějších testů.
Děkujeme! Odebírání newsletteru bylo úspěšně přihlášeno.
