Testijad ja arendajad – või ikkagi meeskond?

Käesoleva aasta juunis toimus Tallinnas teist korda rahvusvaheline Nordic Testing Days (NTD) 2013 konverents, mis keskendub testijate kultuuri arendamisele Eestis ja Põhjamaades.

NTD 2013 korraldus oli eelmisest korrast toekam ja fookus kaasaegne – loenguid ja töötubasid läbivaks teemaks oli Testers and Developers – Partners in Quality. Ilmselt oli lugu ka kuulaja valikutes, kuid kaks märksõna, mis loengutest ja töötubadest kummitama jäid, olid teamwork ja automation.

NTD 2013 koosnes kokku kolmest päevast. Esimene päev oli tutorial’ite päralt, teine ja kolmas aga olid tihedalt täis erinevaid ettekandeid ning töötube.

Proeksperdi panus NTD 2013 õnnestumisse

Automatiseerimise rõõmude ja murede lahkamine on ka Proeksperdi jaoks hingelähedane. Kui eelmisel aastal viisime Mati Parve eestvedamisel läbi ühe automatiseerimise teemalise töötoa, siis sel aastal oli meil kogemusi juba topelt jagada.

Mati Parve BDD ja Test Automation: How not to shoot yourself in the foot jätkas vahepeal kogetuga BDD teemat ja meie

2013-06-19 15.55.36värske mehena oli väljas Valdo Purde: hands on Selenide töötoaga Automated Testing with Selenide. Viimase tegi ägedaks hetk, et seda oli kuulama tulnud ka Selenide looja, Andrei Solntsev, kes isiklikult üritusele tunnustavat tagasisidet jagas.

Konverentsist endast

Teema testijatest ja arendajatest kui käsikäes partneritest on vägagi kõnetav. Proeksperdis on küll juba ligi 5 aastat teadlikult Scrumi ja teisi meeskonnapõhiseid tarkvaraarenduse lähenemisviise rakendatud, kuid siiski esineb aeg-ajalt probleeme arendajate ja testijate vahelise koostööga. Seda põnevam on teada, kuidas selles osas ülejäänud maailmal edeneb.

Järgnev toobki lugejani minu jaoks enim muljet avaldanud ettekanded ja mõtted.

Esimene päev

Lõbusa avaettekande pidas Webmedia (Nortal) endise juhina tuntud Taavi Kotka (Majandus- ja Kommunikatsiooniministeerium). Tema kõne üks oluline mõte pärines vestlussaatest, kus Louis C. K rääkis, et elame küll imelises tehniliste mugavustega maailmas, aga pole selle juures ikkagi õnnelikud, sest keskendutakse pisiprobleemidele – ega osata näha suurt pilti, mil moel sellise arenguni jõutud on.

Mis puutus konverentsi üldise teemaga haakumisse, siis tuleb Kotkale ette heita liigset testijate ja arendajate vastandamist. Vihje, et testijad on mõtlevad olendid ja arendajad vaid koodirobotid, oli tore nali sihtgrupi suunas, kuid sisuliselt liiga äärmuslik. Samas oli tore nentida, et kui mõista testija ehk the last man standing viimase sõna olulisust, pole vaja asjatult karta kiirustades reliisitud süsteemi kokkuvarisemist.

Mis saab testimisest tulevikus? Esineja spekulatsioonide põhjal on tulemas väga põnevad, katsutavad ja graafilised ajad (kerge maitseproov).

Minu enese fookus oli ettekannetel. Esimese päeva üks eredamaid loenguid tuli Lloyd Rodeni poolt – Building successful teams. Lisaks tavapärasemale metoodikale, ehk kuidas viia meeskonnad koostööle ja millised isikuomadused meeskonna koostööd mõjutavad, meeldis mulle tema testija mõtteviisi abil rakendatud analüüsi metoodika.

