Jednu z vecí o riadení, ktorú som sa naučil je, že pri dlhotrvajúcich projektoch je dôležité rozlišovať konštantné a meniace sa veličiny. Pod veličinami môžeme rozumieť akékoľvek počty alebo čísla, ktoré súvisia s projektom. Napríklad počet riadkov zdrojového kódu, počet ľudí v tíme, množstvo úloh v sprinte, počet dní/hodín/minút, počas ktorých trvá, kým sa zistí, že do zdrojového kódu bola omylom pridaná chyba alebo počet minút, ktoré trvá denná porada. Konštantná veličina je taká, ktorá sa časom nemení. Príkladom môže byť už spomínaný počet minút rannej porady. Táto veličina je väčšinou závislá od počtu ľudí v tíme a disciplíny ľudí, ktorí sa jej zúčastňujú, pričom väčšinou ide o interval (napríklad 5 až 10 minút). Dá sa povedať, že táto hodnota je konštantná (aspoň v prípade nášho tímu). Konštantné veličiny sú fajn. Fajn preto, že ak nájdete dobré riešenie, ktoré s nimi súvisí, tak sa o to už ďalej nemusíte starať. Čo sa týka denných porád, tak sme sa dohodli, že na porade budeme stáť, že každý povie to na čom pracuje, pracovať bude a či má nejaký problém, a že nebudeme zachádzať do detailov. To viedlo k tomu, že sa naše porady zmestili do 10 minút.
To, čo je v projekte nebezpečné, sú meniace sa veličiny. Hlavne tie rastúce. Z môjho pohľadu sa ako najnebezpečnejšia javí množstvo funkcionality v aplikácii. To je samozrejme žiadúci efekt. Problém je, že to má za následok rast množstva kódu (čo zase vedie k predĺženiu času automatického zostavenia, automatických testov, atď.), množstva času stráveného regresnými testami, množstva dokumentácie a pod. Hlavným problémom rastúcich veličín je, že súčasné riešenie nemusí byť v budúcnosti dostatočné. Dobrým príkladom, kedy rastúca veličina prevalcuje konštantné riešenie, je použitie agilných metód a manuálneho testovania.
Prvou z dvoch dôležitých požiadaviek, ktoré sú kladené na náš tím je, že umožňujeme zmenu priorít v backlogu (čo znamená, že máme len krátkodobé – sprintové – plánovanie, a teda v ďalšom sprinte môžu prísť ľubovoľné úlohy, a teda aj zmeny v kóde). Tou druhou je, že musíme byť schopní často zverejňovať nové verzie aplikácie s určitou konštantnou mierou rizika (inak povedané s čo najmenším počtom chýb). Tieto požiadavky viedli k tomu, že sme často nútení vykonávať regresné testy nad celou alebo veľkou časťou aplikácie. Takže na jednej strane máme rastúce množstvo funkcionality, ktoré spolu s požiadavkou na konštantnú úroveň rizika chyby v produkčnej prevádzke vedie k nárastu regresných testov. Na druhej strane je tu ale jedno obmedzenie a to je cena testovania. Keďže počet programátorov sa nemení, konštantný by mal ostať aj počet testerov. Tento rozpor je ako činná sopka – sem-tam vypúšťa dym až do chvíle, kedy je energie dosť a dôjde k výbuchu.
Spočiatku sme ako spôsob testovania zvolili ručné testovanie. To znamená, že aj regresné testy sa vykonávali ručne. Prvý rok a pol až dva to bolo únosné. V treťom roku sme narazili na strop možností našich testerov. Jednoducho už nebolo dostatok testerských síl, aby boli schopní otestovať všetko, čo bolo treba. Riešenie, ktoré bolo zvolené na začiatku, bolo vybrané na základe aktuálneho stavu veci. Až teraz sa jasne ukázalo ako nefunkčné práve preto, lebo pracovalo s veličinou, ktorá sa menila (rástla), a to množstvo funkcionality, ktorú treba otestovať. Ostávali len dve možnosti: zmeniť konštantu (počet testerov) alebo zvoliť iné riešenie.
Tým iným riešením sa ukázalo automatické testovanie. V podstate sme nevymysleli nič nové, pretože o automatickom testovaní sa hovorí prakticky v každej knihe o agilných metódach. To, čo sme museli vymyslieť bolo, ktoré nástroje a postupy použiť. Všetko to ešte komplikovalo to, že sme v podstate sedeli v rozbehnutom vlaku, t.j. na projekte sa stále pracovalo a naši testeri (ktorí by mali mať túto automatizáciu hlavne na starosti) mali dosť práce s ručným testovaním. Takže sme pozbierali všetok zvyšný čas, ktorý ostával a investovali ho do toho riešenia. To spolu s nejakou príležitostnou výpomocnou silou viedlo k tomu, že sa nám pomaly začali uvoľňovať ruky a mali sme čas pustiť sa aj do zložitejších častí.
Dnes sa dá povedať, že sme niekde v polovici splácania technologického dlhu z čias, kedy sme vykonávali ručné testy. Samozrejme, rastúce množstvo funkcionality má vplyv aj na množstvo automatických testov. To vedie k predĺženiu ich behu a času ich spravovania. Ale v konečnom dôsledku je to veľmi ďaleko od toho, aby to opäť udrelo o strop – teda narazilo na nejakú konštantu (tou najbližšou môže byť počet nočných hodín, ktoré máme na spúšťanie testov).
Množstvo literatúry o agilných metódach a aj vlastné skúsenosti ma presviedčajú, že sa veľké agilne riadené projekty bez automatizácie nezaobídu. Že požiadavky ako krátkodobé plánovanie a časté zverejňovania nových verzií musia viesť k jej zavedeniu. Na záver už len môj osobný zoznam výhod automatizácie:
1. Znižovanie rizika (chýb, alebo akýchkoľvek problémov, ktoré by vedelo testovanie odhaliť)
2. Odbúrava rutinnú prácu a uvoľňuje ruky pre kreatívnu prácu
3. Informuje (výsledky testov si môže prečítať ktokoľvek)
4. Núti k dobrému návrhu (napr. jednotkové testy) a pochopeniu (nahrávanie automatického testu často viedlo k hlbšiemu rozboru súčasného stavu funkcionality)
5. Je niekedy zábava J (hlavne keď sa darí)
Pre tých, ktorý hľadajú nejaké zdroje:
[1] Paul Duvall: Continuous Integration: Improving Software Quality and Reducing Risk
[2] Lisa Crispin, Janet Gregory: Agile Testing
[3] Mike Gunderloy: Z kodéra vývojářem
