neljapäev, 18. juuni 2015

Kes, mida ja kui palju peaks testima, et oleks "piisav"?

Kui tihti oled kuulnud tarkvaraarendusprojektidest, mis eelarves ei püsi? Või ajakavas? Kui palju seda su enda projektidega juhtunud on? Kui meenus vähemalt kaks (või üks, aga hästi suur), loe edasi. Loodetavasti aitab.

Mis on testimine ja miks see aidata võiks?

Ühe rahvusvahelise definitsiooni järgi on testimine protsess, mis koosneb kõigist tarkvara elutsüklis sisalduvatest tegevustest, mis tegelevad tarkvaraprodukti ja seotud töötulemite hindamise planeerimise, ettevalmistamise ja läbiviimisega, et:
  • selgitada välja, kas ja mil määral nad vastavad nõuetele;
  • näidata nende sobivust eesmärgi saavutamiseks ning
  • leida vigu.
Mida paremini sobib tehtud töö eesmärgi saavutamiseks ja vastab nõuetele, seda vähem peab tööd ümber tegema. Mida varem vead leitakse ja parandatakse, seda vähem tuleb tööd ümber teha. Aga sellest kõigest varsti lähemalt.

Kõige Olulisem Küsimus

Kõik ASA inimesed – kvaliteedikonsultandid, testijuhid, testijad – kuulevad nii müügitegevuses kui ka igapäevastes vestlustes sageli küsimust: „Kui palju peaks testimisele aega/raha kulutama?“ Et aga ainult suhtarv ütleb vähe, sõnastame küsimuse natuke laiemalt:

Kes, mida ja kui palju peaks testima, et oleks "piisav"?

Kirjutise järgnevad peatükid otsivadki antud küsimusele vastust, andes huvitatud lugejale vihjeid edasiseks lugemiseks. Kuna testimine ja tarkvaraarenduse kvaliteeditegevused üldisemalt on üsna lai teema, ei ole antud artikli skoobis võimalik pakkuda enamat põgusa sissejuhatuse andmisest.

Testimise tükeldamine

Ka kõige lihtsamate infosüsteemide puhul saab võimalikke testitavaid sisendite kombinatsioone välja mõelda lõpmatul hulgal, seega on täielik testimine võimatu. Selleks, et testimine erinevate rollide vahel mõistlikult ära jagada, tuleb tööd tükeldada. Seda saab teha nii horisontaalselt, erinevate kvaliteediatribuutide kaudu, kui ka vertikaalselt, vastavalt abstratktsioonitasemetele.  Seejuures võivad teostajad erineda nii testiliikide kui ka –tasemete lõikes. Kõlas keeruliselt? Ilmselt küll. Aga tegelikult ei ole testiliigid ja -tasemed välja mõeldud mitte selleks, et keerulisem oleks, vaid vastupidi -- lihtsam. Kuna tarkvara ise on sageli suur ja keeruline, on mõistlik arendusprotsess (ja selle kvaliteedikontroll) väiksemateks loogilisteks osadeks jagada.

Testiliigid

Testimist saab jagada liikideks vastavalt tarkvara kvaliteediatribuutidele. Viimaste kategooriaid on ISO/IEC 9126 järgi 6:
  1. funktsionaalsus;
  2. töökindlus;
  3. kasutuskõlblikkus;
  4. tõhusus;
  5. hooldatavus ning
  6. porditavus.

Arvatavasti kõige tuntum osa testimisest, üldjuhul ka kõige töömahukam – funktsionaalne testimine – hõlmab esimest kategooriat. Ülejäänud kategooriad võetakse üldjuhul ühise nimetaja alla "mittefunktsionaalsed nõuded" ning nendega seondub palju erinevaid (mittefunktsionaalseid) testiliike, muuhulgas:
  • jõudlustestimine ja selle erijuhud (koormus- ja stressitestimine);
  • robustsustestimine (testimine vigaste andmetega);
  • kasutatavuse testimine;
  • paigaldatavuse testimine;
  • turvatestimine;
  • jpm.
Lisaks eeltoodule saab testimist jagada liikidesse vastavalt sellele, kas programmikood käivitatakse või mitte. Esimesel puhul, mis on taaskord tuntum, on tegu dünaamilise testimisega. Staatiline testimine, mille käigus koodi ei käivitata, võimaldab testida sisuliselt kõike alates ärinõuetest ja prototüüpidest ning lõpetades paigaldus- ja kasutusjuhenditega.

Testitasemed

