Proeksperdi testijate treeningpäevast, common sense’st ja testianalüüsist

Väljas on veel parasjagu külm. Mitte küll nii pakasene, kui veebruari alguses, aga siiski miinuskraadid. Seega viimane aeg kirjutada, kuidas me kuu aja eest Proeksperdi Testimise Treeninglaagri korraldasime. Alguses sai arvatud, et tegu saab olema ühe off-site päevaga, kuid ettevalmistuse käigus sai sellest kokku korralik boot camp.

Miks me nii tegime?

Põhjused on lihtsad – kommunikatsioon ning kogemuste vahetamine. Proeksperdi Kvaliteediarenduse meeskonnas (Quality Engineering Team, edaspidi QE tiim) töötab kirjutamise hetkel 20 inimest. Üks tiimi juht, teine tehniline kirjutaja ja kõik ülejäänud kvaliteediinsenerid (QA Engineer), igapäevatöises kõnepruugis tuntud ka kui testijad. Pea kõik kvaliteediinsenerid töötavad omaette tarkvaraarenduse projektimeeskondade juures ehk siis kõik QE tiimi liikmed on hajutatud laiali üle terve Proeksperdi. Mõned neist suisa teistes majades kliendikeskkonnas.

 

QE tiim ja common sense

Testijate üle ettevõtte hajutamisel on kindlad eelised, kuid sellega kaasnevad samuti mõned miinused. Hea, et Proeksperdi QE tiim keskendub ühtlaselt reaalsetele tarkvaraprojekte läbi viivatele meeskondadele, mitte ei ürita olla musta kasti laadne „testijate osakond”. Üks kvaliteediinsener saab suunata terve projekti jooksul tähelepanu oma projektimeeskonnale, korraldada seal testimist ja jälgida, et kogu projekti korraldamine toimiks mõistlikul ja üle ettevõtte kokku lepitud viisil, järgides seejuures common sense ehk ühise kaine mõistuse põhimõtteid.

Millised on miinused? Eks miinused tulenevadki eeliste varjukülgedest. Hajutatus annab meile suurepärase projektimeeskonna sisese kommunikatsiooni, kuid ahendab suhtlust QE tiimi liikmete vahel. Olemas on küll mõnusalt loitev tiimitunne ja ühised õlled saunaõhtul, kuid organiseeritult, homogeenset erialase teabe vahetust puhkenurgas päris niisama lihtsalt ei teki. Inimesi on tiimis päris palju. Järeldus on lihtne. Pole stabiilset infovahetust, seega ei saa olla ka seda, mida me nii väga common sense’ks nimetada tahaksime. Ehk siis oma hajutatusega oleksime justkui olukorras, kus kogenumad saavad kogenumaks ja vähema staažiga meeskonnaliikmetele jääb üle kogemuse omandamise pikavõitu raja läbikäimine – tihti ennekõike omaenese valusatest vigadest õppides.

 

Jagamine rokib

Kuigi vahest võib näida, et neil, kes teavad palju, pole mahti oma teadmisi jagada, pole asi tegelikult nii hull. Pigem on probleem töökorralduse iseärasustes. Tegelikult meeldiks meile kõigile, kui kaasvõitlejad teaksid, mida ise elementaarseks peame. Toimub ju ühine töö ägedas ettevõttes, kus iga inseneri kogemuste tase on tiimi ja lõppkokkuvõttes terve Proeksperdi tase.

Kuidas siis võimalikult ühtlast teadmiste jagamist korraldada? Tiim peab kokku saama. Ning kokku me saamegi. Lisaks muhedatele tiimiõhtutele korraldame paar korda kuus poolteist tundi kestvaid kogemuste jagamise ettekandeid. Mis on küll hea, aga mitte ideaalne lahendus. Üks räägib, teised kuulavad ja küsivad. Oleks vaja midagi intensiivsemat, mis paneks kõik võrdsesse olukorda. Vastuseks on treeninglaager!

 

Kes minevikku ei mäleta, selle jaoks on projekt uus