Ülal viidatud ettekande sisalduv tester’s style analysis küsimustik annab pildi tugevustest, mida täitja ise endal arvab olevat. Lisaks enese testimisele on küsitlust huvitav läbi viia oma projektimeeskonnas, et teada saada, kas ka teised sind sarnaselt näevad.

Küsimustiku enese täitmine oli lihtne, sarnane isiksust hindavale DISC küsimustikule – pole õigeid ega valesid vastuseid ja vastata tuleb kärmelt. Siin kerge näide:

2013-07-02 18.56.41Võrdle kaht iseloomustavat sõna ja otsusta igapäevaseid tööolukordi arvesse võttes, kumb sinu puhul rohkem kehtib. Vastuste järgi jagatakse testijad neljaks tüübiks: Pragmaatik (Pragmatist), Teerajaja (Pioneer), Analüütik (Analyst) ja Korraldaja (Facilitator). Igal tüübil on omad head ja vähem head käitumisomadused.

Saladuskatte all võin öelda, et näen end pioneerina. Pioneerile ehk teerajajale on omased uued ideed, avatus, muutused ja teiste kaasamine. Samas ei meeldi talle standardid, normid ning paberimajandus. Kui kedagi huvitab see test ise läbi teha, siis minu käest saab soovi korral vormi.

Lisaks veel Friday afternoon bug hunting soovitus testimisele teise nurga alt lähenemiseks ja meeskonnaga ühtsele rajale saamiseks. Proovisin selle enda peal ära ja see töötab – hea nipp, kuidas ühe korraga suur pilt jälle tagasi saada.

Üks tehniline, ehkki meeldejääv loeng oli Rene Tuinhout Passionate partnering for Testers, milles segati lõbusalt kokku erinevad testimise tehnikad ja argielu.

Kes teab, siis TTÜ õppejõud dr Jaak Tepandi ütleb, et funktsionaalse testimise puhul vaatame programmi kui musta kasti, sest me ei tea tema siseehitust – teame vaid sisendeid ja väljundeid (spetsifikatsiooni). Kui juhtus, et Tepandi loengus jäid mõnel kuulajal testimise tehnikad segaseks, siis too loeng aitas nii mõndagi selgemaks saada.

Näiteks, inimestel on teiste suhtes eelistused, mille järgi neid gruppidesse saab jagada – neile meeldivad kas mehed või naised või siis näiteks noored naised ehk pigem vanad mehed. Sarnaselt toimivad ekvivalentsiklassid (Equivalence Partitioning), mille kasutamise põhiideeks on eeldus, et sarnaste andmete puhul käitub programm samal viisil.

Teise toreda näitena on viis erinevat testitüüpe meeldejäävalt kokku võtta ehk PERFUMe meetod: sobitatavus (Portability), tõhusus (Efficiency), töökindlus (Reliability), funktsionaalsus (Functionality), kasutuskõlblikkus (Usability) ja hooldatavus (Maintainability). Vastavad küsimused päris elus on: kas ta on valmis kolima; kas tal on kõrge stressitaluvus; kas ta on usaldusväärne?

Nali naljaks, aga kõiksugu kuivade mõistete seletamine läbi päriselu analoogiate on oluline oskus, mis ei tule mitte ainult kasuks teooria kiirel mõistmisel, vaid ka keerukate süsteemide loomisel ja testimisel.

Esimeselt päevalt koju tagasi liikudes mõlkusid peas erinevad head mõtted. Tuleb tugineda enda tugevustele ja samas arendada enda nõrkusi, et ka nendest kord tugevused saaks. Pikalt ühe ja sama tarkvara kallal nokitsedes on lihtne juhtuma, et klammerdud kasutusjuhtude happy path’ide külge ja unustad, et kusagil on olemas ka tarkvaras ringi ekslev lõppkasutaja.

Tuleb end jälgida, märgata muutusi ja teha korrektuure. Testimisel mõtle kastist väljas ja soovi alati näha suuremat pilti, sest mida lähemal sa vaadatavale oled, seda vähem sa sellest tegelikult näed.

