Dnes bych chtěl nakousnout téma kompatibility testování a agilních metodik. Tedy konkrétně SCRUMu. V poslední době jsou právě agilní metodiky (a SCRUM jako jejich vlaková loď) jedním z nástrojů, kterými se mnohé managementy snaží zlepšit efektivitu svých vývojových týmů a tím ruku v ruce snižovat náklady na vývoj. Při volbě metodiky a nastavování procesů nebývá testování a jeho specifika příliš brány do úvahy. Proto se tu zkusím zamyslet nad tím, jak testování funguje a může fungovat právě v agilních metodikách.

Co je to SCRUM?

Na začátek lehký úvod do metodiky SCRUM. Není mým úmyslem tu popsat v celé šíři principy SCRUMu. Na to zde není prostor a není to ani cílem tohoto článku. Spíš si jen naznačíme , v čem se SCRUm odlišuje od klasických metodik vycházejících z vodopádového pojetí.

Pokud bych měl SCRUM definovat nějak opravdu stručně, pak bych řekl, že je to metodika založená na menších týmech, rychlejší komunikaci, plánování v kratších časových úsecích a schopnosti odhadovat přesněji reálné dokončení práce. Ale to je opravdu příliš stručné. Takže podrobněji.

Základem SCRUMu je tým. Ten je na běžné poměry vývoje softwaru poměrně malý. Tvoří ho tak maximálně deset vývojářů. Úmyslně používám slovo vývojář. Role v týmu totiž nejsou striktně rozděleny. Vlastně by měla fungovat zastupitelnost, kdy kterýkoli člen týmu by měl být schopen zvládnout kteroukoli činnost v rámci procesu vývoje softwaru (myšleno od analýzy po testování). Jedinou zvláštní rolí v týmu je ScrumMaster. Ten je vlastně z podstaty své úlohy trochu mimo tým. Jeho úkolem je pomáhat týmu v úspěšném splnění plánu, ale přitom on sám se na tomto plnění přímo nepodílí. Má totiž v popisu práce tzv. čistit týmu cestu. Vlastně tým administrativně a organizačně zastřešuje. Moderuje jeho meetingy, pomáhá s plánováním, řeší organizační a technické problémy (ve smyslu nefunkční počítač a podobně), odfiltrovává od týmu vnější vlivy, které by mohli jeho výkon ovlivnit (zde myšleno například zamezení úkolování členů týmu mimo naplánované úkoly) a také (a možná především) komunikuje s tzv. ProductOwnerem. To je další role specifická pro SCRUM. Jde vlastně o zákazníka, který zadává týmu práci a následně ji přebírá. Stojí mimo tým, ale úzce s ním komunikuje. ProductOwner je tím, kdo týmu připravuje podklady pro plánování a následně plán "schvaluje".

Plánování je z hlediska SCRUMu prakticky tím nejdůležitějším. Plánuje se v krátkých iteracích, které se zde nazývají Sprinty. Délka sprintu se v různých firmách může lišit, ale měla by se pohybovat od jednoho týdne až po měsíc. Samozřejmě záleží na konkrétních podmínkách na projektu, kde je SCRUM zaváděn. Tým si na nadcházející sprint naplánuje tolik úkolů (které jsou zde označované jako UserStory), kolik jich je (dle svého názoru) schopný splnit. Aby tým byl schopný říci, kolik práce za jeden sprint zvládne, používá se odhadování. U každé jednotlivé UserStory tým odhaduje její náročnost. Používají se k tomu body, které nemají (nebo nemusí a možná by neměly) mít konkrétní vazby na reálnou pracnost v člověkodnech. Tým si zkrátka oboduje jednotlivé UserStory na základě svých zkušeností a znalostí a to tak, že čím vyšší počet bodů, tím náročnější úkol.

Aby tým vůbec mohl s plánování a odhadování začít, musí existovat seznam požadavků, se kterými může pracovat. Tomuto seznamu se říká Product BackLog a jeho vytvoření je úkolem ProductOwnera. Product BackLog by měl obsahovat všechny požadavky, kterými chce ProductOwner daný tým pověřit a kterému jsou v dané chvíli známy. Nejde tedy pouze o požadavky na nejbližší sprint, ale mělo by být pokryto mnohem delší období. Na základě těchto požadavků tým vytváří své UserStory, přičemž nemusí platit (a často neplatí), že jednomu požadavku odpovídá pouze jedna UserStory. 