Testijate treeninglaager tundus hea mõte. Algselt küll tiimi väliüritus egiidi all „pikk päev väljas”, aga kava kokku pannes tekkis arusaamine, et ühes päevas polegi nii palju tunde. Esimese treeningpäeva tingimuseks oli, et teeme kõik ise. Ise selle pärast, et oleme küllalt tark ja elukogenud tiim ning meil on tegelikult teineteisele palju öelda. Vähemalt enne, kui mõne välise guru kõnelema kutsume.

Alguses oli ideid teemadeks ohtralt: usability’st automatiseerimiseni, kuid esmapilgul lõpmatusena tundunud kaheksast tunnist jäi peagi alles vaid kuus ja pool. Organiseerimine nõuab oma osa. Keskenduda tuli olulisele – mis meil olemas on ja milline on meie teadmiste ühisosa.

Meil on olemas fantastiline Proeksperdis arendatud, enam kui kümne aastase ajalooga tarkvaralahendus BioXpert. Tähendusrikas projekt, millest Proekspert õigupoolest alguse saigi ja mida on testinud ka selle kirjatüki autor. Viimane pole üldse vähetähtis, sest tarkvara toimimise põhimõte on tausta teadmisteta esmapilgul hoomamatu ja ülejäänud QE tiimi liikmetel oli senine kogemus BioXperdiga pea olematu. Kõlab just kui päris tarkvaraarenduse projekt.

Nimetatud tarkvara erilisteks plussideks on väga selgepiiriline modulaarsus ja keerukad seadistusliidesed ehk wizard’id. Noid on rakenduses vähemalt viis toekamat ja seega viieks kolme liikmega grupiks treeningul osaleda saanud QE tiimi liikmed väga hästi jagunesidki.

Gruppidesse jaotamise põhimõte oli lihtne. Et mitte aega raisata vaidlustele ja loosidele, lõid korraldajad kõik segamini: erinevad kogemused, erinevad näod. Grupi juhiks sai selle kõige tagasihoidlikum persoon, kes pidi korraldama rollid ja tööülesanded nii, nagu parasjagu oskas.

Täpsustuseks märgin, et kuna BioXpert on isegi seda kunagi kuude kaupa testinule installeerimiseks küllaltki tülikas ja komplitseeritud tarkvara, siis otsustasime loobuda mahlakast installatsiooniprotsessi kogemuse jagamisest ning valmistasime testikeskkonna eelnevalt ette. Kõigile gruppidele oli määratud arvuti virtuaalmasina ja juhistega – juhuks, kui tarkvara tavatult käituma hakkab. Sellele lisaks loomulikult ka tarkvara disaini ja kasutuse dokumentatsioon as is kujul.

 

Iga paat valib oma kalda ise

Grupid teada, vastutajad samuti. Iga seltskonna juht teadis üritusele eelneval õhtul oma tulevast projekti ehk lahendatavat wizard’it. Teadis ka päevakava, mille jagasime kolmeks osaks:

  1. Esimene osa (2,5 tundi)
    • UML-diagrammide joonistamine
    • Ettekanne ühe tiimi poolt
  2. Teine osa (2 tundi)
    • Testimise plaani koostamine
  3. Kolmas osa (2 tundi)
    • Testimise plaani kaitsmine tiimide kaupa
    • Päeva kokkuvõte

Ühesõnaga, joonista oma wizard’i peale skeemid ja ole valmis neid selgitama. Siis koosta plaan, kuidas viid läbi oma wizard’i testimise ja lõpuks selgita oma valikuid nii, et teised kah usuksid sinu väikese tiimi edusse. Käed vabad, lased vaimul lennata ja vali ise oma tee lahenduseni.

 

Kui pilk ei hooma, joonista – kui hoomab, joonista ikka

Võib-olla kõlab lihtsalt, aga mis UML? Loomupäraselt puutub iga projektimeeskond kokku tarkvaraga, mis vajab uuendamist. Ehk siis midagi on olemas, aga klient tahab, et Proeksperdis tehtaks igasugu ägedaid asju juurde. Sellise tarkvara dokumentatsioon on just nimelt selline, nagu ta parasjagu on: kindlasti mitte täiuslik. Kui nüüd veel midagi juurde arendada, on ootamatused kiired tekkima. Suure tõenäosusega olemasolevast ja juurde tekitatud dokumentatsioonist ei piisa, et igasugu nurgataguseid main use case väliseid vigu ja anomaaliaid tuvastada. Mis aga aitab, on funktsionaalsuse skeemidel lahti joonistamine.