ISTQB selgitab arendusprotsessi läbi 4-tasemelise  V-mudeli, milles igale arendustasemele vastab testitase:
  1. moodul- ehk ühiktestimine (unit testing) toimub arendatavale koodile kõige lähemal, testitakse loodavate tarkvaramoodulite (meetodid, klassid) toimivust vastu mooduli disainidokumentatsiooni;
  2. integratsioonitestimises (integration testing) kontrollitakse moodulite omavahelist koostoimivust;
  3. süsteemitestimise (system testing) tasemel kontrollitakse juba kogu süsteemi läbivate äriprotsesside toimivust süsteemidisaini vastu;
  4. vastuvõtutestimise (acceptance testing) eesmärk on veenduda, et süsteem teeb seda, milleks ta loodud on.

Lähtuvalt erinevast abstraktsiooniastmest ja vaatenurgast on igal testitasemel erinevad vastutajad ning eesmärgid. Näiteks vastuvõtutestimise eesmärk ei tohiks kindlasti enam olla vigade leidmine ja parandamine, vaid pigem kindlustunde tekitamine lõppkasutajates. Samuti on testija mõiste igal testitasemel pisut erinev -- näiteks arendajad peaksid kindlasti osalema moodultestimises, seevastu äripool on absoluutselt asendamatu vastuvõtutestimise tasemel.

Lisaks eeltoodule ei tasu testimist unustada ka vahetult pärast programmikoodi ülekandmist toodangukeskkonda (nö. toodangusse vastuvõtu testimine).




Varajane testimine

„Mida varem, seda parem,“ ütleb rahvatarkus. Tõepoolest, see kehtib ka tarkvara testimise puhul, nagu näitas juba Barry Boehm oma 1976. aastal avaldatud artiklis „Software Engineering“ (1976). Täpsemalt, mida hiljem avastatakse tarkvaras viga, seda rohkem on selleks ajaks valesti tehtud tööd, mida ümber teha. Mida abstraktsem on töö, seda suurem on tõenäosus teha vigu. Seega tehakse tõenäolisemalt vigu nõuete kogumise faasis. Sellest omakorda järeldub, et varajane testimine, eelkõige staatiline testimine enne kodeerimise algust, võimaldab saavutada kõige suuremat kokkuhoidu.


Oponendid väidavad nüüd kindlasti, et eeltoodud põhimõte kehtib ainult klassi­kalise koskmudeli puhul ja mitte agiilsetes arendusmetoodikates. Tõsi, inkre­mentaal­sete-iteratiivsete mudelite puhul on inkremendid/iteratsioonid lühemad kui koskmudeli kogu arendustsükkel, seega tehakse dokumen­teeri­mi­sest töötava koodini jõudmiseks vähem tööd, mistõttu on potent­siaalsed kao­tu­sed, vähemalt ühe iteratsiooni piires, tõenäoliselt väiksemad. Ometi on ka siin varajane testi­mine oluline – kui näiteks esimeses iteratsioonis on tehtud funda­mentaalne viga, tuleb selle avastamisel mitu iteratsiooni hiljem ümber teha ka kõigi vahepealsete iteratsioonide tööd.

Testimise osakaal arendusprojektis

Aastal 1988 viidi läbi uuring, kus koostati kolme ettevõtte põhjal tarkvaraprojektide käekäigu simuleerimiseks mudel ning verifitseeriti mudelit seejärel neljanda, sõltumatu projekti raames. Tulemused olid üllatavad: mudel suutis neljanda projekti käekäiku ennustada erinevates mõõtepunktides üsna täpselt.


Uuringust selgus, et antud projektimeeskonna puhul olnuks ideaalne kulutada 15% projekti töötundidest testimis- ehk kvaliteeditegevustele. Antud tulemuse tõlgendamisel tuleb arvesse võtta kaht olulist aspekti. Esiteks vajab mudel sisendiks väga detailseid andmeid projektimeeskonna võimekusest (näiteks vigade esinemise sagedust), mistõttu ei ole see üldjuhul Eesti projektidesse kohaldatav. Teiseks oli vaadeldava projekti teostajaks NASA, mistõttu olid nii meeskonnaliikmete valikul kui ka protsessides väga ranged nõuded ja reeglid. Uuringu põhjal avaldatud artiklit võid lugeda siit.

Erinevad allikad annavad erinevaid soovitusi testimistegevuste osakaalule pro-jekti kogumahus. Näiteks suuremate ERP-lahenduste puhul väidetakse see olevat 40%, mastide otsas kasutatavate telekom-seadmete puhul aga vähemalt 60%. Viimane World Quality Report näitab trendi, et testimise osakaal kogu IT-eelarvest on tõusnud viimase paari aastaga 18% pealt 23% peale ning aastaks 2014 juba 26%-ni. 2017. aastaks ennustatakse, et testimine hõlmab keskmisest IT-eelarvest juba 29%.

Kokkuvõtvalt

Peab nentima, et alguses õhku paisatud küsimusele ühtset ja konkreetset vastust, mis igas projektis paika peaks, ei olegi.

