Konferencia CzechTest 2014

CzechTestV dňoch 26. a 27. júna 2014 sa v Prahe (Clarion Congress Hotel ****, Praha) uskutoční štvrtý ročník medzinárodnej konferencie CzechTest zameranej na testovanie softvéru a systémov. Ide o jedinú konferenciu svojho druhu na území Českej Republiky a Slovenska.

Program konferencie obsahuje množstvo prednášok, ktoré odprezentujú nielen skúsení profesionáli z “našich krajov” ale aj medzinárodne uznávaní zahraniční experti zvučných mien z oblasti testingu. Pod vedením niektorých z nich je možné deň pred konferenciou, 25. júna, absolvovať aj špeciálne tréningy (pre-conference tutorials) zamerané na získavanie a zlepšovanie praktických testovacích zručností.

Účastníkov minuloročnej konferencie nepochybne očarila Julie Gardiner, ktorú sa podarilo získať na konferenciu tento rok opäť. Časť programu sa zaoberá agilnými prístupmi a jedným z prednášajúcich bude aj dobre známy slovenský agilný hrdina Dušan Kocúrek.

Súčasťou konferencie je každoročne súťaž o zaujímavé ceny (napr. iPad), prezentácie hlavných sponzorov, predaj špecializovanej literatúry a stravovanie pre účastníkov priamo v hoteli.

Účastníci, ktorí sa prihásia do 17. júna získavajú zľavu 20% z registračného poplatku, držitelia certifikátu ISTQB získavajú takisto zľavu 20%, študenti rovnako zľavu 20% pričom tieto zľavy sa kumulujú a je teda možné získať celkovú zľavu až 60%.

Konferencia CzechTest 2013

CzechTestV dňoch 21. a 22. marca 2013 sa v Prahe (Clarion Congress Hotel ****, Praha) uskutoční tretí ročník medzinárodnej konferencie CzechTest zameranej na testovanie softvéru a systémov. Ide o jedinú konferenciu svojho druhu na území Českej Republiky a Slovenska.

Program konferencie obsahuje množstvo prednášok, ktoré odprezentujú nielen skúsení profesionáli z “našich krajov” ale aj medzinárodne uznávaní zahraniční experti zvučných mien z oblasti testingu. Pod vedením niektorých z nich je možné deň pred konferenciou, 20. marca, absolvovať aj špeciálne tréningy (pre-conference tutorials) zamerané na získavanie a zlepšovanie praktických testovacích zručností.

Tom Gilb

Tom Gilb

Časť programu sa zaoberá agilnými prístupmi a medzi “ťahákov” konferencie patrí rozhodne Tom Gilb. Jeho koncpet EVO (Evolutionary Project Management), ktorý sformuloval ešte v 70-tych rokoch minulého storočia je považovaný za jeden zo základných kameňov na ktorých Agile staval.

Súčasťou konferencie je každoročne súťaž o zaujímavé ceny (napr. iPad), prezentácie hlavných sponzorov, predaj špecializovanej literatúry a stravovanie pre účastníkov priamo v hoteli.

Účastníci, ktorí sa prihásia do 20. februára získavajú zľavu 20% z registračného poplatku, držitelia certifikátu ISTQB získavajú takisto zľavu 20%, pričom tieto zľavy sa kumulujú.

Agilné testovanie? Prečo nie.

agile.testingAgilný tím by mal byť multiprofesný. Okrem architektov a staviteľov, ktorí ťažko pracujú a budujú produkt, by mal obsahovať niekoho, kto povie, že sa program dá používať. Niekoho, kto sa pozrie na celú vec z inej perspektívy a nájde chyby, ktoré možno z tej pôvodnej nebolo vidno. Niekoho, kto stojí na polceste medzi programátormi a zákazníkmi, a tak sa vie najlepšie dorozumieť s obidvoma skupinami. Tušíte správne, že ten niekto je tester. Aspoň tak ho vidia Lisa Crispin a Janet Gregory v ich knihe Agile Testing.

