Defektide haldamise protsess tarkvara testimisel
Mis on defektihaldusprotsess?
Defektide haldamine on süstemaatiline protsess vigade tuvastamiseks ja parandamiseks. Defektide haldamise tsükkel sisaldab järgmisi etappe: 1) defektide avastamine, 2) defektide kategoriseerimine 3) arendajatepoolne defekti parandamine 4) testijatepoolne kontrollimine, 5) defektide sulgemine 6) defektide aruanne projekti lõpus.
See teema juhendab teid, kuidas rakendada defektide haldamise protsessi projekti Guru99 panga veebisaidil. Defektide lahendamiseks võite järgida alltoodud samme.
1. samm) avastamine
Avastamisfaasis peavad projekti meeskonnad avastama kui palju defektid nagu võimalik, enne kui lõppklient selle avastab. Väidetavalt avastatakse defekt ja muudetakse staatus aktsepteeritud kui arendajad seda tunnustavad ja aktsepteerivad
Ülaltoodud stsenaariumi korral avastasid testijad veebisaidil Guru84 99 defekti.
Vaatame järgmist stsenaariumi; teie testimismeeskond avastas Guru99 panga veebisaidil mõned probleemid. Nad peavad neid defektiks ja teavitasid arendusmeeskonda, kuid seal on konflikt -
Mida te sellisel juhul testijuhina ette võtate?
B) Testijuht võtab kohtuniku rolli otsustamaks, kas probleem on defekt või mitte
C) Leppige arendusmeeskonnaga kokku, et see ei ole defekt
Sellisel juhul tuleks konflikti lahendamiseks rakendada lahendusprotsessi, teie võtate kohtuniku rolli, kes otsustab, kas veebisaidi probleem on defekt või mitte.
2. samm) kategoriseerimine
Defektide kategoriseerimine aitab tarkvaraarendajatel oma ülesandeid tähtsuse järjekorda seada. See tähendab, et selline prioriteet aitab arendajatel esmalt parandada need defektid, mis on väga olulised.
Defektid liigitab tavaliselt testihaldur –
Teeme väikese harjutuse järgmiselt
Lohistage allpool olev defektide prioriteet1) Veebisaidi jõudlus on liiga aeglane |
|
2) Veebilehe sisselogimisfunktsioon ei tööta korralikult |
|
3) Veebisaidi GUI-d ei kuvata õigesti mobiilne seadmed |
|
4) Veebisait ei mäletanud kasutaja sisselogimisseanssi |
|
5) Mõned lingid ei tööta |
|
Siin on soovitatavad vastused
Ei. | Kirjeldus | Prioriteet | Selgitus |
---|---|---|---|
1 |
Veebisaidi jõudlus on liiga aeglane |
Suur |
Jõudlusviga võib kasutajale tekitada suuri ebamugavusi. |
2 |
Veebilehe sisselogimisfunktsioon ei tööta korralikult |
Kriitiline |
Sisselogimine on panga veebisaidi üks põhifunktsioone, kui see funktsioon ei tööta, on tegemist tõsiste vigadega |
3 |
Veebisaidi GUI-d ei kuvata mobiilseadmetes õigesti |
Keskmine |
Defekt mõjutab kasutajat, kes kasutab veebilehe vaatamiseks nutitelefoni. |
4 |
Veebisait ei mäletanud kasutaja sisselogimisseanssi |
Suur |
See on tõsine probleem, kuna kasutaja saab sisse logida, kuid ei saa teha täiendavaid tehinguid |
5 |
Mõned lingid ei tööta |
Madal |
See on arendusmeeste jaoks lihtne lahendus ja kasutaja pääseb saidile juurde ilma nende linkideta |
Samm 3) Defektide lahendamine
Defektide lahendamine Tarkvara testimine on samm-sammult defektide parandamise protsess. Defektide lahendamise protsess algab defektide määramisega arendajatele, seejärel kavandavad arendajad defektide parandamise prioriteedi järgi, seejärel parandatakse defektid ja lõpuks saadavad arendajad testihaldurile lahenduse raporti. See protsess aitab defekte hõlpsalt parandada ja jälgida.
Defekti parandamiseks võite järgida järgmisi samme.
- Ülesanne: määratud arendajale või muule tehnikule parandamiseks ja olekuks muudeti Vastamine.
- Ajakava kinnitamine: arendaja pool võtab selles etapis juhtimise enda kätte. Nad loovad nende defektide parandamiseks ajakava, mis sõltub defekti prioriteedist.
- Parandage defekt: Sel ajal, kui arendusmeeskond defekte parandab, jälgib testihaldur defektide parandamise protsessi võrreldes ülaltoodud ajakavaga.
- Teatage resolutsioonist: kui vead on parandatud, saate arendajatelt aruande lahenduse kohta.
4. samm) Kinnitamine
Pärast arendusmeeskonda fikseeritud ja teatatud defekt, testimismeeskond kontrollib et vead on tegelikult lahendatud.
Näiteks ülaltoodud stsenaariumi korral, kui arendusmeeskond teatas, et nad on juba parandanud 61 defekti, testib teie meeskond uuesti, et kontrollida, kas need vead on tegelikult parandatud või mitte.
5. samm) sulgemine
Kui defekt on lahendatud ja kontrollitud, muudetakse defekti olekuks suletud. Kui ei, siis olete saatnud arendusse teate, et viga uuesti kontrollida.
6. samm) Defektidest teatamine
Defektidest teatamine tarkvara testimises on protsess, mille käigus testijuhid koostavad ja saadavad juhtkonnale veaaruande, et saada tagasisidet defektide haldamise protsessi ja defektide oleku kohta. Seejärel kontrollib juhtkond veaaruannet ja saadab tagasisidet või pakub vajadusel täiendavat tuge. Defektidest teatamine aitab paremini suhelda, defekte jälgida ja üksikasjalikult selgitada.
Juhatusel on õigus teada puuduse seisundit. Nad peavad mõistma defektide haldamise protsessi, et teid selles projektis toetada. Seetõttu peate neilt tagasiside saamiseks teavitama neid praegusest veaolukorrast.
Miks vajate defektide haldamise protsessi?
Teie meeskond leidis projekti Guru99 panganduse testimisel vigu.
Nädala pärast vastab arendaja -
Järgmisel nädalal testija vastab
Nagu ülaltoodud juhul, kui defektsuhtlus toimub suuliselt, muutub asi varsti väga keeruliseks. Vigade kontrollimiseks ja tõhusaks haldamiseks on vaja defekti elutsüklit.
Olulised defektide mõõdikud
Tagasi ülaltoodud stsenaariumile. Arendaja ja testimisrühmad on teatatud defektid üle vaadanud. Siin on selle arutelu tulemus
Kuidas mõõta ja hinnata testi täitmise kvaliteeti?
See on küsimus, mida iga Testijuht tahab teada. Siin on 2 parameetrit, mida võite pidada järgmisteks
Ülaltoodud stsenaariumi korral saate arvutada kõrvalekaldumise tagasilükkamise suhe (DRR) on 20/84 = 0.238 (23.8%).
Teine näide, oletatakse, et Guru99 panga veebisaidil on kokku 64 defekte, kuid teie testimismeeskond ainult tuvastab 44 defektid, st need puudusid 20 defektid. Seetõttu saate arvutada, et defekti lekke suhe (DLR) on 20/64 = 0.312 (31.2%).
Järeldus, testi täitmise kvaliteeti hinnatakse kahe parameetri abil
Mida väiksem on DRR-i ja DLR-i väärtus, seda parem on testi teostamise kvaliteet. Mis on suhte vahemik, mis on vastuvõetav? Selle vahemiku võib projekti sihtmärgis määratleda ja selle aluseks võtta või viidata sarnaste projektide mõõdikutele.
Selles projektis on vastuvõetava suhte soovitatav väärtus 5 ~ 10%. See tähendab, et testi täitmise kvaliteet on madal. Peaksite leidma vastumeetmed nende suhtarvude vähendamiseks, näiteks
- Parandama liikme testimisoskused.
- Kuluta rohkem aega testimise täitmiseks, eriti testi täitmise tulemuste ülevaatamiseks.
KKK
Click siin kui video pole juurdepääsetav
Ressursid:
Laadige alla defektide teatamise malli näidis