Vitet e fundit, testimi i automatizuar është bërë një trend në fushën e zhvillimit të softuerit, në një farë kuptimi, zbatimi i tij është bërë një "ushqim i modës". Sidoqoftë, zbatimi dhe mbështetja e testeve të automatizuara është një procedurë shumë intensive e burimeve dhe, rrjedhimisht, e shtrenjtë. Përdorimi i gjerë i këtij mjeti më së shpeshti çon në humbje të konsiderueshme financiare pa ndonjë rezultat të rëndësishëm.
Si mund të përdorni një mjet mjaft të thjeshtë për të vlerësuar efektivitetin e mundshëm të përdorimit të autotesteve në një projekt?
Çfarë përcaktohet si "efikasiteti" i automatizimit të testit?
Mënyra më e zakonshme për të vlerësuar efikasitetin (kryesisht ekonomike) është llogaritja e kthimit të investimit(ROI). Ai llogaritet mjaft thjesht, duke qenë raporti i fitimit me kostot. Sapo vlera e ROI kalon një, zgjidhja kthen fondet e investuara në të dhe fillon të sjellë të reja.
Në rastin e automatizimit, do të thotë fitim kursime në testimin manual. Për më tepër, fitimi në këtë rast mund të mos jetë i dukshëm - për shembull, rezultatet e gjetjes së defekteve në procesin e testimit ad-hoc nga inxhinierët, koha e të cilëve u lirua për shkak të automatizimit. Një fitim i tillë është mjaft i vështirë për t'u llogaritur, kështu që ju ose mund të bëni një supozim (për shembull, + 10%) ose ta hiqni atë.
Megjithatë, kursimi nuk është gjithmonë qëllimi i zbatimit të automatizimit. Një shembull është shpejtësia e ekzekutimit të testit(si për nga shpejtësia e kryerjes së një testi, ashtu edhe për nga frekuenca e testimit). Për një sërë arsyesh, shpejtësia e testimit mund të jetë kritike për një biznes - nëse investimet në automatizim shpërblehen me fitimin e marrë.
Një shembull tjetër - përjashtimi i "faktorit njerëzor" nga procesi i testimit të sistemit. Kjo është e rëndësishme kur saktësia dhe korrektësia e ekzekutimit të operacioneve është kritike për biznesin. Çmimi i një gabimi të tillë mund të jetë shumë më i lartë se kostoja e zhvillimit dhe mbajtjes së një autotesti.
Pse të matni performancën?
Matja e efikasitetit ndihmon për t'iu përgjigjur pyetjeve: "A ia vlen të zbatohet automatizimi në një projekt?", "Kur do të na sjellë një rezultat domethënës zbatimi?", "Sa orë testim manual do të zëvendësojmë?", "A është e mundur të zëvendësoni 3 inxhinierë testimi manual me 1 inxhinier testimi të automatizuar? dhe etj.
Këto llogaritje mund të ndihmojnë në formulimin e qëllimeve (ose metrikave) për ekipin e automatizuar të testimit. Për shembull, duke kursyer X orë në muaj të testimit manual, duke ulur koston e ekipit të testimit me njësi Y.
Sa herë që dështojmë në një tjetër publikim, bëhet bujë. Njerëzit fajtorë shfaqen menjëherë, dhe shpesh jemi ne, testuesit. Ndoshta është fati të jetë lidhja e fundit në ciklin jetësor të softuerit, kështu që edhe nëse një zhvillues shpenzon shumë kohë duke shkruar kodin, askush nuk mendon se testimi janë gjithashtu njerëz me aftësi të caktuara.
Ju nuk mund të hidheni mbi kokën tuaj, por mund të punoni 10-12 orë në ditë. Kam dëgjuar fraza të tilla shumë shpesh)))
Kur testimi nuk i plotëson nevojat e biznesit, atëherë lind pyetja, pse të testohen fare nëse nuk kanë kohë të punojnë në kohë. Askush nuk mendon se çfarë ka ndodhur më parë, pse kërkesat nuk janë shkruar siç duhet, pse nuk është menduar arkitektura, pse kodi ka qenë i shtrembër. Por kur keni një afat dhe nuk keni kohë për të përfunduar testimin, atëherë ata menjëherë fillojnë t'ju ndëshkojnë ...
Por ishin disa fjalë për jetën e vështirë të një testuesi. Tani tek pika 🙂
Pas disa falsifikimeve të tilla, të gjithë fillojnë të pyesin se çfarë nuk shkon në procesin tonë të testimit. Ndoshta ju si drejtues i kuptoni problemet, por si ia kaloni menaxhmentit? Pyetje?
Menaxhmenti ka nevojë për numra, statistika. Fjalë të thjeshta - të dëgjuan, tundën kokën, thanë - "Hajde bëje" dhe kaq. Pas kësaj, të gjithë presin një mrekulli nga ju, por edhe nëse keni bërë diçka dhe nuk ju ka dalë, ju ose udhëheqësi juaj do të merrni përsëri një kapelë.
Çdo ndryshim duhet të mbështetet nga menaxhmenti dhe që menaxhmenti ta mbështesë duhet shifra, matje, statistika.
Shumë herë kam parë se si ata u përpoqën të ngarkonin statistika të ndryshme nga gjurmuesit e detyrave, duke thënë se "Ne heqim matjet nga JIRA". Por le të kuptojmë se çfarë është një metrikë.
Një metrikë është një vlerë e matshme teknikisht ose procedurale që karakterizon gjendjen e objektit të kontrollit.
Le të shohim - ekipi ynë gjen 50 defekte gjatë testimit të pranimit. Është shumë? Apo pak? A ju tregojnë këto 50 defekte për gjendjen e objektit të kontrollit, në veçanti për procesin e testimit?
Me siguri jo.
Dhe nëse ju është thënë se numri i defekteve të gjetura gjatë testimit të pranimit është 80%, ndërsa duhet të jetë vetëm 60%. Unë mendoj se është menjëherë e qartë se ka shumë defekte, përkatësisht, për ta thënë butë, kodi i zhvilluesve është plotësisht i g ... .. i pakënaqshëm për sa i përket cilësisë.
Dikush mund të thotë se pse atëherë testimi? Por unë do të them se defektet janë kohë testimi, dhe koha e testimit është ajo që ndikon drejtpërdrejt në afatin tonë.
Prandaj, ne nuk kemi nevojë vetëm për metrikë, ne kemi nevojë për KPI.
KPI është një metrikë që shërben si tregues i gjendjes së objektit të kontrollit. Një parakusht është prania e një vlere të synuar dhe tolerancave të vendosura.
Kjo do të thotë, gjithmonë, kur ndërtoni një sistem metrikë, duhet të keni një qëllim dhe devijime të lejueshme.
Për shembull, ju duhet (qëllimi juaj) që 90% e të gjitha defekteve të zgjidhen që në përsëritjen e parë. Në të njëjtën kohë, ju e kuptoni që kjo nuk është gjithmonë e mundur, por edhe nëse numri i defekteve të zgjidhura herën e parë është 70%, kjo është gjithashtu e mirë.
Kjo do të thotë, ju i vendosni vetes një qëllim dhe një devijim të pranueshëm. Tani, nëse numëroni defektet në lëshim dhe merrni një vlerë prej 86%, atëherë kjo sigurisht nuk është mirë, por nuk është më një dështim.
Matematikisht do të duket kështu:
Pse 2 formula? Kjo për faktin se ekziston një koncept i metrikës ngjitëse dhe zbritëse, d.m.th. kur vlera jonë e synuar i afrohet 100% ose 0%.
Ato. nëse po flasim, për shembull, për numrin e defekteve të gjetura pas zbatimit në funksionimin tregtar, atëherë sa më pak, aq më mirë, dhe nëse po flasim për mbulimin e funksionalitetit me raste testimi, atëherë gjithçka do të jetë anasjelltas.
Në të njëjtën kohë, mos harroni se si të llogaritni këtë apo atë metrikë.
Për të marrë përqindjet, copat etj. që na duhen, duhet të llogarisim çdo metrikë.
Për një shembull ilustrues, unë do t'ju tregoj për metrikën "Kohëzgjatja e përpunimit të defekteve me anë të testimit".
Duke përdorur një qasje të ngjashme, të cilën e përshkrova më lart, ne gjithashtu formojmë një KPI për metrikën bazuar në vlerat dhe devijimet e synuara.
Mos u shqetësoni, nuk është aq e vështirë në jetën reale sa duket në foto!
Çfarë kemi ne?
Epo, është e qartë se numri i lëshimit, numri i incidentit ....
Kritike - shanse. 5,
Major - shanse. 3,
Minor - shanse. 1.5.
Më pas, duhet të specifikoni SLA për kohën e përpunimit të defektit. Për ta bërë këtë, përcaktohen vlera e synuar dhe koha maksimale e lejuar e ritestimit, e ngjashme me mënyrën se si e përshkrova më lart për llogaritjen e metrikës.
Për t'iu përgjigjur këtyre pyetjeve, ne do të kalojmë drejtpërdrejt te metrika e performancës dhe do ta bëjmë pyetjen menjëherë. Dhe si të llogaritet treguesi nëse vlera e një kërkese mund të jetë e barabartë me "zero". Nëse një ose më shumë tregues është i barabartë me zero, atëherë treguesi përfundimtar do të ulet shumë, kështu që lind pyetja se si të balancojmë llogaritjen tonë në mënyrë që vlerat zero, për shembull, të kërkesave me një faktor ashpërsie "1" të mos ndikojnë shumë. vlerësimin tonë përfundimtar.
Peshaështë vlera që na nevojitet për të pasur ndikim sa më të vogël të kërkesave në notën përfundimtare me ashpërsi të ulët dhe anasjelltas, një kërkesë me ashpërsinë më të madhe ka një ndikim të madh në notë, me kusht që të jemi të vonuar për këtë kërkesë.
Në mënyrë që të mos keni keqkuptime në llogaritjet, ne do të prezantojmë variabla specifike për llogaritjen:
x është koha aktuale e shpenzuar për ritestimin e defektit;
y është devijimi maksimal i lejuar;
z është faktori i gravitetit.
Ose në gjuhën e përbashkët, kjo është:
W=ESLI(x<=y,1,(x/y)^z)
Kështu, edhe nëse kemi shkuar përtej kufijve të SLA që kemi vendosur, kërkesa jonë, në varësi të ashpërsisë, nuk do të ndikojë seriozisht në rezultatin tonë përfundimtar.
Të gjitha siç përshkruhen më sipër:
X– koha aktuale e shpenzuar për ritestimin e defektit;
y– devijimi maksimal i lejuar;
zështë faktori i gravitetit.
h- koha e planifikuar sipas SLA
Unë nuk di më si ta shpreh këtë në një formulë matematikore, kështu që do të shkruaj në një gjuhë programimi me operatorin NËSE.
R = IF (x<=h;1;ЕСЛИ(x<=y;(1/z)/(x/y);0))
Si rezultat, marrim që nëse e kemi arritur qëllimin, atëherë vlera e kërkesës tonë është e barabartë me 1, nëse shkuam përtej devijimit të lejuar, atëherë vlerësimi është i barabartë me zero dhe llogariten peshat.
Nëse vlera jonë është midis objektivit dhe devijimit maksimal të lejueshëm, atëherë në varësi të faktorit të ashpërsisë, vlera jonë ndryshon në intervalin .
Tani do të jap disa shembuj se si do të duket në sistemin tonë metrikë.
Çdo kërkesë ka SLA-në e vet në varësi të rëndësisë së tyre (faktori i ashpërsisë).
Çfarë shohim këtu.
Në kërkesën e parë ne kemi devijuar vetëm një orë nga vlera e synuar dhe tashmë kemi një vlerësim prej 30%, ndërsa në kërkesën e dytë kemi devijuar vetëm me një orë, por shuma e treguesve nuk është më 30%, por 42.86%. Kjo do të thotë, koeficientët e ashpërsisë luajnë një rol të rëndësishëm në formimin e treguesit përfundimtar të pyetjes.
Në të njëjtën kohë, në kërkesën e tretë kemi shkelur kohën maksimale të lejueshme dhe vlerësimi është i barabartë me zero, por pesha e kërkesës ka ndryshuar, gjë që na lejon të llogarisim më saktë ndikimin e kësaj kërkese në koeficientin përfundimtar.
Epo, për t'u siguruar për këtë, thjesht mund të llogaritni se mesatarja aritmetike e treguesve do të jetë e barabartë me 43.21%, dhe ne morëm 33.49%, që tregon një ndikim serioz të pyetjeve me rëndësi të madhe.
Le të ndryshojmë vlerat në sistem në 1 orë.
në të njëjtën kohë, për prioritetin e 5-të, vlera ndryshoi me 6%, dhe për të tretën - me 5.36%.
Përsëri, rëndësia e një pyetjeje ndikon në rezultatin e tij.
Kjo është ajo, ne marrim treguesin përfundimtar të metrikës.
Çfarë është e rëndësishme!
Nuk po them që përdorimi i sistemit metrikë duhet të bëhet në analogji me vlerat e mia, thjesht po sugjeroj një qasje për ruajtjen dhe mbledhjen e tyre.
Në një organizatë, pashë që ata zhvilluan kornizën e tyre për mbledhjen e metrikave nga HP ALM dhe JIRA. Është vërtet e lezetshme. Por është e rëndësishme të mbani mend se një proces i tillë i mbajtjes së metrikës kërkon respektim serioz të proceseve rregullatore.
Epo, dhe më e rëndësishmja, vetëm ju mund të vendosni se si dhe çfarë metrike të mbledhni. Nuk keni nevojë të kopjoni ato metrika që nuk mund t'i grumbulloni.
Qasja është komplekse, por efektive.
Provojeni dhe ndoshta edhe ju mundeni!
Alexander Meshkov, Shef Operacional në Laboratorin e Performancës, ka mbi 5 vjet përvojë në testimin e softuerit, menaxhimin e testeve dhe konsulencën për sigurimin e cilësisë. Ekspert ISTQB, TPI, TMMI.
Qëllimi i vlerësimit të performancës, të cilin disa e kanë quajtur tashmë "formula e pakënaqësisë" është thjesht të bëjë testuesin të lumtur, në mënyrë që të mund të tregosh me numra se njëri funksionon mirë dhe duhet të përkëdhelet në kokë për të, dhe tjetri është i keq. dhe duhet rrahur ... Vlerësimi vetëm sipas këtij kriteri nuk mund të jetë i vetmi, prandaj duhet të merret parasysh në lidhje me treguesit e tjerë, si zbatimi i planit, automatizimi i testit etj.
Performanca e një testuesi, si çdo punonjës tjetër, duhet të kuantifikohet, d.m.th. në një tregues të matshëm. Por cilët tregues të zgjidhni?
Gjëja e parë që ju vjen në mendje është numri i defekteve të gjetura. Dhe ishte ky tregues që menjëherë u përpoqa ta futja në Inreco LAN. Megjithatë, menjëherë lindi një diskutim i nxehtë, i cili më shtyu të analizoja këtë kriter. Për këtë temë, unë dua të diskutoj në këtë artikull.
Numri i defekteve të gjetura është një tregues jashtëzakonisht i rrëshqitshëm. Të gjitha burimet në rrjet që diskutojnë këtë problem e përsërisin gjithashtu këtë (http://www.software-testing.ru/, blogs.msdn.com/imtesty, it4business.ru, sqadotby.blogspot.com, blogs.msdn.com / larryosterman, sql.ru, http://www.testingperspective.com/ dhe shumë e shumë të tjerë). Pasi analizova përvojën time dhe këto burime, arrita te pema e mëposhtme e problemeve:
Së pari, defekt në defekt - mosmarrëveshje. Një testues mund të kërkojë defekte në vendndodhjen e butonave në një aplikacion, një tjetër mund të thellohet në logjikë dhe të dalë me situata komplekse testimi. Në shumicën e rasteve, testuesi i parë do të gjejë më shumë defekte, sepse edhe përgatitja e testit do t'i marrë shumë më pak kohë, por vlera e defekteve të tilla është shumë më e ulët. Ky problem zgjidhet lehtësisht duke futur kritikitetin e defektit. Mund të vlerësohet nga numri i defekteve të gjetura në secilën prej kategorive. Për shembull, kemi 4 prej tyre: kritike, domethënëse, mesatare dhe të parëndësishme. Por duke qenë se përkufizimi i kritikitetit nuk është plotësisht i qartë, megjithëse kemi shenja formale kritike, mund të shkojmë në dy mënyra më të besueshme. E para është që një pjesë e caktuar e defekteve të gjetura gjatë periudhës së përzgjedhur duhet të jenë defekte jo kritike. E dyta është të mos merren parasysh defekte të vogla në vlerësim. Kështu, ne luftojmë kundër dëshirës së testuesit për të shënuar sa më shumë defekte në kurriz të përshkrimit të të metave të vogla, duke e detyruar atë (ose më shpesh atë) të gërmojë më thellë dhe të gjejë defekte serioze. Dhe ata janë gjithmonë, besoni përvojën time. Zgjodha opsionin e dytë - hidhni defekte të vogla.
Arsyeja e dytë për "rrëshqitjen" e një kriteri të tillë është prania e një numri të mjaftueshëm defektesh në sistem në mënyrë që testuesi t'i gjejë ato. Këtu janë tre faktorë. E para është kompleksiteti i logjikës dhe teknologjisë së sistemit. E dyta është cilësia e kodimit. Dhe e treta është faza e projektit. Le t'i marrim me radhë këta tre faktorë. Kompleksiteti i logjikës dhe teknologjisë mbi të cilën është shkruar sistemi ndikon në të metat e mundshme që mund të bëhen. Për më tepër, varësia këtu nuk është e drejtpërdrejtë. Nëse zbatoni logjikë të thjeshtë në një platformë komplekse ose të panjohur, atëherë gabimet do të lidhen kryesisht me përdorimin e gabuar të teknologjisë së zbatimit. Nëse zbatoni logjikë komplekse në një platformë primitive, atëherë, ka shumë të ngjarë, gabimet do të shoqërohen si me vetë logjikën ashtu edhe me kompleksitetin e zbatimit të një logjike të tillë në një gjuhë primitive. Kjo është, një ekuilibër është i nevojshëm kur zgjedh një teknologji për zbatimin e sistemit. Por shpeshherë teknologjia diktohet nga klienti apo tregu, ndaj vështirë se mund të ndikojmë. Prandaj, mbetet vetëm të merret parasysh ky faktor si një koeficient i caktuar i numrit të mundshëm të defekteve. Për më tepër, vlera e këtij koeficienti, ka shumë të ngjarë, duhet të përcaktohet nga një ekspert.
Cilësia e kodimit. Këtu definitivisht nuk mund të ndikojmë në asnjë mënyrë te zhvilluesi. Por ne mund: a) përsëri, të vlerësojmë me ekspertizë nivelin e zhvilluesit dhe ta përfshijmë atë si një faktor tjetër, dhe b) të përpiqemi të parandalojmë shfaqjen e gabimeve në kod përmes testeve të njësisë, duke e bërë mbulimin 100% të kodit me testet e njësisë një kërkesë të detyrueshme .
Faza e projektit. Dihet prej kohësh se është e pamundur të gjenden të gjitha defektet, përveç ndoshta një programi të parëndësishëm ose rastësisht, pasi nuk ka kufi për përsosmërinë dhe çdo mospërputhje me përsosmërinë mund të konsiderohet defekt. Por është një gjë kur një projekt është në fazën aktive të zhvillimit, dhe krejt tjetër kur është në fazën e mbështetjes. Dhe nëse marrim parasysh edhe faktorët e kompleksitetit të sistemit dhe teknologjisë dhe cilësisë së kodimit, është e qartë se e gjithë kjo ndikon rrënjësisht në numrin e defekteve që një testues është në gjendje të gjejë. Ndërsa projekti i afrohet përfundimit ose fazës së mbështetjes (ne i quajmë të gjitha me kusht dhe e përcaktojmë në mënyrë intuitive tani), numri i defekteve në sistem zvogëlohet, dhe si rrjedhim edhe numri i defekteve të gjetura. Dhe këtu është e nevojshme të përcaktohet momenti kur bëhet e paarsyeshme të kërkohet nga testuesi të gjejë një numër të caktuar defektesh. Për të përcaktuar një moment të tillë, do të ishte mirë të dinim se çfarë pjesë të numrit të përgjithshëm të defekteve mund të gjejmë dhe sa defekte kanë mbetur ende në sistem. Kjo është një temë për një diskutim më vete, por mund të zbatohet një metodë statistikore mjaft e thjeshtë dhe efektive.
Bazuar në statistikat e projekteve të mëparshme, është e mundur të kuptohet, me një gabim të caktuar, sa defekte kishte në sistem dhe sa u konstatuan nga ekipi i testimit në periudha të ndryshme të projektit. Kështu, ju mund të merrni një tregues mesatar të caktuar të efektivitetit të ekipit të testimit. Mund të dekompozohet për çdo testues individual dhe të marrë një vlerësim personal. Sa më shumë përvojë dhe statistika, aq më i vogël do të jetë gabimi. Ju gjithashtu mund të përdorni metodën "error seding", kur ne e dimë saktësisht se sa gabime ka në sistem. Natyrisht, duhet të merren parasysh faktorë shtesë, si lloji i sistemit, kompleksiteti i logjikës, platforma, etj. Pra, marrim lidhjen midis fazës së projektit dhe përqindjes së defekteve të gjetura. Tani mund ta zbatojmë këtë varësi në drejtim të kundërt: duke ditur numrin e defekteve të gjetura dhe fazën aktuale të projektit, mund të përcaktojmë numrin total të defekteve në sistemin tonë (me disa gabime, sigurisht). Dhe më pas, bazuar në treguesit e një vlerësimi personal ose të përgjithshëm, mund të përcaktoni se sa defekte mund të gjejë një testues ose një ekip në periudhën e mbetur kohore. Bazuar në këtë vlerësim, tashmë është e mundur të përcaktohet kriteri i efektivitetit të testuesit.
Funksioni i treguesit të performancës së testuesit mund të duket si ky:
Defektet- numri i defekteve të gjetura,
Ashpërsia– kritika e defekteve të gjetura,
Kompleksiteti- kompleksiteti i logjikës së sistemit,
platformë– platforma e zbatimit të sistemit,
Faza- faza e projektit,
periudhëështë periudha kohore në shqyrtim.
Por tashmë një kriter specifik që duhet të plotësojë një testues duhet të zgjidhet në mënyrë empirike dhe duke marrë parasysh specifikat e një organizate të caktuar.
Për momentin, nuk është e mundur të merren parasysh të gjithë faktorët, megjithatë, së bashku me zhvilluesin tonë kryesor Ivan Astafiev dhe menaxherin e projektit Irina Lager, ne dolëm me formulën e mëposhtme që merr parasysh numrin e defekteve dhe kritikitetin e tyre:
, ku
E- efikasiteti, i përcaktuar nga numri i defekteve të gjetura,
D Klienti- numrin e defekteve të gjetura nga klienti, por që testuesi i vlerësuar duhet t'i kishte gjetur,
D testues- numri i defekteve të gjetura nga testuesi,
k dhe d– faktorët korrigjues për numrin total të defekteve.
Dua të vërej menjëherë se kur vlerësohet sipas kësaj formule, duhet të merren parasysh vetëm ato defekte që lidhen me fushën e përgjegjësisë së testuesit të vlerësuar. Nëse shumë testues ndajnë përgjegjësinë për një defekt të humbur, atëherë ai defekt duhet të përfshihet në vlerësimin e secilit testues. Gjithashtu, llogaritja nuk merr parasysh defektet me kritikë të ulët.
Pra, kemi një parabolë të shkallës së tretë, që pasqyron kriterin e intensitetit të gjetjes së defekteve, të cilin testuesi duhet të plotësojë. Në përgjithësi, nëse rezultati i testuesit është mbi parabolën, do të thotë që ai punon më mirë se sa pritej, nëse është më i ulët, atëherë, në përputhje me rrethanat, më keq.
Ekziston një nuancë që lidhet me numrin e përgjithshëm të defekteve të analizuara. Natyrisht, sa më shumë statistika, aq më mirë, por ndonjëherë ju duhet të analizoni fazat e ndryshme të projektit, ndonjëherë ju duhet vetëm një vlerësim për çdo periudhë kohore. Dhe është një gjë kur gjenden 4 defekte gjatë periudhës dhe 2 prej tyre janë nga klienti, dhe krejt tjetër kur konstatohen 100 defekte dhe 50 prej tyre janë nga klienti. Në të dyja rastet, raporti i numrit të defekteve të gjetura nga klienti dhe testuesi do të jetë i barabartë me 0.5, por ne e kuptojmë që në rastin e parë, jo gjithçka është aq keq, por në të dytin është koha për të dhënë alarmin.
Pasi u përpoqëm pa shumë sukses të bënim një lidhje të rreptë matematikore me numrin total të defekteve, ne i bashkëngjitëm, sipas fjalëve të së njëjtës Irina Lager, "paterica" kësaj formule në formën e intervaleve, për secilën prej të cilave ne përcaktuam tonën. koeficientët. Kishte tre intervale: për statistikat nga 1 deri në 20 defekte, nga 21 në 60 defekte dhe për statistikat për më shumë se 60 defekte.
|
Numri i defekteve |
k |
d |
Pjesa e vlerësuar e lejueshme e defekteve të gjetura nga klienti nga numri i përgjithshëm i defekteve të gjetura |
Kolona e fundit në tabelë u prezantua për të shpjeguar se sa defekte lejohet që klienti të gjejë në këtë mostër. Prandaj, sa më i vogël të jetë mostra, aq më i madh mund të jetë gabimi dhe aq më shumë defekte mund të gjenden nga klienti. Nga pikëpamja e funksionit, kjo nënkupton vlerën minimale kufizuese të raportit të numrit të defekteve të gjetura nga klienti dhe testuesi, pas së cilës efikasiteti bëhet negativ, ose pika ku grafiku kalon boshtin X. sa më i vogël të jetë kampioni, aq më i drejtë duhet të jetë kryqëzimi me boshtin. Në terma menaxheriale, kjo do të thotë që sa më i vogël të jetë kampioni, aq më pak i saktë është një vlerësim i tillë, prandaj ne vijmë nga parimi që testuesit duhet të vlerësohen më pak në mënyrë rigoroze në një kampion më të vogël.
Kemi grafikët e formës së mëposhtme:
Grafiku i zi pasqyron kriterin për marrjen e mostrave për më shumë se 60 defekte, të verdhë për 21-60 defekte, jeshile për marrjen e mostrave për më pak se 20 defekte. Mund të shihet se sa më i madh të jetë kampioni, aq më shumë majtas grafiku kalon boshtin x. Siç u përmend tashmë, për punonjësin vlerësues, kjo do të thotë se sa më i madh të jetë kampioni, aq më shumë mund t'i besoni kësaj shifre.
Metoda e vlerësimit konsiston në llogaritjen e efektivitetit të punës së testuesit sipas formulës (2), duke marrë parasysh faktorët e korrigjimit dhe krahasimin e këtij vlerësimi me vlerën e kërkuar në grafik. Nëse rezultati është më i lartë se grafiku, testuesi përmbush pritshmëritë; nëse është më i ulët, testuesi punon nën "shiritin" e kërkuar. Dua të theksoj gjithashtu se të gjitha këto shifra janë përzgjedhur në mënyrë empirike dhe për secilën organizatë ato mund të ndryshohen dhe zgjidhen më saktë me kalimin e kohës. Prandaj, çdo koment (këtu ose në blogun tim personal) dhe përmirësime, unë vetëm i mirëpres.
Kjo metodë vlerësimi sipas raportit të numrit të defekteve të gjetura nga ekipi i testimit dhe klienti/përdoruesi/klienti më duket e arsyeshme dhe pak a shumë objektive. Vërtetë, një vlerësim i tillë mund të kryhet vetëm pas përfundimit të projektit, ose, të paktën, nëse ka përdorues të jashtëm aktiv të sistemit. Por çfarë nëse produkti nuk është ende në përdorim? Si të vlerësohet puna e një testuesi në këtë rast?
Për më tepër, kjo teknikë për vlerësimin e efektivitetit të një testuesi krijon disa probleme shtesë:
1. Një defekt fillon të ndahet në disa më të vogla.
· Menaxheri i testit, i cili ka vënë re një situatë të tillë, duhet ta ndalojë atë me metoda joformale.
2. Menaxhimi i defekteve bëhet më kompleks për shkak të rritjes së numrit të hyrjeve të dyfishta.
· Rregullat për regjistrimin e defekteve në sistemin e gjurmimit të gabimeve, duke përfshirë rishikimin e detyrueshëm të defekteve të ngjashme, mund të ndihmojnë në zgjidhjen e këtij problemi.
3. Mungesa e vlerësimit cilësor të defekteve të konstatuara, pasi qëllimi i vetëm i testuesit është numri i defekteve dhe, si rrjedhojë, mungesa e motivimit të testuesit për të kërkuar defekte “cilësore”. Megjithatë, nuk mund të barazohet kritika dhe "cilësia" e një defekti, e dyta është një koncept më pak i formalizuar.
· Këtu rolin vendimtar duhet të luajë “qëndrimi” i testuesit dhe drejtuesit. Vetëm një kuptim i përgjithshëm i saktë (!) i kuptimit të një vlerësimi të tillë sasior mund ta zgjidhë këtë problem.
Duke përmbledhur të gjitha sa më sipër, arrijmë në përfundimin se është jo vetëm e vështirë, por edhe jo plotësisht e saktë të vlerësohet puna e një testuesi vetëm nga numri i defekteve të gjetura. Prandaj, numri i defekteve të gjetura duhet të jetë vetëm një nga treguesit e vlerësimit integral të punës së testuesit, dhe jo në formën e tij të pastër, por duke marrë parasysh faktorët që kam renditur.
