Pastaraisiais metais automatizuotas testavimas tapo programinės įrangos kūrimo tendencija, tam tikra prasme jo įgyvendinimas tapo „duoklė madai“. Tačiau automatizuotų testų diegimas ir priežiūra yra labai daug resursų reikalaujanti, todėl nepigi procedūra. Plačiai paplitęs šios priemonės naudojimas dažniausiai sukelia didelių finansinių nuostolių be jokio reikšmingo rezultato.
Kaip galite naudoti gana paprastą įrankį, kad įvertintumėte galimą automatinių projektų testų naudojimo efektyvumą?
Kas apibrėžiama kaip testavimo automatizavimo „veiksmingumas“?
Dažniausias efektyvumo (pirmiausia ekonominio) vertinimo būdas yra investicijų grąžos apskaičiavimas(IG). Jis apskaičiuojamas gana paprastai, tai yra pelno ir sąnaudų santykis. Kai tik IG vertė viršija vieną, sprendimas grąžina į jį investuotas lėšas ir pradeda pritraukti naujų.
Automatizavimo atveju pelnas reiškia sutaupyti atliekant rankinį testavimą... Be to, pelnas šiuo atveju gali būti neakivaizdus – pavyzdžiui, inžinierių, kurių laikas buvo atlaisvintas dėl automatizavimo, ad-hoc testavimo proceso defektų radimo rezultatai. Tokį pelną gana sunku apskaičiuoti, todėl galite daryti prielaidą (pvz., + 10%) arba jos praleisti.
Tačiau taupymas ne visada yra automatizavimo tikslas. Vienas pavyzdys yra testo vykdymo greitis(tiek pagal vieno testo atlikimo greitį, tiek pagal testavimo dažnumą). Testavimo greitis verslui gali būti labai svarbus dėl daugelio priežasčių – jei investicijos į automatizavimą atsipirks gaunamą pelną.
Kitas pavyzdys - „žmogiškojo faktoriaus“ pašalinimas nuo sistemos testavimo proceso. Tai svarbu, kai verslui labai svarbus operacijų tikslumas ir teisingumas. Tokios klaidos kaina gali būti žymiai didesnė už automatinio testo kūrimo ir priežiūros išlaidas.
Kodėl verta matuoti našumą?
Efektyvumo matavimas padeda atsakyti į klausimus: „Ar verta projekte įdiegti automatizavimą?“, „Kada diegimas duos reikšmingų rezultatų?“, „Kiek valandų rankinio testavimo pakeisime?“ ir kt.
Šie skaičiavimai gali padėti suformuluoti tikslus (arba metriką) testavimo automatizavimo komandai. Pavyzdžiui, sutaupoma X valandų per mėnesį atliekant rankinį testavimą, sumažinant testavimo komandos išlaidas Y įprastiniais vienetais.
Kiekvieną kartą, kai mums nepavyksta kitam leidimui, prasideda šurmulys. Iš karto atsiranda kalti, o neretai ir mes, bandytojai. Galbūt likimas lemta būti paskutine grandimi programinės įrangos gyvavimo cikle, todėl net jei kūrėjas daug laiko skiria kodo rašymui, niekas net nesusimąsto, kad testavimas yra ir tam tikras galimybes turintys žmonės.
Virš galvos šokinėti negalima, bet dirbti 10-12 valandų galima. Labai dažnai girdėjau tokias frazes)))
Kai testavimas neatitinka verslo poreikių, tada kyla klausimas, kam išvis testuoti, jei nespėja laiku dirbti. Niekas negalvoja, kas buvo anksčiau, kodėl nebuvo normaliai surašyti reikalavimai, kodėl neapgalvota architektūra, kodėl kreivas kodas. Bet kai turite terminą ir neturite laiko atlikti testo, jie iškart pradeda jus bausti ...
Tačiau tai buvo keli žodžiai apie sunkų testuotojo gyvenimą. Dabar prie reikalo 🙂
Po kelių tokių klastočių visi pradeda domėtis, kas negerai mūsų testavimo procese. Galbūt jūs, kaip vadovas, suprantate problemas, bet kaip jas perteikti vadovybei? Klausimas?
Vadovybei reikia skaičių, statistikos. Paprasti žodžiai – tavęs išklausė, papurtė galvas, pasakė – „Nagi, daryk“ ir viskas. Po to visi tikisi iš tavęs stebuklo, bet net jei ką nors padarei ir nepasisekė, tu arba tavo vadovas vėl gauna kepurę.
Bet kokius pokyčius turi palaikyti vadovybė, o kad vadovybė tai palaikytų, reikia skaičių, matavimų, statistikos.
Daug kartų mačiau, kaip jie bandė iškrauti įvairią statistiką iš užduočių sekimo priemonių, sakydami, kad „Išimame metriką iš JIRA“. Bet pažiūrėkime, kas yra metrika.
Metrika yra techniškai arba procedūriškai išmatuojamas dydis, apibūdinantis valdomo objekto būseną.
Pažiūrėkime – priėmimo testavimo metu mūsų komanda randa 50 defektų. ar tai daug? Arba šiek tiek? Ar šie 50 defektų pasako apie valdymo objekto būseną, ypač apie testavimo procesą?
Tikriausiai ne.
Ir jei jums būtų pasakyta, kad priimamojo patikrinimo metu nustatytų defektų skaičius yra 80%, o tai turėtų būti tik 60%. Manau iš karto aišku, kad defektų daug, atitinkamai, švelniai tariant, kūrėjų kodas pilnas g ... .. netenkina kokybe.
Kas nors gali pasakyti, kam tada reikia testuoti? Bet aš pasakysiu, kad defektai yra testavimo laikas, o testavimo laikas yra tai, kas tiesiogiai įtakoja mūsų terminą.
Todėl mums reikia ne tik metrikų, bet ir KPI.
KPI yra metrika, kuri tarnauja kaip valdymo objekto būsenos indikatorius. Būtina sąlyga yra tikslinės vertės ir nustatytų leistinų nuokrypių buvimas.
Tai yra, visada, kurdami metrikų sistemą, turite turėti tikslą ir priimtinus nukrypimus.
Pavyzdžiui, jums reikia (jūsų tikslo), kad 90% visų defektų būtų išspręsta nuo pirmos iteracijos. Tuo pačiu jūs suprantate, kad tai ne visada įmanoma, tačiau net jei pirmą kartą išspręstų defektų skaičius lygus 70%, tai taip pat yra gerai.
Tai reiškia, kad išsikėlėte sau tikslą ir paklaidos ribą. Dabar, jei suskaičiuosite išleidimo defektus ir gautumėte 86% vertę, tai tikrai nėra gerai, bet tai jau nėra gedimas.
Matematiškai tai atrodys taip:
Kodėl 2 formulės? Taip yra dėl to, kad egzistuoja metrikos iš apačios į viršų ir iš viršaus į apačią samprata, t.y. kai mūsų tikslinė vertė artėja prie 100 % arba 0 %.
Tie. jei mes kalbame, pavyzdžiui, apie defektų skaičių po įdiegimo pramoninėje operacijoje, tai kuo mažiau, tuo geriau, o jei kalbame apie funkcionalumo aprėptį bandomaisiais atvejais, tada viskas bus atvirkščiai.
Tuo pačiu metu nepamirškite, kaip apskaičiuoti tą ar kitą metriką.
Norėdami gauti reikiamus procentus, gabalus ir pan., turime apskaičiuoti kiekvieną metriką.
Iliustruojančiame pavyzdyje papasakosiu apie metriką „Defektų apdorojimo savalaikiškumas testuojant“.
Taikydami panašų metodą, kurį aprašiau aukščiau, taip pat sudarome metrikos KPI pagal tikslines vertes ir nuokrypius.
Neišsigąskite, gyvenime tai nėra taip sunku, kaip atrodo paveikslėlyje!
Ką mes turime?
Na, aišku, kad išleidimo numeris, incidento numeris….
Kritinis – šansai. 5,
Pagrindinis – šansai. 3,
Mažas – šansai. 1.5.
Tada turite nurodyti defekto apdorojimo laiko SLA. Norėdami tai padaryti, nustatomos tikslinės vertės ir maksimalus leistinas pakartotinio bandymo laikas taip pat, kaip aprašiau aukščiau skaičiuodamas metriką.
Norėdami atsakyti į šiuos klausimus, pereisime tiesiai prie našumo metrikos ir iškart užduosime klausimą. Ir kaip apskaičiuoti rodiklį, jei vienos užklausos reikšmė gali būti lygi nuliui. Jei vienas ar keli rodikliai yra lygūs nuliui, galutinis rodiklis labai stipriai sumažės, todėl kyla klausimas, kaip subalansuoti mūsų skaičiavimą, kad nulinės reikšmės, pavyzdžiui, užklausos, kurių sunkumo koeficientas yra "1", neturėtų didelės įtakos. mūsų galutinis įvertinimas.
Svoris- tai vertė, kurios mums reikia, kad užklausos turėtų mažiausią poveikį galutiniam įvertinimui su mažu sunkumo koeficientu, ir atvirkščiai, užklausa su didžiausiu sunkumo koeficientu turi reikšmingos įtakos pažymiui, jei mes pradelstas įvykdyti šį prašymą.
Kad skaičiavimuose nekiltų nesusipratimų, pateiksime konkrečius skaičiavimo kintamuosius:
x yra faktinis laikas, praleistas pakartotinai tikrinant defektą;
y – didžiausias leistinas nuokrypis;
z yra sunkio koeficientas.
Arba įprasta kalba, tai yra:
W = ESLI(x<=y,1,(x/y)^z)
Taigi, net jei viršytume savo nustatytą SLA sistemą, mūsų prašymas, atsižvelgiant į sunkumą, neturės rimtos įtakos mūsų pelnui.
Viskas yra taip, kaip aprašyta aukščiau:
X- faktinis laikas, praleistas pakartotinai tikrinant defektą;
y- didžiausias leistinas nuokrypis;
z Ar gravitacijos koeficientas.
h - planuojamas laikas pagal SLA
Nebežinau, kaip tai išreikšti matematine formule, todėl parašysiu programine kalba su operatoriumi JEI.
R = IF (x<=h;1;ЕСЛИ(x<=y;(1/z)/(x/y);0))
Dėl to gauname, kad jei pasiekėme tikslą, mūsų užklausos reikšmė yra 1, jei viršijome leistiną nuokrypį, tada įvertinimas lygus nuliui ir apskaičiuojami svoriai.
Jei mūsų vertė yra tarp tikslinio ir didžiausio leistino nuokrypio, tai priklausomai nuo gravitacijos koeficiento, mūsų vertė skiriasi diapazone.
Dabar pateiksiu keletą pavyzdžių, kaip tai atrodys mūsų metrikos sistemoje.
Kiekvienai užklausai, atsižvelgiant į jų svarbą (sunkumo koeficientą), yra atskiras SLA.
Ką mes čia matome.
Pirmoje užklausoje nuo tikslinės vertės nukrypome tik valanda ir jau turime 30 proc. reitingą, o antroje užklausoje taip pat nukrypome tik viena valanda, tačiau rodiklių suma jau nebe 30 proc. 42,86%. Tai yra, sunkumo veiksniai vaidina svarbų vaidmenį formuojant galutinį užklausos rodiklį.
Tuo pačiu trečiuoju prašymu pažeidėme maksimalų leistiną laiką ir įvertinimas lygus nuliui, tačiau pasikeitė užklausos svoris, kas leidžia teisingiau apskaičiuoti šio prašymo įtaką galutiniam koeficientui.
Na, o norėdami tuo įsitikinti, galite tiesiog paskaičiuoti, kad rodiklių aritmetinis vidurkis bus 43,21%, o mes gavome 33,49%, o tai rodo rimtą didelės svarbos užklausų poveikį.
Pakeiskime reikšmes sistemoje 1 val.
tuo pačiu metu 5-ajam prioritetui reikšmė pasikeitė 6 proc., o trečiajam – 5,36 proc.
Vėlgi, užklausos svarba turi įtakos jos metrikai.
Tai viskas, mes gauname galutinę metriką.
Kas svarbu!
Nesakau, kad metrinės sistemos naudojimas turėtų būti atliekamas pagal analogiją su mano vertybėmis, tik siūlau požiūrį į jų išlaikymą ir rinkimą.
Vienoje organizacijoje mačiau, kad jie sukūrė savo sistemą, skirtą metrikos rinkimui iš HP ALM ir JIRA. Tai tikrai šaunu. Tačiau svarbu atsiminti, kad tokiam metrikų palaikymo procesui reikia rimtai laikytis reguliavimo procesų.
Na, o svarbiausia, tik jūs galite nuspręsti, kaip ir kokius rodiklius rinkti. Nereikia kopijuoti tų metrikų, kurių negalite rinkti.
Metodas yra sudėtingas, bet galingas.
Išbandykite ir jums taip pat gali pasisekti!
Aleksandras Meškovas, „Performance Lab“ operacijų vadovas, turi daugiau nei 5 metų patirtį programinės įrangos testavimo, testų valdymo ir kokybės užtikrinimo konsultacijų srityse. ISTQB, TPI, TMMI ekspertas.
Veiksmingumo vertinimo, kurį kai kas jau vadino „nelaimės formule“, tikslas – pradžiuginti testuotoją, kad būtų galima skaičiais parodyti, kad vienas veikia gerai ir reikia paglostyti galvą, o kitas – blogas ir reikia plakti... pagal šį kriterijų jis negali būti vienintelis, todėl vertintinas kartu su kitais rodikliais, tokiais kaip plano vykdymas, testų automatizavimas ir pan.
Testuotojo, kaip ir bet kurio kito darbuotojo, darbas turi būti kiekybiškai įvertintas, t.y. išmatuojamame rodiklyje. Bet kokius rodiklius turėtumėte pasirinkti?
Pirmas dalykas, kuris ateina į galvą, yra rastų defektų skaičius. Ir būtent šį rodiklį iš karto pabandžiau įvesti į Inreko LAN. Tačiau iš karto kilo karšta diskusija, kuri ir paskatino paanalizuoti šį kriterijų. Šia tema noriu paspėlioti šiame straipsnyje.
Rastų defektų skaičius yra itin slidus rodiklis. Visi interneto šaltiniai, kuriuose aptariama ši problema, taip pat kartoja tą patį (http://www.software-testing.ru/, blogs.msdn.com/imtesty, it4business.ru, sqadotby.blogspot.com, tinklaraščiai. msdn.com / larryosterman, sql.ru, http://www.testingperspective.com/ ir daugelis kitų). Išanalizavęs savo patirtį ir šiuos išteklius priėjau prie tokio problemų medžio:
Pirma, yra skirtumas tarp defekto ir defekto. Vienas testuotojas gali ieškoti programoje esančių mygtukų išdėstymo defektų, kitas – įsigilinti į logiką ir sugalvoti sudėtingas testavimo situacijas. Daugeliu atvejų pirmasis testuotojas ras daugiau defektų, nes net ir testo paruošimas jam užtruks daug mažiau laiko, tačiau tokių defektų vertė yra daug mažesnė. Ši problema lengvai išspręsta įvedant defekto kritiškumą. Jį galima įvertinti pagal kiekvienoje kategorijoje rastų defektų skaičių. Pavyzdžiui, turime 4 iš jų: kritinį, reikšmingą, vidutinį ir nereikšmingą. Bet kadangi kritiškumo apibrėžimo riba nėra iki galo aiški, nors ir turime formalių kritiškumo požymių, galime eiti dviem patikimesniais keliais. Pirma, tam tikra pasirinktam laikotarpiui nustatytų defektų dalis neturėtų būti mažos kritinės reikšmės defektai. Antrasis – nekreipti dėmesio į nedidelius vertinimo trūkumus. Taigi mes kovojame su testuotojo noru surinkti kuo daugiau defektų aprašydami smulkius trūkumus, verčiant jį (ar dažniau ją) pasigilinti ir rasti rimtų defektų. Ir jie visada yra šalia, patikėkite mano patirtimi. Pasirinkau antrą variantą – smulkius defektus išmesti.
Antroji tokio kriterijaus „slidumo“ priežastis – pakankamas sistemos defektų skaičius, kad testeris galėtų juos rasti. Čia yra trys veiksniai. Pirmasis yra sistemos logikos ir technologijos sudėtingumas. Antrasis yra kodavimo kokybė. Ir trečia – projekto etapas. Panagrinėkime šiuos tris veiksnius eilės tvarka. Logikos ir technologijos, kuria remiantis sukurta sistema, sudėtingumas turi įtakos galimiems trūkumams, kuriuos galima padaryti. Be to, priklausomybė čia toli gražu nėra tiesioginė. Jei įdiegsite paprastą logiką sudėtingoje ar nepažįstamoje platformoje, klaidos daugiausia bus susijusios su netinkamu diegimo technologijos naudojimu. Jei primityvioje platformoje įdiegsite sudėtingą logiką, greičiausiai klaidos bus susijusios ir su pačia logika, ir su tokios logikos įgyvendinimo primityviąja kalba sudėtingumu. Tai yra, renkantis sistemos diegimo technologiją reikia pusiausvyros. Tačiau dažnai technologijas diktuoja klientas ar rinka, todėl vargu ar galime daryti įtaką. Taigi belieka tik atsižvelgti į šį veiksnį kaip į tam tikrą galimo defektų skaičiaus koeficientą. Be to, šio koeficiento reikšmę greičiausiai turi nustatyti ekspertai.
Kodavimo kokybė. Čia tikrai negalime niekaip paveikti kūrėjo. Bet mes galime: a) dar kartą ekspertiškai įvertinti kūrėjo lygį ir įtraukti jį kaip kitą veiksnį ir b) bandyti užkirsti kelią kodo klaidoms per vienetų testus, todėl 100% kodo aprėptis vienetiniais testais yra privalomas reikalavimas.
Projekto etapas. Seniai žinoma, kad visų defektų rasti neįmanoma, nebent dėl nereikšmingos programos ar atsitiktinai, nes tobulumui ribų nėra, o bet koks nesutapimas su tobulumu gali būti laikomas defektu. Tačiau vienas dalykas, kai projektas yra aktyvioje kūrimo stadijoje, ir visai kas kita, kai jis yra paramos etape. Ir jei dar atsižvelgsime į sistemos sudėtingumo ir technologijos bei kodavimo kokybės veiksnius, tai aišku, kad visa tai radikaliai įtakoja defektų, kuriuos gali rasti testeris, skaičių. Artėjant projekto pabaigai arba palaikymo fazei (dabar visa tai vadiname sąlyginai ir apibrėžiame intuityviai), sistemos defektų skaičius mažėja, taigi ir randamų defektų skaičius. Ir čia reikia nustatyti momentą, kada tampa neprotinga reikalauti iš testerio surasti tam tikrą skaičių defektų. Norint nustatyti tokį momentą, būtų malonu žinoti, kokią dalį iš viso defektų galime rasti ir kiek sistemoje dar liko defektų. Tai atskiros diskusijos tema, tačiau galima pritaikyti gana paprastą ir efektyvų statistinį metodą.
Remiantis ankstesnių projektų statistika, su tam tikra paklaida galima suprasti, kiek sistemoje buvo defektų ir kiek jų rado testavimo komanda skirtingais projekto laikotarpiais. Taigi galite gauti tam tikrą vidutinį statistinį testavimo komandos efektyvumo rodiklį. Jis gali būti išskaidytas kiekvienam atskiram testuotojui ir gauti asmeninį įvertinimą. Kuo daugiau patirties ir statistikos, tuo mažesnė bus klaida. Taip pat galite naudoti „klaidų sėjimo“ metodą, kai tiksliai žinome, kiek klaidų yra sistemoje. Žinoma, reikia atsižvelgti į papildomus veiksnius, tokius kaip sistemos tipas, logikos sudėtingumas, platforma ir kt. Taigi, gauname ryšį tarp projekto etapo ir rastų defektų procento. Dabar šią priklausomybę galime pritaikyti priešinga kryptimi: žinodami rastų defektų skaičių ir esamą projekto fazę, galime nustatyti bendrą mūsų sistemos defektų skaičių (žinoma, su tam tikra paklaida). Tada pagal asmeninio ar bendro vertinimo rodiklius galima nustatyti, kiek defektų bandytojas ar komanda gali rasti per likusį laikotarpį. Remiantis šiuo vertinimu, jau galima apibrėžti testuotojo darbo efektyvumo kriterijų.
Testerio našumo metrikos funkcija gali atrodyti taip:
Defektai- rastų defektų skaičius,
Sunkumas- nustatytų defektų kritiškumas,
Sudėtingumas- sistemos logikos sudėtingumas,
Platforma- sistemos diegimo platforma,
Fazė- projekto etapas,
Laikotarpis- nagrinėjamas laikotarpis.
Bet jau konkretus kriterijus, kurį turi atitikti testuotojas, turi būti parinktas empiriškai ir atsižvelgiant į konkrečios organizacijos specifiką.
Šiuo metu dar neįmanoma atsižvelgti į visus veiksnius, tačiau kartu su pagrindiniu kūrėju Ivanu Astafjevu ir projekto vadove Irina Lager, atsižvelgdami į defektų skaičių ir jų kritiškumą, priėjome prie tokios formulės:
, kur
E- efektyvumas, nustatomas pagal nustatytų defektų skaičių,
D Klientas- užsakovo nustatytų defektų, kuriuos turėjo rasti vertinamas testuotojas, skaičius,
D testeris- testerio nustatytų defektų skaičius,
k ir d- viso defektų skaičiaus pataisos koeficientai.
Iš karto noriu pastebėti, kad vertinant pagal šią formulę reikia atsižvelgti tik į tuos defektus, kurie priklauso vertinamo testuotojo atsakomybės sričiai. Jei keli bandytojai dalijasi atsakomybe už praleistą defektą, į šį defektą reikia atsižvelgti vertinant kiekvieną bandytoją. Be to, skaičiuojant neatsižvelgiama į žemos kritinės reikšmės defektus.
Taigi turime trečiojo laipsnio parabolę, kuri atspindi defektų radimo intensyvumo kriterijų, kurio turi atitikti testeris. Apskritai, jei testuotojo įvertinimas yra aukščiau parabolės, tai reiškia, kad jis veikia geriau nei tikėtasi, jei žemesnis, tai atitinkamai blogesnis.
Čia yra niuansas, susijęs su bendru analizuojamų defektų skaičiumi. Natūralu, kad kuo daugiau statistikos, tuo geriau, tačiau kartais reikia išanalizuoti skirtingus projekto etapus, kartais tereikia sąmatos kiekvienam laikotarpiui. Vienas dalykas, kai per laikotarpį buvo nustatyti 4 defektai ir 2 iš jų buvo nustatyti užsakovo, ir visai kas kita, kai buvo nustatyta 100 defektų, iš kurių 50 buvo nustatyti užsakovo. Abiem atvejais užsakovo ir testuotojo rastų defektų skaičiaus santykis pasirodys 0,5, tačiau suprantame, kad pirmuoju atveju ne viskas taip blogai, o antruoju jau laikas nuskambėti. signalizacija.
Be didelio pasisekimo, bandydami sukurti griežtą matematinį ryšį su bendru defektų skaičiumi, prie šios formulės, tos pačios Irinos Lager žodžiais tariant, prikabinome „ramentus“ intervalų pavidalu, kurių kiekvienam nustatėme savo. koeficientai. Buvo trys intervalai: statistikai nuo 1 iki 20 defektų, nuo 21 iki 60 defektų ir daugiau nei 60 defektų statistikai.
|
Defektų skaičius |
k |
d |
Apskaičiuota leistina užsakovo nustatytų defektų dalis nuo bendro nustatytų defektų skaičiaus |
Paskutinis lentelės stulpelis buvo įvestas siekiant paaiškinti, kiek defektų klientas gali rasti pateiktame pavyzdyje. Atitinkamai, kuo mažesnė imtis, tuo didesnė gali būti klaida ir tuo daugiau defektų gali rasti klientas. Funkcijos požiūriu tai reiškia ribinę minimalią kliento ir testuotojo rastų defektų skaičiaus santykio reikšmę, po kurios efektyvumas tampa neigiamas, arba tašką, kuriame grafikas kerta X ašį. kuo mažesnė imtis, tuo labiau į dešinę turi būti sankirta su ašimi. Kalbant apie valdymą, tai reiškia, kad kuo mažesnė imtis, tuo toks įvertinimas yra netikslesnis, todėl vadovaujamės principu, kad bandytojai turėtų būti ne taip griežtai vertinami mažesnėje imtyje.
Turime tokios formos grafikus:
Juodas grafikas atspindi daugiau nei 60 defektų mėginio kriterijų, geltona - 21-60 defektų, žalia - mažiau nei 20 defektų. Matyti, kad kuo didesnė imtis, tuo labiau į kairę grafikas kerta X ašį.Kaip jau minėta, vertintojui tai reiškia, kad kuo didesnė imtis, tuo labiau galima pasitikėti šiuo skaičiumi.
Vertinimo metodas susideda iš testerio veiklos apskaičiavimo pagal (2) formulę, atsižvelgiant į pataisos koeficientus ir šio įvertinimo palyginimą su reikiama verte grafike. Jei balas didesnis už grafiką, testeris pateisina lūkesčius, jei mažesnis – testeris dirba žemiau reikalaujamos „juostelės“. Taip pat noriu pastebėti, kad visi šie skaičiai buvo parinkti empiriškai ir kiekvienai organizacijai bėgant laikui juos galima keisti ir koreguoti tiksliau. Todėl laukiami bet kokie komentarai (čia arba mano asmeniniame tinklaraštyje) ir patobulinimai.
Šis testavimo komandos ir kliento / vartotojo / kliento nustatytų defektų skaičiaus santykio vertinimo metodas man atrodo pagrįstas ir daugiau ar mažiau objektyvus. Tiesa, toks vertinimas gali būti atliktas tik baigus projektą arba bent jau esant aktyviems išoriniams sistemos naudotojams. Bet ką daryti, jei produktas dar nenaudojamas? Kaip tokiu atveju vertinti testuotojo darbą?
Be to, tokia testerio efektyvumo vertinimo technika sukuria keletą papildomų problemų:
1. Vienas defektas pradeda dalytis į keletą mažesnių.
· Testavimo vadovas, pastebėjęs tokią situaciją, turėtų ją nuslopinti neformaliais metodais.
2. Defektų valdymas tampa sunkesnis dėl didėjančio pasikartojančių įrašų skaičiaus.
· Šią problemą gali padėti išspręsti klaidų sekimo sistemos defektų nustatymo taisyklės, kurios numato privalomą panašių defektų peržiūrą.
3. Rastų defektų kokybinio įvertinimo stoka, nes vienintelis testerio tikslas yra defektų skaičius, o dėl to testuotojo motyvacijos stoka ieškoti „kokybinių“ defektų. Visgi defekto kritiškumas ir „kokybė“ negali būti tapatinami, pastaroji yra mažiau formalizuota sąvoka.
· Čia lemiamą vaidmenį turėtų suvaidinti tiek testuotojo, tiek vadovo „požiūris“. Tik bendras teisingas (!) Tokio kiekybinio vertinimo prasmės supratimas gali išspręsti šią problemą.
Apibendrinant visa tai, kas išdėstyta aukščiau, prieiname prie išvados, kad testuotojo darbą vertinti tik pagal rastų defektų skaičių ne tik sunku, bet ir ne visai teisinga. Todėl rastų defektų skaičius turėtų būti tik vienas iš testuotojo darbo integralaus vertinimo rodiklių ir ne gryna forma, o atsižvelgiant į mano išvardintus veiksnius.