Vzniklé UserStory tým ohodnotí a následně vybere ty, které dokáže v rámci sprintu splnit. Tím vzniká Sprint Backlog, tedy plán na sprint. Toto plánování je v rukou týmu, který musí být schopen odhadnout reálný objem práce, který zvládne. Tento objem se vyjadřuje jako rychlost, tedy počet bodů za sprint. Rychlost týmu by měla být v dlouhodobém pohledu plus mínus stejná, samozřejmě s ohledem na situaci v týmu (dovolené, nemoci, a pod.) Díky tomu dokáže tým i ProductOwner poměrně přesně plánovat reálné dokončení a dodání výstupů z vývoje. ProductOwner může navíc plánování týmu ovlivnit tím, že jednotlivýcm požadavkům v Product Backlogu přidělí priority a tím upřednostní jeden požadavek před druhým.  

Výsledky svého snažení po skončení sprintu prezentuje tým na tzv. Customer Demo meetingu. Jde vlastně o předvedení dokončené práce, kdy má zákazník možnost se k výsledkům vyjádřit a s týmem o nich diskutovat a také plánovat další postup. Kromě toho se tým schází pravidelně na tzv. StandUp meetingu, který by měl být ideálně každý den a kdy jednotliví členové týmu prezentují výstupy své práce za předcházející den a svoji plánovanou činnost na aktuální den.

Jedním z nejviditelnějších projevů toho, že tým funguje ve SCRUMu je tabule se Sprint Backlogem. Každý tým by měl mít k dispozici (v nějaké formě) tabuli, který zachycuje aktuální situaci při práci na Userstory v daném sprintu. Obvykle má tři části, kdy první je samotný Sprint Backlog - tedy to co se má udělat, druhou částí je to, co je již rozpracované (tedy úkoly, na kterých již někdo pracuje, ale zatím nejsou dokončené) a třetí ty úkoly, které byly dokončeny. 

Testování ve SCRUMu

A nyní k tomu podstatnému - jak probíhá testování v rámci SCRUM týmu. Jednu z podstatných informací jsem tu už uvedl, ve SCRUM týmu by měla fungovat zastupitelnost a to do té míry, že by neměly být rozlišitelné role jako je vývojář, analytik nebo tester. Příslušný úkol, tedy i testování, by měl dělat vždy ten, kdo má v danou chvíli čas a to tak, aby se úkoly jednoho typu (například právě testování) nehromadily a nečekaly na konkrétního člena týmu. ALE, je tu jedno velké ale. Neznám moc natolik univerzálních lidí, kteří by bez problémů přepínali mezi analýzou, vývojem a testováním a všechny tyto složky by měli stejně silné. Upřímně řečeno mě právě nenapadá nikdo takový. Při vytváření týmu se samozřejmě dávají dohromady lidé s konkrétní specializací. Při fungování týmu si pak celkem logicky přednostně berou ty úkoly, které jim jsou bližší. Čím déle tým funguje, tím více se projevuje postupné prolínání rolí. Nicméně, stále funguje jakýsi status garanta za danou oblast, tedy to, že například o testování ví nejvíc tester.

Jaké jsou tedy výhody a nevýhody fungování testera ve SCRM týmu? Nejdříve se zaměříme na výhody.

Výhody

• Rychlá a snadná komunikace 

              Největší výhoda, kterou SCRUM testerovi přináší. Tester má přímo v týmu analytika i vývojáře a je tedy přímo u zdroje informací. Může se (a vlastně musí) průběžně ptát a je u toho, když dochází k různým diskuzím o konkrétních řešeních nebo případných změnách. Vzhledem k tomu, že jsou všichni členy jednoho týmu a mají společný cíl, odpadá tu jakýkoli náznak možné rivality (který se někdy mezi těmito profesemi objevuje). Nalezenou chybu může tester okamžitě prodiskutovat s vývojářem bez toho, že by ji nutně musel předtím zadat do bugtrackingového nástroje. Tím se velice podstatně snižuje riziko zadávání chyb, které se nakonec ukáží například jako problém konfigurace nebo vstupních dat, případně postupu testování. Jde o skutečně velkou výhodu SCRUM metodiky. Neříkám, že vývojový tým spolu nemůže komunikovat i bez toho, že by pracoval dle SCRUMu. Jisté ale je, nebo alespoň moje zkušenosti tomu odpovídají, že pokud jsou všichni členy jednoho týmu, který se jako celek zavázal splnit nějaký objem práce, motivace jeho členů spolu komunikovat a řešit problémy je podstatně větší než když je celý projekt rozdělen na známé etapy (analýza, vývoj, testování) a jednotlivé role odpovídají pouze za splnění právě té své etapy.

