Nagu Urmo eelnevas postituses kirjutas, oleks hea aruteludele järgnevalt teha kokkuvõtteid ning sõnastada iseenda ja teiste jaoks kõige olulisemad järeldused. Teen sellega ise kohe algust ning soovitan sama ka teistele!
Üks minu eesmärkidest workshopile tulles oli saada selgust ning teiste osalejate arvamusi teemal, kuidas testija töö headust hinnata eelkõige "ette", juba testimise protsessi käigus - enne kui ilmnevad mingid tagajärjed toodangus. Antud infot vajab hädasti näiteks testijuht, kes projekti käigus peab hoidma silma peal testijate töö kvaliteedil ning vajadusel suunama testijaid paremini testima (oluline on ju ikkagi tulemus mitte lihtsalt töö ärategemine!). Lihtsad mõõdikud, näiteks leitud vigade arv ei ütle tegelikult palju selle kohta, kui palju ja kui kriitilisi (!) vigu veel leidmata võib olla. Etteruttavalt ütlen, et sellele küsimusele ei saanud ma päris aktsepteeritavat vastust ka arutelu käigus.
Siiski sõnastaksin enese jaoks kõige kasulikumad ja kasutatavamad järeldused meie arupidamisest järgnevalt:
1. Testimise väärtust on ilmselt küllalt edukalt võimalik hinnata tagantjärele (pärast vigade leidmist arenduse käigus või toodangus) - tuleb kokku arvutada kõigi vea haldamise ja parandamisega seotud inimeste töötunnid (alustades helpdeskist, lõpetades arenduse, kordustestimise ja toodangusse panemisega). "Pehmete" kulude nagu inimeste (klientide ja arendusega seotud) närvid, kahjud mainele, saamata jäänud tulu mõõtmine ei pruugi olla nii lihtne, kuid ka sel juhul on meetrika kasutatav.
2. Väärt testija puhul on oluline oskus valida konkreetsesse arendusolukorda sobiv lähenemine (plaanist, sh testimise maht, meetodite ja vahenditeni) ning osata seda usutavalt põhjendada. See annab kindlust, et testija on professionaal ja olulised aspektid saavad piisavalt testitud. Eellest lähtuvalt on info, mis on testija töö tulemiks, kvaliteetne ning selle põhjal on võimalik teha õigeid otsuseid.
Kui järele mõelda, siis tegelikult selle järgi saab mingil määral hinnata testija töö headust ka "ette". See hindamine aga on pigem subjektiivne, kui mitte öelda intuitiivne.
Igal juhul püüan edaspidi antud järeldusi ka praktikas testida ja soovitan seda teistelegi huvitatutele - see tagab, et mõne aja pärast saame selle teema juurde jälle tagasi tulla. Sel korral aga kogemuse võrra rikkamana.
Head testimist!
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
Lisaksin ühe mõõdiku mis käidi välja EuroSTAR-il. Nimelt võiks hinnata testijat vastavalt sellel kui palju pareneb selle tiimi, mille osaline ta on, toodetav kood/tarkvara/etc... Idee on selles, et testija, peale info jagamise, peaks andma panuse ka üldisesse QA-sse, ntx. näitama arendajale kus ta tihti vigu teeb, analüütikule tema tüüp vead nõuete koostamisel, etc. Järelikult võiks üheks mõõdikuks olla terve tiimi toodetava "asja" kvaliteedi paranemine. Mis arvate?
Töö käigus testimise hindamiseks ei ole samuti kahjuks midagi head leidnud, kuid tagantjärele tarkusena testimise hindamiseks leidsin oma toredalt plakatilt (http://deltaaxiom.com/C1256ED60045E95F/sysOakFil/plakat-konfigurationsstyring_T_amj/$File/P-T-axiom-0707.pdf) terve rea kriteeriume:
- planeeritud tegevuste progress
- loodud testilugude hulk
- käivitatud testilugude hulk
- positiivsete testilugude hulk
- vearaportite hulk
- vigade parandamise käigus tehtud uute vigade hulk
- soovitud kaetuse ulatus (%)
- tarkvarasse jäänud vigade hulga prognoos
- maandamata riskide alad
- tegelik vs. planeeritud aeg
- tegevuste tegelik tööpanus
- vigade leidmise protsent -> milline testimistegevus on kõige efektiivsem + milliseid testimisprotsesse saab täiustada
- probleemide hulk komponendi kohta -> probleemide jaotus tootes
- probleemide jaotus vea tüüpide kaupa
Et neid testimise hindamise mõõdikuid rakendada, peab esmalt selleks ka vajalikke andmeid koguma.
Nende andmete kogumise korrektsus (kehtestatud raporteerimise reeglitest kinnipidamine) omakorda võib olla testija töö üheks mõõdikuks.
Post a Comment