Teine päev

Teist päeva alustas karismaatiline Anton Keks (Codeborne’i kaasasutaja) väga inspireeriva ettekandega. Võib-olla aitasid kõigele kaasa tema lahedad joogapüksid, aga see selleks. Antoni jutust jäi kõlama julge mõte: on kahte sorti teste – regressioonitestid ja kõik ülejäänu. Ehk siis, elu on liiga lühike, et teha manuaalseid regressiooniteste.

Tuntud mõistele code smells vastavalt eksisteerivad ka tests smell ehk riknenud testid. Meeskond peab fokusseerima olulistele asjadele, mitte raiskama aega kohmakatele reliisimistele või tuhandete testide haldamisele, mis juba aastaid midagi ei testi. Taaskord, automatiseerimine – mida kusjuures tehakse ühtse tarkvara arendava meeskonnana – mitte ei ühed ei oota, kuni teised selle ette võtavad. Mulle endale meeldib väljend “Kui laevas on auk, lähevad kõik põhja”.

ProÜlikoolil on vend TeX!

Kes ei tea, siis Proeksperdis on ProÜlikool ehk ettevõtte sisemiste teadmiste jagamise keskus, mille elujõud tugineb meie endi inimeste aastakümnete vanusele traditsioonile oma töökogemusi teistega vahetada. Seetõttu oli eriti inspireeriv Magnus HillermaaHelping Engineers to grow loeng, milles ta rääkis, kuidas käib kogemuste jagamine Skype’s, kus see on TeXi (Technical Exchange) näol jõuliselt ette võetud. Proekspert on ehk selle koha pealt natuke lapsekingades, kuid oluline on, et meil on mõttekaaslasi ja me liigume õiges suunas. Loodetavasti saame mõnegi idee realiseerida ka Proeksperdis. Nagu meil maal öeldakse: sheering is keering.

Päeva lõpetas Margus Simson väärt mõttega, et ühe õige tarkvaraprojekti edu indikaator on meeskonna usk. Kui kogu meeskond usub projekti õnnestumisse juba selle alguses, siis väga suure tõenäosusega see ka õnnestub. Kui meeskonnas on kahtlusi, et antud aeg, ressursid või  oskused ei kanna projekti välja, siis elu näitab, et see nii ka läheb.

Kokkuvõtteks

Nende kahe intensiivse ettekannete päeva jooksul sain kinnitust paljudele mõtetele: äärmiselt oluline on, et sinu meeskonnas oleksid õiged inimesed; et meeskond omavahel suhtleks; et kogu meeskond võtaks vastutuse. Ja mis kõige olulisem, tuleb teha olulisi asju ja hoiduda nüridest, korduvatest tegevustest neid automatiseerides.

Mis peamine, lahti tuleb saada MINA ja SINA mõtteviisist. Minu töö ei ole vaid testimine ega sinu töö ainult arendamine. MEIE koos loome tarkvara, mis aitab maailma parandada!

1 thought on “Testijad ja arendajad – või ikkagi meeskond?”

  1. Oli tore lugeda!
    Tuleksin ketserlikult ühe kunagise AK mõtte juurde, et testimine kui eraldiseisev üksus on arendajad ära rikkunud. Suhtumine, et arendaja purtsutab mingisuguse asja valmis ja testijad lihtsalt leiavad vead ülesse on palju halba teinud. Selline illusioon on väga ohtlik. Arendajal kaob igasugune side ja vastutus lõpptootega. Sellisel juhul ei ole arendaja enam loov ja efektiivne. Tegelikult peaks olema see suures osas arendaja vastutus, et tuleks välja hea asi. Hea asi on see asi mis aitab klienti ja on veavaba. Ilmselt peaks arendajad testima rohkem ja testijad rohkem arendama ja kas siis ongi eraldi inimesi.

Leave a Reply

Your email address will not be published. Required fields are marked *