Tüüpilise algaja testija käitumine tundmatule tarkvarale teste luues on testisammude kirjutama asumine. Seda viga olen korduvalt teinud isegi, uppudes hiljem kombinatsioonide rägastikku ja üsna kindlalt paljud kordavad. Õppisin targematelt, nüüd õpetan teistelegi. UML kirjeldusviis pole loodud niisama ja see ei pea olema vaid analüütikute tööriist. Eriti, kui üks testija on tihti omaette analüütik.

Analüüsida on testijal palju. Kuigi Scrum ja agiilne lähenemisviis üritavad testija rolli arendusmeeskonna ühiseks tegevusosaks sulandada, ei pääse üle eespool mainitud olukordadest. Meil on olemas vana funktsionaalsus, millest me ei tea suurt midagi. Meil on juba kuidagi loodud uus funktsionaalsus, millest me samuti suurt midagi ei tea. Ja kõigele lisaks tahab klient funktsionaalsust, mis ei tarvitse kõigi osapoolte parimatest soovidest hoolimata olla see, mida ta tegelikult väljendas. Kõlab karmilt, aga tootmismaailmas igiammune probleem. „Ütlesin ju, et tahan asja, millega põrgatada, miks te mulle kurika asemel palli tegite?!”

Testija missioon on võimalikult vara mõista, et tema peaks kurikat testima, mitte lootma eksikombel nõuetesse sattunud palli kirjeldusele. Seegi tuleb joonistades ehk suure pildi selgelt esile toomisel kiirelt välja, sest tarkvara funktsionaalsuse toimimise skeeme koostades satume alati küsimuste otsa. Neid küsides leiab ka vastused, mis võivad sillutada teed tegelike ootuste avastamiseni.

Testija kui analüütiku rollis on veel oluline mõista, et peamine kasutusjuht on enamasti kõigile arusaadav, vähemalt selle arendanule endale. Mõistlik ja enesest lugupidav arendaja hoolitseb, et tema realiseeritud use case töötaks. Tihti töötabki, aga ikka tuleb tarkvaras vigu esile. Teada on, et mida hiljem leitud viga, seda kallim selle parandamine on. Varakult olemasolevate, loomisel või äsja loodud kasutusjuhtude lahti joonistamine on see, mis aitab ja juhib meid kiirelt kohtadeni, mida arendaja või algse idee analüütik ette ei näinud. Need on nurgatagused juhud, millele kogenud arendajad viitavad rääkides, et õige testija peab tarkvara kangutama, lõhkuma ja vigu otsima. Vigu saab otsida kogemuste põhjal, tarkvara üdini tundes, kuid ka siis võib kahe silma vahele jäänud haru meid ootamatu exception’i juurde juhatada.

 

Tagasi treeningpäeva juurde

Tarkvara funktsionaalsuse käitumisskeemide joonistamine pole Proeksperdis midagi revolutsiooniliselt uut. Kogenud testijal on see selliselt käes, et keegi ei märkagi, kuidas tahvlile või paberile harud tekivad. Lisaks on ettevõtte wikis soovitused ja juhised ammuilma kirjas. Oluline on hoopis, kuidas tekib soovitud common sense. Seda skeemide teemat võib igaüks mõista erinevalt, vastavalt kogemusele, kuuldule või loetule. Ent on äge, kui erinevad inimesed joonistavad enda analüüsi skeemiks nii, nagu parasjagu parimal viisil oskavad ja siis neid võrdlevad. Kohtab avastamist ja „ahhaa, nii saab ka” efekti, mis on tunduvalt mõjusamad kui igapäevatöös katsetamine.

Treeningpäeva esimese poole tulemused olid erinevad. Iga tiim tegi põhimõtteliselt sama asja, joonistas diagramme, kuid lähenes lahenduse kujutamisele üsnagi erinevalt. See erinevus avaldus just teise osa töö esitlemisel, mille käigus pidi teiste ees oma grupi testimise plaani kaitsema. Sõnastasime „testimise plaani” nime taotluslikult „testiplaanist” erineva, et ei tekiks ISTQB ainetel krampi testiplaani koostamiseks. Eesmärk oli piiratud aja jooksul tõestada ja demonstreerida, et väike tiim testib ära kogu funktsionaalsuse, mitte rõhuda vormistamisele.