Hneď na začiatku treba povedať, že kniha by sa dala rozdeliť na dve časti. Jedna sa týka vysvetľovania agilných metód ako takých. Rozoberané sú jednotlivé praktiky aj dôvody prečo ich používať. Tá druhá má za cieľ ukázať ako v prostredí týchto metód testovať. Teda zaoberá sa už len priamo testovaním. Dobrá správa je, že kniha má dosť strán (533), a teda obe polovice dostali dosť priestoru. Zlá je, že sa tieto dve časti knihou postupne preplietajú, a tak si neviete prečítať jednu alebo druhú podľa toho, čo vás zaujíma.

Autorky vidia testera ako veľmi dôležitú časť tímu. Hneď v prvých kapitolách, kde vysvetľujú agilné metódy, sa snažia presvedčiť,  že tester môže byť iniciátorom aj katalyzátorom zmeny riadenia na agilné. S veľkou časťou týchto myšlienok som sa už stretol vo forme pre programátorov, to ale netratí na ich cene v tejto knihe. Nechýbajú klasické témy ako: metriky, spôsob zaznamenávania chýb, plánovanie a spolupráca s požadovanými štandardmi.

Druhá časť knihy je venovaná takzvaným štyrom kvadrantom testovania. Tieto kvadranty sú vytvorené kombináciou možnosti, či ide o testy na podporu tímu (t.j. zvýšenie kvality produktu) alebo kritiku produktu (t.j. vylepšenia používania) s možnosťami, či ide o technické testy (testy stability, škálovateľnosti atď.) alebo skôr obchodné testy (testy procesov, používania). Dá sa povedať, že všetka práca testera v agilnom tíme spadá do niektorých z týchto kvadrantov. Pre každý kvadrant Lisa a Janet uvádzajú zoznam postupov a nástrojov, ktoré môžu byť pre neho použité. Priznám sa, že silu tejto myšlienky som pochopil až na druhé čítanie, ale o to silnejšia mi pripadá. Zatiaľ v žiadnej knihe som nevidel tak jasne a rozumne rozdelenú prácu testera s pomerne kvalitným popisom. Dokonca každý kvadrant obsahuje kapitolu o tom, čo môže tester robiť, ak tím testy v danom kvadrante vôbec nepoužíva.

Ďalšia pomerne veľká časť je venovaná automatizácii. Obsahuje štandardné zoznamy dôvodov, prečo automatizovať testovanie, zoznamy nástrojov, ktoré sa dajú použiť ako aj menej časté témy ako napríklad, čo sa automatizovať neoplatí alebo ako naštartovať automatizáciu už v bežiacom projekte. Odkaz autoriek v tejto časti je jasný: „Čo sa dá, to automatizujte.“

Posledná časť knihy by sa dala označiť ako „sprievodca testera v agilnom tíme“. Postupne sú rozoberané jednotlivé fázy od plánovania releasu/sprintu, cez samotný beh iterácie až po nasadenie. Autorky sa snažia vysvetliť, čo je hlavnou zodpovednosťou testera a o čo sa má snažiť. To snaženie nie je len tak, pretože na niekoľkých miestach v knihe som sa dočítal radu, že ak vás ako testera nezavolajú napríklad na plánovacie stretnutie, tak sa tam proste dostavte a všetkým vysvetlite, že tam musíte byť.

Ako som už spomenul skôr, pozícia testera je brána s plnou vážnosťou ako seriózna inžinierska rola v tíme. Celou knihou sa preplieta myšlienka, že tester je ten najlepší komunikátor medzi zákazníkom (alebo doménovým expertom) a programátorom. Hovoria tomu „sila troch“ a tvrdia, že ak sa má riešiť nejaký problém, tak len vždy v takejto trojici. Osobne s takýmto striktným prístupom nemám skúsenosti ale v mnohých bodoch, na ktoré je v knihe poukázané, sa s Lisou a Janet zhodneme. Každopádne kníh, ktoré by sa venovali priamo agilnému testovaniu nie je až tak veľa, aby Agile Testing nestálo za prelistovanie.

Čo sa mení, nie je konštantné, alebo prečo to bez automatizácie nejde

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