Jei prisimenate knygą “12 kėdžių” ir jos pagrindinį veikėją Ostapą Benderį, tai gal prisimenate, kaip jis padakė “Taigi…” ir toliau nežinojo ką pasakyt.

Jei su nežinojimu ką pasakyt susidūrė jis, nėra pagrindo manyt, kad su panašia problema nesusidursit jūs. Ypač paklausti “Kiek ištestavai?”, “Kiek liko?”, “Kiek laiko dar reikia?” ir “Kokia dabartinė sistemos būklė?”

Girdėti klausimai? O kaip su atsakymais į juos? Ar tikrai drąsiai, sąžiningai ir nesusimąstydami į juos atsakėt?

Kad šie klausimai jūsų nestresuotų, reikia iš anksto pagalvoti apie testavimo metrikas. Tai yra apie testavimo darbų ataskaitas, kuriose atsispindėtų atsakymai į visus šiuos klausimus.

Pradėkime nuo pirmų trijų klausimų:

• Kiek padaryta?
• Kliek liko?
• Kiek laiko reikia likusiai daliai?

Jie visi yra tarpusavyje susiję. Jei galim atsakyti į bent vieną iš jų, vadinasi galime atsakyti ir į likusius. Kaip pagrindą atsakymams reikia imti ne ką kitą, o testavimo atvejus arba kažką, ką naudojat vietoj jų (e.g. checklist’as). Dėja, užregistruotos klaidos čia netinka. Kodėl? Kaip paprastą pavyzdį galima paimti kokį nors sistemos komponentą, kuriam einamuoju momentu nėra klaidų. Ar tokia situacija reiškia, kad komponentas buvo ištestuotas ir jame nebuvo aptikta klaidų, ar kad buvo ištestuota dalis komponento ir klaidų nebuvo toje dalyje, ar kad komponentas dar nebuvo testuotas?

Grįžtant prie testavimo atvejų: kaip pamenate, jie turi tokius atributus, kaip prioritetas ir sudėtingumas. Prioritetas metrikų atvejų nėra toks svarbus, o sudėtingumas yra ir netgi labai

Apie tai, kiek darbo jau padaryta, galima spręsti iš to, kiek ir kokio sudėtingumo testavimo atvejų yra įvykdyta (passed/failed/warning). Pirmiausia apskaičiuojam įvykdytų TA dalį lyginant su visais TA (tam tikras procentas). Po to apskaičiuojam kiek TA liko įvykdyti (blocked/not run). Jau gaunam savotišką rezultatą. Tas savotiškas rezultatas bus galutinis, jei sudėtingumai nenaudojami.

Jei sudėtingumai naudojami, tai skaičiuojame ne TA kiekį, o jų sudėtingumus. Tarkim, jei yra 10 paprastų, 20 vidutinio sudėtingumo ir 30 sudėtingų TA, tai viso turėsim ne 60 TA, o 10*1 + 20*2 + 30*3 = 140 sąlyginių vienetų, kurie tiesiogiai įtakoja testavimo laiką (čia 1, 2, 3 – testavimo atvejo svoris pagal jo sudėtingumą). Tada skaičiuojam kiek sąlyginių vienetų jau praeity, o kiek mūsų dar laukia ateity

Į klausimą kiek laiko liko – tiesiog perskaičiuojam testavimo laiko neįvykdytai TA daliai (žr. čia ir čia).

Dabar apie būklę ir iš tos būklės kylančias rizikas:

1. Būklė nustatoma pagal atvirų/neišspręstų klaidų skaičių. Būtų labai gerai, jei klaidos būtų rišamos su TA (apie tai čia), tada būtų paprasta pasakyt kurie TA ar kurios TA grupės liečia labiausiai nekokybiškas sistemos dalis. 
2. Didžiausią riziką kelia tos dalys, kur yra daugiausia “blocked” testavimo atvejų – jie negalėjo būti vykdyti dėl to, kad klaidos atsirado prieš juos esančiuose TA.
3. Didžiausią dėmesį reikia skirti toms sistemos dalims, kuriose, lyginant su kitomis, buvo aptikta daugiausia klaidų – klaidos yra socialinės būtybės: kur jų daug, ten jų ir bus daug iki pat pabaigos, o kur jų nėra, ten jos vargu ar atsiras dideliais kiekiais
4. Norint parodyti kaip sunkiai dirbo programuotojai, klaidų suvestinėje reikia pažymėti kiek klaidų buvo užregistruota iš viso, ir kiek iš jų šiam momentui liko atviros.

Kokia forma visa tai pateiksit – čia jau jūsų asmeninis reikalas TA valdymo sistemos dažniausiai turi numatytas ataskaitas. Pvz.: TestLink sistemoje galite lengvai sugeneruoti iš esmės visas reikalingas metrikas. Kitas reikalas, kad tų metrikų “prekinė išvaizda” kiek šlubuoja, bet tai pataisoma Word’o/Excel’io pagalba

Šiam kartui tiek.