Nõnda näidatigi. Mõned tegid täiusliku joonise sõrmega järje ajamiseks ja kattuvuses veendumiseks. Mõned koostasid joonise järgi klassikalised test case’d. Üks grupp läks aga FitNesse automaattestide kirjeldamise teed.

 

Mida me sellest kõigest õppisime?

Kaine aja planeerimine ja time boxing töötab! Päeva ettenägelik planeerimine aitas ürituse õnnestumisele väga palju kaasa. Midagi sellist organiseerides tuleb arvestada, et kujuteldav tund kahaneb reaalsuses 10 minutiks. Arvestasime. Ja päev töötas praktiliselt minuti pealt. Kõik said sõna, kõik tööd ja teemad olid lõpuks kaetud. Treeningpäeva lõpus toimuva kokkuvõtte osa hakkis kahjuks ära planeerimata elektrikatkestus, aga sellestki saime üle. Projektorist olulisem on alati enese arusaadav väljendamise oskus.

Arvame, et kõik teavad juba seda, mida mina tean, aga tegelikult ju ei tea! Üllatuslikku informatsiooni jagamist tuli päeval piisavalt ette. Säherdune treeningpäev on suurepärane viis kogemuste jagamiseks ja uute asjade teada saamiseks. Asusime pealtnäha lihtsate ülesannete juurde, kuid lahenduskäigud näitasid, et me kõik mõtleme ja mõistame asju erinevalt. Järelikult on teineteiselt veel palju õppida.

Meeskonnavaim loeb (ja mitte vähe)! Külmas on küll sant istuvat tööd teha, aga kui on huvi, saab kõigest üle. Kuradi külm oli, ausalt! Jope, sall ja müts olid vajalik kostüümi osa. Kes sai, see kasutas kindaid ka. Jagunesime Laitse konverentsiruumides kahte saali ja see, mis vähem külm oli, lõhnas rallipargist sisseimbuva tärpentiini järele. Aga mehed ja naised ei kaebanud vaid rebisid keskendunult tööd murda. Meil on väga äge tiim! Ilma sellise meeskonnata poleks midagi taolist korraldada saanud. Aitäh!

2 thoughts on “Proeksperdi testijate treeningpäevast, common sense’st ja testianalüüsist”

  1. Väga äge üritus. Tore kuulda et testijate ürituste korraldamine on hoogu kogumas üle eesti. Kas tohib uurida kes antud teema välja mõtles ning kas antud tulemusi oleks võimalik ka näha?

    Kas toimus ka teiste poolt devil’s advocate’imine või oli lihtsalt loomine ja esitlemine? Lisaks kas oli kohal ka projekti nn “klient”, kellele seda esitati ning kellelt ka hinnangut saadi?

    Oliver Vilson

  2. Tänud! Teema saigi ise päris vajadustest tuletatud ja meeldiv üllatus oli nädal hiljem avastada, et juba võetigi treeningpäeval kogetud töövõtteid üle. Paraku ei mõelnud ürituse korraldamisel ette, kuidas tulemusi n-ö vabalt jagatavana vormistada. Eks näis, ehk leiab kunagi aja mingid näited kokku panna ja asjast lähemalt kirjutada.

    Tiimi töö kaitsmine oli seekord suhteliselt leebe, sest ajapiirangud ei lubanud pikematesse sõnavahetustesse laskuda. Oluline oli, et mõtle, tee ja demo nii, et teised aru saaksid, miks just sellise lähenemisviisi või lahenduse valisid. Mõttelise kliendi osas sain olla ise, kuna olin ainus, kes tarkvaraga põhjalikumalt kokku oli puutunud. Sellele rollile ma siiski suurt rõhku ei pannud. Ajalised piirangud. Rohkem sai vaadatud, kuidas selle lühikese ettevalmistusaja jooksul pöörati tähelepanu detailidele, mis ennast kunagi üllatasid.

Leave a Reply

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