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.

Defektide haldamise protsess

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.

avastus

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?

A) Nõustuge testimismeeskonnaga, et tegemist on defektiga

B) Testijuht võtab kohtuniku rolli otsustamaks, kas probleem on defekt või mitte

C) Leppige arendusmeeskonnaga kokku, et see ei ole defekt

Korrektne
Vale

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.

Liigitamine

Defektid liigitab tavaliselt testihaldur –

Teeme väikese harjutuse järgmiselt

Lohistage allpool olev defektide prioriteet
1) 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.

Defektide lahendamine

  • Ü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.

Defektide haldamise protsess

Nädala pärast vastab arendaja -

Defektide haldamise protsess

Järgmisel nädalal testija vastab

Defektide haldamise protsess

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

Olulised defektide mõõdikud

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

Olulised defektide mõõdikud

Ü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

Olulised defektide mõõdikud

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

Viga on kodeerimisvea tagajärg/tulemus.

A Tarkvara testimise defekt on tarkvararakenduse variatsioon või kõrvalekalle lõppkasutaja nõuetest või algsetest ärinõuetest. Tarkvaraviga on viga kodeerimisel, mis põhjustab tegelikele nõuetele mittevastavast tarkvaraprogrammist valesid või ootamatuid tulemusi. Testijad võivad testjuhtumite täitmisel selliste defektidega kokku puutuda.

Nendel kahel terminil on väga väike erinevus. Tööstuses on mõlemad vead, mis tuleb parandada ja mida mõned terminid kasutavad vaheldumisi. Testimine võistkonda.

Kui testijad katsejuhtumeid teostavad, võivad nad kokku puutuda selliste testitulemustega, mis on oodatud tulemustega vastuolus. Seda testitulemuste erinevust nimetatakse tarkvara defektiks. Neid defekte või variatsioone nimetatakse erinevates organisatsioonides erinevate nimetustega, nagu probleemid, probleemid, vead või juhtumid.

Tarkvara testimise veaaruanne on üksikasjalik dokument tarkvararakenduses leitud vigade kohta. Veaaruanne sisaldab kõiki üksikasju vigade kohta, nagu kirjeldus, vea leidmise kuupäev, selle leidnud testija nimi, selle parandanud arendaja nimi jne. Veaaruanne aitab tuvastada sarnaseid vigu tulevikus, et neid saaks vältida.

  • Defekti_ID – Defekti unikaalne identifitseerimisnumber.
  • Defekt Descriptioon – Defekti üksikasjalik kirjeldus, sealhulgas teave mooduli kohta, milles defekt leiti.
  • Versioon – Rakenduse versioon, milles leiti defekt.
  • Sammud - Üksikasjalikud sammud koos ekraanipiltidega, mille abil arendaja saab defekte reprodutseerida.
  • Tõusmise kuupäev – Defekti esiletõstmise kuupäev
  • Viide – kus sa Esitage viide sellistele dokumentidele nagu . nõuded, disain, arhitektuur või võib-olla isegi vea ekraanipildid, mis aitavad defekti mõista
  • Tuvastas – Defekti tõstatanud testija nimi/ID
  • Staatus - Defekti olek, sellest lähemalt hiljem
  • Parandatud – Selle parandanud arendaja nimi/ID
  • Sulgemise kuupäev – Defekti sulgemise kuupäev
  • Tõsidus mis kirjeldab defekti mõju rakendusele
  • Prioriteet mis on seotud defektide parandamise kiireloomulisusega. Raskuse prioriteet võib olla kõrge/keskmine/madal, olenevalt löögi kiireloomulisusest, mille korral defekt tuleks vastavalt parandada

Click siin kui video pole juurdepääsetav

Ressursid:

Laadige alla defektide teatamise malli näidis