Kes peaks testima? Kõik projekti osapooled, olenevalt vajalikest testiliikidest. Testija rollis võivad olla elukutselised testijad, aga kindlasti ka arendajad, analüütikud, lõppkasutajad, administraatorid, tellijad, tootejuhid jne.

Mida peaks testima? Lähtuma peaks kindlasti kvaliteediatribuutidest, mida antud projekti puhul olulisteks edu faktoriteks peetakse.

Kui palju peaks testima? See sõltub väga palju projekti iseloomust, kuid levinud praktika on hetkel 26% kogu ettevõtte IT-eelarvest kulutada testimistegevustele.

Viimases kahes punktis võiks ühtlasi lähtuda riskihinnangust – testimine kui meede riskide ennetamiseks ei ole kindlasti kasulik, kui sellele kulutada riski realiseerumisel saadavast potentsiaalsest kahjust rohkem.

teisipäev, 2. juuni 2015

Koolitus tehnilisest testimisest - mida peab iga testija ja arendaja teadma tarkvara siseelust?

Tarkvaraprojektides jooksevad testijad ja arendajadki tihti peaga vastu seina - testitakse küll ja justkui pühendunult ja päris korralikult, aga "tavaline" testimine ei leia kõiki olulisi vigu üles. Teine ebameeldiv võimalus on, et vead tulevad välja liiga hilja - vahetult enne live'i tähtaega või juba toodangukeskkonnas, põhjustades nii kõigile osapooltele sõnulseletamatuid kannatusi. Veel tahaksid uudishimulikud tarkvaraprofid saada ka objektiivset ülevaadet oma testimise põhjalikkusest - näiteks vastusena küsimustele "Kui suure osa koodist mu testid katavad?" või "Kas mu koodis on testimata osasid?"


Ka kliendid ei ole kitsid tarkvarale kõrgete nõuete esitamisega - tarkvara peab olema kiire, teenindama suure hulga paralleelseid kasutajaid, olema turvaline ja ilma probleemideta hallatav ning edasi arendatav, modulaarne ja filigraanne. Testijad aga teavad, et kui on nõue, tuleb ka testida, kas nõue on täidetud. Mõnikord aga... nagu hästi ei oska. Ja isegi kui oskaks, siis missuguseid tööriistu oleks kõige õigem kasutada? Mida automatiseerida ja mida mitte?

Tehnilise testija koolitus käsitleb testimise aspekte, mis on olulised nii tehnilisemate ülesannetega kokku puutuvale testijale (näiteks agiilses arendustiimis) kui ka arendajale.

Põhiliseks koolituse fookuseks on meetodid, tehnikad ja tööriistad, mida kasutada "tavapärasele" musta kasti käsitsitestimisele lisaks, et leida vigu lihtsamini (väiksema aja/rahakuluga) ning kontrollida kvaliteeti terviklikumalt kui vaid funktsionaalsusele rõhku pöörates. Et kullakarvalise kasutajaliidese all ei oleks liialt siiruviiruline kood. 

Väike ülevaade käsitletavatest teemadest on järgmine:
  • koodi testikate (test coverage) - kuidas seda eesmärgistada, mõõta, kasvatada ja mitte üle pingutada,
  • tarkvara sisekvaliteedi (hallatavus, hooldatavus) hindamine - koodistandardid ja staatiline analüüs,
  • koodi käitumise uurimine - dünaamiline analüüs, profileerimine,
  • tehnilist laadi testide planeerimine ja läbiviimine - jõudlustestid, turvatestid, tarkvara töökindluse tagamine,
  • testide automatiseerimine - millal ja kuidas peaks ja ei tohiks, 
  • tehnilise testija tööriistakast ja oma isikliku tööriistakasti komplekteerimine.
Koolitus, kuhu on oodatud nii testijad kui ka arendajad, toimub juba 24. - 26. augustil. Koolitajaks on Lloyd Roden (http://lloydrodenconsultancy.com), kes on nii AKA eelmistel koolitustel kui ka erinevatel testimise alastel konverentsidel saanud positiivse tagasiside kui praktilise kogemusega mänguline treener. Koolitusel igav ei hakka! 

Lisainfo ja registreerumine aadressil maili [at] asaquality.ee.
Registreerudes enne jaanipäeva on kolmepäevase koolituse hind 1500€+KM, edaspidi 1600€+KM (sisaldab toitlustust ja kõiki materjale, ei sisalda sertifikaadieksami tasu).

Koolitus põhineb ISTQB Certified Tester Advanced Level Technical Test Analyst õppekaval ning koolituse läbinutel on võimalik sooritada sertifikaadieksam (eksami sooritamise eelduseks on ISTQB CTFL sertifikaadi olemasolu, koolitusel saab osaleda ka ilma CTFL sertifikaadita).