• Aktivní účast na hledání řešení 

Pro testery, kteří často fungují uklízecí četa na konci projektu a nemají příliš šancí ovlivnit, jakým způsobem je projekt vyvíjen, jde o vítanou změnu. Ve SCRUMu se ostatní členové týmu testera prostě ptát musí. Už ve fázi odhadování a plánování musí celý tým získat alespoň obecnou představu o tom, co otestování vyvíjené funkčnosti znamená a co je proto potřeba. Všechny UserStory, i ty zaměřené čistě na testování, ohodnocuje celý tým a ne pouze tester. Všichni tak musí vědět, o jak velký objem práce jde. Navíc ale má tester možnost mluvit i do konkrétního řešení při vývoji. Samozřejmě je otázka, zda jeho připomínky budou brány v úvahu, ale  to už je závislé na nastavených procesech uvnitř týmu. Je ale v zájmu celého týmu zabývat se tím, zda je zvolené řešení vhodné i z pohledu testování.

            Tento bod bych vlastně mohl nazvat i takto - " Účast na projektu od jeho začátku". Tester je prostě součástí týmu po celou dobu vývoje. A to je příjemné. Kdo má zkušenost s projektovým způsobem práce tak ví, že testeři jsou velice často k projektu přizváni až ve chvíli, kdy už existuje finální verze analýzy (a analytik pomalu přechází na jiný projekt) a vývojáři dokončují první  testovatelnou verzi aplikace. Tak k tomu ve SCRUMu nedochází.

          Ve SCRUM týmu se obvykle plánují UserStory jako ucelený blok, který má nějaký prezentovatelný výstup. Součástí UserStory je tak jak analýzy, vývoj, tak i testování. Vzhledem k tomu, že UserStory se plánují s ohledem na schopnost týmu je dokončit v plánovaném sprintu, může se stát, že rozčlenění vývoje aplikace na tyto úseky nemusí odpovídat tomu, jak by si testování této aplikace naplánoval tester, kdyby fungoval samostatně. Může se vyskytnout například potřeba dílčích testů, které by jinak nebyly v této podobě prováděny a byly by součástí nějakých větších testovacích scénářů. Tester v tomto musí respektovat potřeby týmu a fakt, že na konci sprintu tým odevzdává svou práci, která by měla být mimo jiné i otestovaná. Na druhou stranu, jak už jsme tu řekl, tým by měl brát v úvahu testovatelnost vyvíjené a dodávané části aplikace.

Tyto výhody a nevýhody jsou mojí úvahou a vyházejí z mých (ne zase tak bohatých) zkušeností se SCRUMem na konkrétním projektu. Nechci proto úplně zevšeobecňovat. Můj subjektivní pocit ze SCRUMu je, po počátečním odporu, dobrý. Rozšířil mi obzor o další odbornosti. Ne že by se ze mě stal vývojář nebo analytik. Ale rozhodně mám pocit, že do jejich práce teď vidím líp, než předtím. Ke SCRUMu mám vlastně jen jednu výtku. Mám pocit, že v zájmu celku, tedy výkonu týmu, není kladen takový důraz na rozvoj jednotlivých členů. Tedy to není úplně pravda. Je hodně podporováno předávání znalostí a zkušeností mezi členy týmu. Snahou je, aby vznikl tým univerzálních vývojářů, kteří jsou schopní si z tabule backlogu vzít kterýkoli úkol a úspěšně ho vyřešit. Z mého pohledu (a můžu se mýlit) se tím poněkud utlumuje snaha jednotlivých členů týmu rozvíjet svou specializace. Tým tak funguje jako celek dobře a má takový výkon, jaký si naplánuje, ale trochu se obávám, jestli tím neustrne v rozvoji jednotlivých odborností. Nebyl jsem ale členem SCRUM týmu tak dlouho, abych toto mohl  jednoznačně tvrdit. Pokud někdo máte hlubší a dlouhodobější zkušenost, rád se dozvím, jak to v tomto ohledu ve SCRUMu funguje.