Täiuslikus maailmas võib tarkvaraarendus kulgeda tõrgeteta ning testimise ja kontrollimise etapid oleksid kiired ning vigu ei leiaks peaaegu üldse.
Kuid kuna see on vaid kujutlusvõime, peavad testijad reaalses maailmas tegelema iga tarkvararakenduse kõrvalekallete ja tõrgetega.
Tarkvara kvaliteedi määrab see, kui puhas või veavaba on tarkvara?
Seetõttu on oluline, et testijad vaataksid läbi keerukad mitmekihilised rakendused ning tuvastaksid, dokumenteeriksid, jälgiksid ja parandaksid arvukad vead või defektid.
Sisukord
- Mida tähendab defekt?
- Klassifikatsioon
- Tüübid
- Defekti mõõdikud
- Defektide klassifikatsioon
- 1. Defekti raskusaste
- Miks see oluline on?
- Defektide tüübid sõltuvalt defekti raskusastmest
- Enne raskusastme määramist olge ettevaatlik
- 2. Defektide prioriteet
- Defektide tüübid defektide prioriteedi alusel
- Juhised enne prioriteedi ja raskusastme valimist
- Erinevus defekti tõsiduse ja prioriteedi vahel
- Raskuse ja prioriteedi kombineerimine
- 3. Defekti tõenäosus
- Defektide tõenäosuse tüübid
- Defekti elutsükkel
- Defektriigid
- Defektide elutsükli juhised
- Defekti algpõhjuse analüüs
- Protsess (5W1H meetod)
- Samm-sammuline algpõhjuse analüüs
- 1. Moodustage algpõhjuste analüüsi meeskond
- 2. Defineeri
- 3. Identifitseerimine
- 4. Algpõhjuse korrigeeriva tegevuse rakendamine (RCCA)
- 5. Põhipõhjuste ennetava tegevuse rakendamine (RCPA)
- Algpõhjuste analüüsi eelised
- Viga vs defekt vs rike
- Tingimused
- Sissejuhatus vea, defekti ja rikkesse
- Viga
- Vigade tüübid
- Vigade põhjused
- Viga vs defekt vs rike
- Lõpusõnad
- Defekti aruanne
- Tarkvara testimise defekti määratlemine
- Määratlege defektiaruanne
- Defekti aruande mall
- Defektide haldamise protsess
- Vajadus defektide haldamise protsessi järele
- Tõhus defektidest teatamine
- Defekti mõõdikud
- Defekti KKK
- Soovitatavad artiklid
Mida tähendab defekt?
Defekt on seisund, mis ilmneb tarkvaratootes, kui see ei vasta tarkvara nõuetele või ootustele.
See võib olla viga programmi kodeerimises või loogikas, mis põhjustab selle talitlushäireid.
Neid määratletakse kui ebakorrapärasusi või kõrvalekaldeid oodatavatest tulemustest, mis tulenevad arendaja vigadest arendusfaasis.
Defektid või vead või vead on puudused või ebatäiuslikkused, mis takistavad tarkvararakendusel seda, mida talt oodatakse.
Defektid põhjustavad tarkvararakenduse rikke.
Mõned meetodid, mis on kasutusele võetud programmeerijate poolt arenduse käigus vigade sissetoomise vältimiseks, on järgmised:
- Peer Review
- Koodi analüüs
- Kasutatud programmeerimistehnikad
- Tarkvaraarenduse metoodikad
Klassifikatsioon
Allpool toodud defektide klassifikatsioonid on vaid juhised. Defektide klassifitseerimise alus sõltub organisatsioonist ja nende poolt kasutatavast defektide jälgimise tööriistast.
Meeskonnaliikmetel peab olema eelkokkulepe defektide klassifikatsioonis, mida kasutatakse tulevaste konfliktide vältimiseks.
Defekte saab klassifitseerida järgmiselt:
Raskusaste
Defekti raskusaste oleneb defekti keerukusest, mida tuleb arengu seisukohalt parandada.
Raskusaste andis testijale aimu tarkvara kõrvalekaldest spetsifikatsioonidest.
See võib olla:
- Kriitiline – need vead kajastavad olulisi kõrvalekaldeid tarkvararakenduse funktsionaalsuses ilma nende parandamiseta, mida kvaliteedikontrolli tester ei saa kinnitada.
- Suured – need vead leitakse siis, kui rakenduse oluline moodul ei tööta, kuid ülejäänud süsteem töötab hästi. Kvaliteedimeeskond peab need probleemid lahendama, kuid võib ka ülejäänud rakenduse kinnitada, olenemata sellest, kas suur defekt on parandatud või mitte.
- Keskmine – need vead on seotud ühe ekraani või funktsiooni probleemidega, kuid need ei mõjuta süsteemi kui terviku toimimist. Puudused ei blokeeri ühtegi funktsionaalsust.
- Madal – need vead ei mõjuta tarkvararakenduse funktsionaalsust üldse. See võib olla seotud kasutajaliidese ebajärjekindluse, kosmeetiliste defektide või soovitustega kasutaja kasutajaliidese kogemuse parandamiseks.
Tõenäosus
Defekti tõenäosust võib defineerida kui süsteemi tunnuse defekti tõenäosust.
Vea leidmise tõenäosus sõltub selle konkreetse funktsiooni kasutamisest. Kui atribuuti kasutatakse harva, on leitud defekti tõenäosus suur. Siiski, kui atribuuti kasutatakse laialdaselt, võib defekti esinemise tõenäosus olla väike, olenevalt defekti avastamise haruldusest.
See võib olla:
- Kõrge – kui defekti leiavad kõik või enamus funktsiooni kasutajad kergesti, siis on defekt suure tõenäosusega.
- Keskmine – kui defekti leiab vähemalt 50% funktsiooni kasutajatest, on defekti esinemise tõenäosus keskmine.
- Madal – kui väga vähesed funktsiooni kasutajad puutuvad kokku defektiga, on defekti esinemise tõenäosus väike.
Prioriteet
Konkreetse vea parandamise tähtsus või kiireloomulisus määrab defekti prioriteedi.
Defekti prioriteedi määrab a tarkvara tester ja lõplikult projektijuht.
Seda saab liigitada järgmiselt:
- Kiireloomuline – selle kategooria defekti on vaja viivitamatult lahendada, kuna need vead võivad rakendust tõsiselt mõjutada ja põhjustada kulukaid remonditöid, kui neid ei ravita.
- Kõrge – nende defektide viivitamatu lahendamine on oluline, kuna need vead mõjutavad rakendusmooduleid, mis muudetakse kuni defektide parandamiseni kasutuks.
- Keskmine – need ei ole nii olulised defektid ja nende parandamise saab ajastada hilisemates väljaannetes.
- Madal – kui ülaltoodud kriitilised vead on parandatud, võib tester need parandada või mitte.
Süstimise faas
Defektide klassifitseerimiseks saab kasutada ka tarkvaraarenduse elutsükli faasi, milles defekt esmakordselt kasutusele võeti või sisestati.
Defekti süstitud faas leitakse pärast nõuetekohast algpõhjuse analüüsi.
Defekti saab süstida mis tahes järgmistest etappidest:
- Nõuete arendamine
- Detailne disain
- Kõrgetasemeline disain
- Kodeerimine
- Kasutuselevõtt
Faas tuvastatud
Pärast süstitud faasi saabumist tuvastatakse faas. Faasi, milles konkreetne defekt tuvastati, nimetatakse tuvastatud faasiks.
Seal on järgmised etapid Tarkvara testimine :
Seotud moodul
Defekti klassifikaatorina saab kasutada moodulit, milles konkreetne defekt tuvastati.
Seotud moodulite klassifikatsioon annab teavet kõige rohkem vigu sisaldava mooduli kohta.
Seotud kvaliteedimõõde
Need on sadu tarkvara kvaliteedi dimensioone, nagu juurdepääsetavus, ühilduvus, samaaegsus ja palju muud.
Otsus, milline mõõde on olulisem ja tuleks kõigepealt fikseerida, on subjektiivne. See sõltub ainult testija suuremate väärtuste mõõtmest selles konkreetses olukorras.
Nõuded ja spetsifikatsiooni defekt
Kliendi lünk või tootja (testija või arendaja) lünk võib põhjustada nõuetega seotud defekte, mille puhul arendaja või testija ei mõista kliendi nõudeid.
Nõudedokumendid tuleks nende puuduste vähendamiseks koostada üheselt mõistetavates, vastuolulistes, selgetes, üleliigsetes ja täpsetes nõuetes.
Disaini defektid
Ühildumatute või valesti projekteeritud komponentide ja moodulite vastastikmõju põhjustab süsteemis defekte.
Algoritmid, loogika- või andmeelemendid, mooduli liidese kirjeldused, algoritmid ja välise tarkvara või riistvara kasutajaliidese kirjeldused peavad olema disainivigade vältimiseks õigesti kavandatud.
Kodeerimise vead
Disaini või koodide vale rakendamine arendus- või kodeerimisstandardite puudumise tõttu võib põhjustada kodeerimisvigu.
Need vead on tihedalt seotud klasside kujundamise defektidega, eelkõige juhul, kui detailprojekteerimisel kasutatakse pseudoklasse.
Mõnikord võib olla keeruline defekti klassifitseerida kodeerimis- või disainidefektiks.
Defektide testimine
Vale testimine või testitud artefaktide defektid põhjustavad testimise defekte.
Neid võib olla kolme tüüpi:
- Testitööriista defekt – testijate kasutatavad testimisvahendid on samuti võimelised tarkvaras defekte tekitama. A käsitsi test kasutatakse automaatsete tööriistade põhjustatud defektide leidmiseks.
- Katsedisaini defekt – testimisartefaktide defekte, nagu testimisplaanid, katsestsenaariumid, katseandmete määratlus ja testjuhtumid, nimetatakse testidisaini defektideks.
- Testikeskkonna defekt – kui testkeskkond, st riistvara, tarkvara, testimisinimesed ja simulaator ei ole seadistatud, tekivad testkeskkonna defektid.
Olek
Defekti saab klassifitseerida selle defekti elutsükli oleku või oleku järgi, milles defekt parasjagu on.
Need seisundid võivad olla:
- Avatud
- Suletud
- Edasi lükatud
- Tühistatud
Sõna toode
Töötoote või arendusfaasi dokumentide või lõpptoodete põhjal võib defekti liigitada järgmiselt:
- Lähtekood – rakenduse lähtekoodis leitud defekt.
- SSD – tarkvara süsteemiuuringu dokumendis leitud defekt.
- Kasutaja dokumentatsioon – tarkvara kasutusjuhendites või kasutusjuhendis leitud defekt.
- ADS – tarkvara arhitektuurse projekti dokumendis leitud defekt.
- Testplaan või testjuhtum – tarkvara testimisplaanis või testjuhtumites leitud defekt.
- FSD – tarkvara funktsionaalsete spetsifikatsioonide dokumendis leitud defekt.
- DDS – tarkvara detailplaneeringu dokumendis leitud defekt.
Tüübid
Mõned peamised tarkvaraarenduse defektide tüübid on järgmised:
Loogilised vead
Koodi juurutamise ajal ei pruugi programmeerija probleemist selgelt aru saada või mõelda valesti. Sellistel juhtudel tekivad loogilised vead.
Loogilised vead on seotud tarkvara tuumaga ja võivad ilmneda, kui programmeerija ei rakenda nurgajuhtumeid õigesti.
Toimivusdefektid
Kui süsteem või tarkvararakendus ei anna soovitud ja oodatud tulemusi ega suuda täita kasutaja nõudeid, ilmnevad jõudlusdefektid.
Need defektid hõlmavad ka süsteemi reageerimist süsteemi koormuse muutmisele.
Mitme keermestamise defektid
Mitme ülesande samaaegset täitmist nimetatakse mitmelõimeliseks ja see viib väga keerulise silumiseni.
Deadlocki ja Starvationi probleemid mitme lõimega töötlemisel võivad põhjustada süsteemi rikke.
Aritmeetilised vead
Liigne töömaht või teadmiste vähenemine võib põhjustada programmeerija vigu aritmeetilistes avaldistes ja nende lahendustes, mida nimetatakse aritmeetilisteks defektideks.
Koodi ülekoormamine võib muuta programmeerija võimatuks kirjutatud koodi õigesti lugeda ja põhjustada ka aritmeetilisi vigu.
Süntaksi vead
Mõnikord teevad arendajad koodi kirjutades vigu, mis on seotud koodi stiili või süntaksiga.
Need vead võivad olla nii väikesed kui sümboli väljajätmine.
Süntaksivigade näide võib olla semikooloni väljajätmine (;) koodi kirjutamisel C++ või Java keeles.
Liidese defektid
Defektid võivad mõjutada kasutaja ja tarkvara vahelist suhtlust. Neid nimetatakse liidese defektideks.
Keerulised, ebaselged või platvormipõhised liidesed võivad põhjustada tarkvara liidese defekte.
Defekti mõõdikud
Testitava projekti kvaliteedi, maksumuse ja tõhususe täpne hindamine on ülioluline.
Defekti mõõdikud aitavad meil hinnata tarkvararakenduse varem mainitud aspekte.
Defektide tiheduse mõõdikud
Defektide paksust või kontsentratsiooni tarkvara sees nimetatakse defektide tiheduse mõõdikuteks.
Defektide tiheduse mõõdikuid saab määratleda protsendina tuvastatud defektide arvust nõude või katsejuhtumi kohta.
Valem:
|_+_|Kus suurus on nõutavate testjuhtumite arv.
Näide:
Oletame, et tarkvaras on 1000 testjuhtumit, millest 600 on läbitud ja 400 ebaõnnestunud. Defektide tihedus on sel juhul
|_+_|Seega on defekti tihedus 40%. Seega ebaõnnestus täitmise ajal 40% testjuhtumitest või ainult 40% testi kujundusest võis defekte leida.
Defektide kogumõõdik
Kogudefektide suhteline hinnang mooduli suuruse ja tarkvara keerukuse kohta võib selgitada testimise tõhusust.
Keegi ei suuda uskuda arendajat, kes ütleb, et mis tahes tarkvaras ei leitud defekti.
Defektide jaotus prioriteedi ja raskusastme järgi
Oleme juba aru saanud, et defektid klassifitseeritakse nende prioriteedi ja raskusastme alusel.
Kui kõik tuvastatud defektid on madala raskusastmega või esmatähtsad, tähendab see, et testimisrühm ei ole süsteemi korralikult testinud.
Kogudefektid annavad hea ettekujutuse testimise kohta ning prioriteetsus ja tõsidus võivad aidata testimisel ja koostamise kvaliteedil.
Kaalutud defektide tihedus
Keskmist defekti tõsidust katsejuhtumi kohta võib määratleda kui kaalutud defekti tihedust.
Valem:
|_+_|Kui suurus on katsejuhtumite või nõuete arv.
Raskusastmest lähtuvalt määratakse kaalud 5,3 ja 1.
Defekti leidmise kulud
Olgu see arendus või testimine, kulu mängib iga projekti puhul olulist tegurit.
Kui klient maksab suuri summasid, eeldab ta, et tarnitav tarkvara on defektideta ja tõhus.
Valem:
|_+_|Koguraha saab arvutada täielike ressursside, arveldusmäärade ja testimise kestuse põhjal.
Defektide eemaldamise tõhusus
Testimismeeskonna pädevust tõhusalt eemaldada ja tuvastada maksimaalne vigade arv enne tarkvara saatmist järgmises faasis nimetatakse defektide eemaldamise tõhususe mõõdikuteks.
Valem:
|_+_|Näide:
Kaaluge tarkvara, millel on algfaasis 200 defekti. Pärast tarkvara parandamist, uuesti testimist ja regressioonitesti läbiviimist testib kasutajate aktsepteerimise meeskond ja leiab veel 40 defekti, mida oleks võinud eelmiste testimisetappide käigus tuvastada ja lahendada. Need 40 defekti lekkisid järgmistesse faasidesse ja neid ei eemaldatud süsteemist. Seega
|_+_|Seega suutis tarkvara testimise meeskond tuvastada ja parandada ainult 83,33% kõigist defektidest ning lekitas ülejäänud 16,67% järgmistes etappides.
Defektide lekke mõõdikud
Vastupidiselt defektide eemaldamisele näitavad defektide lekkemõõdikud nende defektide protsenti, mis on lekkinud praegusest testimisetapist järgmisse või järgmisesse faasi.
Defektide lekke mõõdikud peaksid meeskonna väärtuse parandamiseks olema minimaalsed.
Valem:
|_+_|Näide:
Kaaluge tarkvara, millel on algfaasis 200 defekti. Pärast tarkvara parandamist, uuesti testimist ja regressioonitesti läbiviimist testib kasutajate aktsepteerimise meeskond ja leiab veel 40 defekti, mida oleks võinud eelmiste testimisetappide käigus tuvastada ja lahendada. Need 40 defekti lekkisid järgmistesse faasidesse ja neid ei eemaldatud süsteemist. Seega
|_+_|Seetõttu lekkis järgmisse faasi 16,67% defektidest.
Defekti vanus
Defektide elutsükkel algab uue defekti tuvastamisest ja lõpeb siis, kui need parandatakse või säilitatakse järgmise väljalaske jaoks ja dokumenteeritakse.
Defekti vanus on ajavahemik defekti tuvastamise ja kõrvaldamise vahel.
|_+_|Defekt võib ilmneda tundides või päevades – mida väiksem on defekti vanus, seda parem on testimismeeskonna reageerimisvõime.
Defektide klassifikatsioon
Kõik vead ei ole ühesugused ega vaja testijate viivitamatut tähelepanu.
Seetõttu on defektide klassifitseerimine hädavajalik.
Defektid määratletakse raskusastme või prioriteediga, et arendusmeeskond saaks aru, milline neist tuleb kõigepealt lahendada.
1. Defekti raskusaste
Defekti või vea tõsidus , mis tähendab võhiku terminites, võib seletada kui mõju, mida defekt avaldab tarkvara arendamisele või täitmisele.
ISTQB järgi võib defekti tõsidust defineerida kui defekti mõju astet süsteemi komponendi või kogu süsteemi arengule või toimimisele.
Kvaliteedikontrolli meeskonna ülesanne on määratleda iga tuvastatud defekti raskusaste.
Tõhusate defektide tõsidusmeetmete abil saab kvaliteedikontrolli meeskond lahendada süsteemi kriitilised defektid ja muud tõsidused, et kontrollida lõppkasutaja potentsiaalset ärimõju.
Näide:
Lisa ostukorvi on vale kirjapilt on mittekriitiline defekt, kuid e-kaubanduse veebisaidil mittetöötav Lisa ostukorvi on kriitiline defekt.
Miks see oluline on?
Probleemi raskusastmete määratlemise tähtsus on järgmine:
- Testimismeeskonnad saavad määrata testimisprotsessi tõhususe.
- Tarkvara erinevate aspektide ebaõiget toimimist on lihtne kontrollida.
- Vigade jälgimist suurendatakse defektide raskusastme abil, mis parandab tarkvara kvaliteeti.
- Kvaliteedikontrolli meeskond saab esmalt kindlaks teha ja testida suurema raskusastmega defekte.
- Vigade jälgimise ja haldamise süsteemid võivad muutuda süstemaatilisemaks ja organiseeritumaks, kasutades defekti või vea tõsidust.
- Defekte saab tõhusamalt jaotada sõltuvalt arendaja oskuste ja kogemuste tasemest ning raskusastmest ja tasemest.
Defektide tüübid vastavalt defekti raskusastmele
Defekti raskusastme põhjal on tarkvaras neli raskusastet:
(i) Kriitiline
Seda tähistab S1 ja see on kõrgeim raskusaste või kõrgeima prioriteediga raskusaste, mida tarkvaras võib leida.
Need veatüübid takistavad täielikult tarkvara käitamist ja põhjustavad mõnikord süsteemi täieliku väljalülitamise.
Nende defektide eemaldamine on ülimalt oluline, kuna neile ei ole lahendust ja need häirivad tarkvara edasist testimist.
Sest näide , isegi pärast õige ID ja parooli sisestamist ei saa kasutaja sisse logida ja rakendusele juurdepääs on kriitiline defekt.
(ii) major
Märkimisväärne defekt ilmneb siis, kui süsteemile antakse sisendite komplekt, kuid see ei suuda pakkuda soovitud tulemuste komplekti. S2 tähistab seda.
Need vead võivad põhjustada süsteemi kokkujooksmist, kuid jätta mõned funktsioonid siiski toimivaks, jättes seega väikese ruumi nende ümbertöötamiseks edasiseks testimiseks.
Sest näide , kui e-kaubanduse veebisaidil ei saa ostukorvi lisada rohkem kui ühte toodet, on see märkimisväärne defekt, kuid mitte kriitiline, kuna kasutaja saab ikkagi osta ühe kauba.
(iii) Alaealine
Kui komponent ei anna oodatud tulemusi või ei vasta selle nõuetele, kuid sellel on väheoluline mõju kogu süsteemile, nimetatakse väikeseks või mõõdukaks defektiks.
Väiksemad vead, mida tähistab S3, mõjutavad vaid väikest osa rakendusest, mis põhjustab tarkvara ebaloomuliku käitumise, kuid mõjutab süsteemi tervikuna.
Sest näide , isegi pärast kaupade tellimist on kaup näha tellitud kaupade hulgas ja seda saab jälgida, kuid kuvatakse teade Kauba tellimata viipaaknast. See on väike defekt, kuna viip on lihtsalt vale.
(iv) Triviaalne
Defektide triviaalsed vead on madala raskusastmega vead, mis mõjutavad ainult tarkvara välimust ja olemust, kuid ei mõjuta süsteemi või tarkvara funktsionaalsust ega talitlushäireid.
See S4 raskusastme defekt ei pruugi funktsionaalsust mõjutada, kuid on siiski kehtiv defekt ja see tuleb parandada.
Sest näide , Vale joondus või kirjaviga veebisaidi tingimuste/tingimuste lehel on tühine viga.
Enne raskusastme määramist olge ettevaatlik
Kuna defektide tõsidus on tarkvara testimise oluline aspekt, tuleks nende määratlemisel olla väga ettevaatlik.
Iga raskusaste peab olema selgelt määratletud, kuna see võib põhjustada erinevusi arendus- ja kvaliteedikontrolli meeskonna vahel.
2. Defektide prioriteet
Defekti lahendamise tähtsuse või kiireloomulisuse määrab defekti või vea prioriteetsus.
The projektijuht määrab igale defektile prioriteedi, lähtudes kasutaja ärivajadustest ja defekti tõsidusest.
Defekti prioriteetsus on subjektiivne, kuna see määratakse pärast võrdlust teiste defektidega.
Peale projektijuhi määravad defektide kõrgema või madalama prioriteedi tooteomanikud, ärianalüütikud ja ettevõtte sidusrühmad.
Defektide tüübid defektide prioriteedi alusel
Defektide klassifitseerimiseks on neli prioriteetset taset:
(i) Koheselt
Süsteemi ja ärinõudeid mõjutavad vead tuleb koheselt parandada.
Need defektid, mida tähistab P1, takistavad süsteemil põhifunktsioonide täitmist või muudavad süsteemi ebastabiilseks, piirates sellega edasist testimist.
Kõik kriitilised raskusastmega defektid on esmatähtsad, välja arvatud juhul, kui ettevõte/huvirühmad järjestavad järjekorda.
Sest näide , ei pruugi valesti kirjutatud ettevõtte nimi olla tõsine või kriitiline defekt, kuid see on esmatähtis, kuna see mõjutab ettevõtte äritegevust.
(ii) kõrge
Need P2 või kõrge prioriteediga defektid on järgmised, mis tuleb lahendada, kui esmatähtsad vead on lahendatud.
Defektid, mis ei vasta nende väljumiskriteeriumidele või muudavad komponendi eelmääratletud jõudlusnäitajatest kõrvale. Need meetmed võivad sõltuda kodeerimisest või keskkonnateguritest.
Defekt ei puuduta otseselt ettevõtet ega klienti, kuid see tuleb siiski kiiresti parandada.
Sest näide , toodete ostukorvi mitte lisamine kuulub kõrge prioriteediga kategooriasse.
(iii) Keskmine
Defektid, mis ei kuulu kõrgesse ja vahetusse kategooriasse, kuuluvad keskmise prioriteedi alla.
Need vead tuleb parandada kohe pärast ülalnimetatud defektide parandamist, kuna need võivad sisaldada funktsionaalsusega seotud defekte.
Need defektid, mida tähistab P3, võivad mõnikord sisaldada triviaalseid või kosmeetilisi vigu, näiteks ebaõnnestumise ajal valesid veateateid.
Neid defekte saab parandada ka järgmistes versioonides.
Sest näide , isegi pärast edukat sisselogimist kuvatakse veateade sisselogimise ID/parool kehtetu, siis on tegemist keskmise prioriteediga veaga.
(iv) Madal
Need on enamasti madala raskusastmega defektid, mis ei vaja kohest tähelepanu ja mida saab lahendada pärast muude kriitiliste ja oluliste defektide parandamist.
Need vead, mida tähistab P4, võivad olla trükkimisvead, kosmeetilised vead või soovitused, mis on seotud kasutajakogemuse parandamise täiustustega.
Kuna need ei vaja kohest tähelepanu, saab neid tulevikus lahendada.
Sest näide , ei asu kontakti vahekaart avalehel ja on peidetud navigeerimisriba teises menüüs.
Juhised enne prioriteedi ja raskusastme valimist
Arendus- ja testimismeeskondade vahelise sujuva tehingu ja suhtluse tagamiseks tuleb enne tõsiduse ja prioriteedi astme valimist otsustada mõned juhised.
Mõned neist juhistest on järgmised:
- Oluline on mõista tõsiduse prioriteedi kontseptsiooni.
- Enne defekti mõju üle otsustamist mõistke defekti prioriteetsust kasutaja jaoks.
- Loetlege kõik vea esinemise ja toimimisega seotud jadad.
- Esiteks isoleerige defekt ja seejärel määrake selle löögi sügavus.
- Keerukuse ja kontrollimisaja põhjal määrake iga defekti parandamiseks kuluv aeg.
- Määrake sisendi klass, mida defekt toetab.
- Määrake raskusaste vea tüübi alusel, kuna see määrab ka selle prioriteedi.
Erinevus defekti tõsiduse ja prioriteedi vahel
| Defekti raskusaste | Defektide prioriteet |
|---|---|
| See on defekti mõju aste süsteemile. | See on järjekord, milles arendaja vea kõrvaldab. |
| Kvaliteedikontrolli testijad määravad raskusastme. | Tootejuhid ja teised ettevõtte sidusrühmad määravad prioriteetide järjestuse. |
| Kui tõsidus on kord otsustatud, ei muutu see aja jooksul. | Defektide prioriteet võib muutuda võrreldes teiste defektidega. |
| Seda on nelja tüüpi: kriitiline, suur või tühine | Seda on nelja tüüpi: ImmediateHighMediumLow |
| See näitas vea tõsidust. | See näitab defekti ärilist tähtsust ja seda, kui kiiresti see tuleb parandada. |
| Raskusaste põhineb funktsionaalsusel, mida defekt mõjutab. | Prioriteet põhineb äriväärtusel, mida defekt mõjutab. |
| SIT-i ajal fikseeritakse vead esmalt raskusastme ja seejärel prioriteedi alusel. | UAT ajal parandatakse defektid prioriteedi alusel. |
Raskuse ja prioriteedi kombineerimine
Kuna prioriteet ja tõsidus on kaks kõige olulisemat defektide klassifikatsiooni, kombineerivad paljud organisatsioonid erinevate tasemete määratlemiseks raskusastme ja prioriteetsuse taseme.
1. Kõrge prioriteet, kõrge raskusastmega
Kriitilised või olulised ärinõuete vead kuuluvad sellesse kategooriasse ja need tuleb kohe parandada, kuna enne nende parandamist ei saa toimuda täiendavat testimist.
Sest näide , pärast e-kaubanduse veebisaidil ostukorvis olevate toodete eest tasumist ei ole kaup ikka veel tellitud, kuid makse on teie kontolt maha arvatud.
2. Kõrge prioriteet, madal raskusaste
Defektid, mis ei mõjuta funktsionaalset nõuet, kuid mõjutavad ärinõuet või kasutajakogemust, kuuluvad sellesse kategooriasse.
Sest näide , ei ole veebisaidi fondid ja joondus kasutajasõbralikud, siis klõpsab veebisaidil vähem kliente, mis mõjutab äritegevust.
3. Kõrge raskusastmega, madala prioriteediga
Need defektid on funktsionaalsete nõuete poolest väga tõsised, kuid ei mõjuta ärinõudeid.
Sest näide , pääseb rakendusele juurde ainult konkreetse brauseri uuematest versioonidest, millel on väga tõsine, kuid madala prioriteediga defekt.
4. Madal raskusaste, madal prioriteet
Sellesse kategooriasse kuuluvad kirjavead, font, vale joondus rakenduse hilisematel lehtedel, millele kasutajad sageli ei pääse.
Sest näide , kirjavead tingimuste lehel või privaatsuspoliitika lehtedel on madala raskusastmega ja madala prioriteediga defektid.
3. Defekti tõenäosus
Defekti tõenäosus on tõenäosus, et kasutaja näeb defekti.
Defekti tõenäosust võib nimetada ka defekti nähtavuseks, vea nähtavuseks või vea tõenäosuseks ning seda tähistatakse protsentides (%).
Defekti tõenäosus määratakse kindlaks konkreetse funktsiooni või komponendi, kuid mitte kogu süsteemi kohta.
Seega võib laialdaselt kasutatavas funktsioonis esineda väikese tõenäosusega defekt, samas kui suure tõenäosusega defekti kasutatakse harva.
Defektide tõenäosuse tüübid
(i) Kõrge
Suure tõenäosusega vead on need, mida kasutajad võivad hõlpsasti kohata.
Need vead esinevad peaaegu kõigis kasutaja juurdepääsu funktsioonides.
(ii) Keskmine
Konkreetse funktsiooni testimise ajal, kui defekti kohtab rohkem kui 50% selle kasutajatest, liigitatakse defekt keskmise tõenäosusega defektiks.
(iii) Madal
Väikese tõenäosusega defekte kohtavad väga vähesed kasutajad ja neid ei ole vaja kohe lahendada.
Defekti elutsükkel
Defekti elutsükkel või vea elutsükkel on määratlenud olekute kogumi, mida defekt läbib kogu oma eluvormi jooksul ja mis leitakse olevat lahendatud / tagasi lükatud / edasi lükatud.
Vea elutsüklit võib mõista kui vea kasvutsüklit, mis on määratletud erinevate meeskondade vahelise koordineerimise ja suhtlemise hõlbustamiseks.
Veatsükkel varieerub olenevalt organisatsioonist, tööriistadest (JIRA, QC jne) ja projekti tüübist.
Defektriigid
Tarkvara testimisel on defekti või vea elutsüklis erinevaid olekuid. Need on järgmised:
Uus: Kui testimismeeskond leiab arendatud rakenduses vea või vea, käivitub tarkvara veatsükkel ja väidetavalt on viga uues olekus.
Määratud: Pärast defekti avastamist kiidab testijuht või projektijuht defekti heaks ja määrab selle arendusmeeskonnale, muutes defekti olekuks Määratud.
Avatud: Kui arendusmeeskond hoiab defekti käigus, määratakse sellele avatud olek. Arendajad võivad hakata viga parandama, kui see ei kuulu vea elutsükli järgmistesse kategooriatesse:
- Viga loodetakse parandada hilisemates versioonides.
- Viga on väike ja ei vaja kohest tähelepanu.
- Klient võib kliendi nõuet muuta.
- Viga ei ole seotud tarkvara praeguse järguga.
- Meeskonnajuht või projektijuht peaks tagama, et meeskonnaliikmed teaksid oma vastutust defekti ja selle staatuse eest.
- Defekti staatus tuleks määrata ja seda säilitada.
- Veenduge, et kogu defekti elutsükkel on hästi dokumenteeritud ja iga teie meeskonnaliige arusaadav.
- Enne defekti staatuse muutmist tuleb täpsustada usutav ja üksikasjalik põhjus.
- Probleemiga seotud süsteemid,
- Probleemi periood,
- Probleemi mõju ja
- Probleemiga seotud isik.
- Samade küsimuste ümbertöötamise vähendamine ikka ja jälle.
- Korduvate probleemide ennetamine.
- Probleemide lahendamise kulude vähendamine.
- Klientide ja sidusrühmade varustamine tühise defektiga tarkvaraga
- Arendaja loogiline viga põhjustab vea.
- Projekteerimisviga arhitekti poolt.
- Inimharjumused, nagu letargia, viivitamine või muud, põhjustavad vea.
- Vigu võib põhjustada klientidelt saadud ebaõige või ebapiisav teave.
- Nõuete valesti tõlgendamine ärianalüütiku poolt põhjustab vea.
- Nõuete valesti edastamine analüütiku ja arendaja vahel põhjustab vigu.
- Avastus – defekt
- Kategooria – defekt
- Parandamine/lahendus – defekti parandamine arendajate poolt
- Kontrollimine – testijate poolt
- Sulgemine – defektiga
- Defekti aruanne
Parandatud: Pärast defekti lahendamist annab arendusmeeskond vea edasi testimismeeskonnale uuesti testimiseks, määrates sellele oleku Fikseeritud.
Kordustesti ootel: Kui testimismeeskond saab vea elutsükli eelmisest etapist fikseeritud oleku defekti, määratakse vea olek Ootel kordustestimiseks.
Uuesti testimine: Kui rakenduse kordustestimine on alanud, et kontrollida, kas defekt on parandatud või mitte, määratakse defektile uuesti testimise olek. Kui defekti kordustestimine on lõppenud, saab testimisrühm määrata sellele veatsükli kahest olekust ühe:
Ava uuesti: Kui defekti ei lahendata ka pärast uuesti testimist, määrab testimine veale Reopen oleku ja saadab selle tagasi arendusmeeskonnale.
Kinnitatud: Kui defekt on täielikult kõrvaldatud, omistatakse defektile olek Kontrollitud, mis tähendab, et defekt on lahendatud ja kvaliteedikontrolli poolt kontrollitud.
Suletud: Kui arendaja on vea parandanud ja testija selle kinnitanud, muudetakse defekti olekuks Suletud. Ka defekti elutsükkel saab selle oleku valmimisega läbi.
Defektide elutsükli juhised
Enne defekti elutsükli olekute määratlemist tuleb arvestada konkreetsete juhistega. Nemad on:
Defekti algpõhjuse analüüs
Nüüd, kui oleme näinud defekte ja defektide elutsükli klassifikatsiooni, tutvume defektide algpõhjuste analüüsiga (RCA), et mõista selle algpõhjuseid.
Kui seda analüüsi teha süstemaatiliselt, on praegusest tarkvarast kasu mitte ainult, vaid ka kogu organisatsioonile.
Algpõhjuste analüüs aitab defekte varakult leida, vähendades seeläbi nende parandamise üldkulusid pikemas perspektiivis. Seda saab teha nii disainivigade, testimisdefektide kui ka tootedefektide puhul.
Kuid pidage meeles, et algpõhjuste analüüsi eesmärk ei ole defekti ravimine või kõrvaldamine, vaid ainult nende leidmine või diagnoosimine.
Arvestades külmiku mehaaniku juhtumiuuringut, saame algpõhjuste analüüsist paremini aru. Hea mehaanik leiab esmalt meie külmiku probleemide algpõhjuse ja seejärel rakendab selle parandamiseks sobivaid meetodeid.
Algpõhjuste analüüsi võib pidada pöördprojekteerimise mehhanismiks, mille puhul sündmuste ahel kulgeb tagurpidi, alustades viimasest võimalikust tegevusest.
Protsess (5W1H meetod)
Alltoodud nelja küsimuse abil saab läbi viia algpõhjuste analüüsi:
Mida?
Esimene ja oluline samm algpõhjuste analüüsi protsessis on kindlaks teha, MIS probleem seisneb.
Kui me probleemi täpselt ei tea, on probleemi algpõhjust võimatu kindlaks teha.
Sest näide , on teie veebisaidi kasutajad kurtnud, et nad ei saa õige ID ja parooliga sisse logida.
Millal?
Järgmine samm on kindlaks teha, millal konkreetne probleem ilmnes.
Näiteks ei saanud kasutajad kella 4.00–5.00 sisse logida.
Kuhu?
See samm määrab, kus probleem ilmnes, st millisel veebisaidi lehel või tarkvara asukohas.
Sest näide , ei saanud kasutajad sisselogimislehel sisse logida, mistõttu tekkis probleem sisselogimislehel.
WHO?
See küsimus puudutab inimest, kes oli seotud probleemi lahendamisega.
Sest näide , vastutas serveri hoolduse eest serveri administraator, mis põhjustas kasutajatega sisselogimisprobleeme.
Miks?
See samm tegeleb probleemi põhjuse väljaselgitamisega ja selle algpõhjuse üksikasjaliku analüüsiga.
Sest näide , serverid seisid hoolduse tõttu maas, mis segas kasutajate sisselogimist.
Kuidas?
See on algpõhjuste analüüsimise protsessi viimane etapp. See aitab meil tagada, et probleem tulevikus ei tekiks.
Sest näide , tagades, et süsteemi hoolduse ajal saadetakse kõigile registreeritud kasutajatele e-kiri või SMS, aitab meil vältida selle edaspidist esinemist.
Samm-sammuline algpõhjuse analüüs
Algpõhjuste analüüsimisel on oluline rakendada struktuurset ja organiseeritud lähenemisviisi.
Järgitavad sammud on järgmised:
1. Moodustage algpõhjuste analüüsi meeskond
Iga meeskonna ülesanne on omada RCA juhti, kes kogub probleemidega seotud üksikasju ja algatab RCA protsessi.
Iga meeskonna töötajad, st nõuded, testimine, kvaliteet, disain, tugi ja hooldus ning dokumentatsioon, peaksid olema RCA meeskonnas.
Iga meeskond vastutab defekti jälitamise ja oma etapis valesti läinud juhtumite aruande, probleemi tõendite jms abil.
2. Defineeri
Kui juhtumiaruanne, probleemi tõendid ja muud dokumendid on kogutud, uurib RCA meeskond probleemi ja püüab kindlaks teha:
Sündmuste jada, mis viib kasutaja probleemini,
3. Identifitseerimine
Pärast probleemi määratlemist saab RCA meeskond kasutada Fishbone'i või 5 Miks analüüs, et määrata algpõhjus.
RCA juht aitab seejärel paika panna reeglid ajurünnaku sujuvaks toimimiseks.
4. Algpõhjuse korrigeeriva tegevuse rakendamine (RCCA)
Tarnehalduri abiga määratakse kohaletoimetamise kuupäev ja parandamist vajavad versioonid, misjärel algab parandustegevus.
Näiteks kui tugimeeskond pakub kasutajatele nende probleemile lahenduse, on see ajutine. RCCA juurutamine tagab püsiva paranduse, et defekti tulevikus ei tekiks.
5. Põhipõhjuste ennetava tegevuse rakendamine (RCPA)
RCPA tegeleb selliste sarnaste probleemide ennetamisega tulevikus uuendatud juhendi, meeskonna uuendatud hindamise kontrollnimekirja, täiustatud oskuste jms abil.
Algpõhjuste analüüsi eelised
RCA aitab selles
Viga vs defekt vs rike
Üldiselt on testimise algajad segaduses, millist terminit kasutada süsteemi/rakenduse kõrvalekalde või ootamatu väljundi kohta.
Nad nimetavad neid kõrvalekaldeid vigadeks, vigadeks, defektideks või tõrgeteks ja kasutavad neid termineid vaheldumisi, ilma et nad mõistaksid selgelt, mida need tähendavad.
Vaatame, kuidas vead, defektid ja tõrked üksteisest erinevad.
Tingimused
Esiteks käsitleme mõningaid erinevaid termineid, mida algajad testijad kasutavad.
Viga: Viga võib olla viga, arusaamatus või arendaja eksiarvamus. Arendajad võivad olla programmeerijad, tarkvarainsenerid , analüütikud ja testijad. Viga põhjustab programmi funktsionaalsuse muutumise. Näiteks võib juhtuda, et programmi kirjutamise ajal kasutatakse muutuja nime vääralt. See võib põhjustada silmuse või muu süntaktilise vea.
Defekt: See on punkt, kus rakendus või tarkvara erineb kliendi nõudmistest. See võib olla mis tahes probleem, mis on seotud süsteemi välise või sisemise käitumise ja funktsioonidega.
Viga: Testija leitud viga nimetatakse veaks. Kui tõrget ei käsitleta õigesti, võib see jõuda kliendini ja põhjustada programmi halva töö ja ootamatute tulemuste saavutamise. See võib põhjustada ka rakenduse krahhe.
Vale: Kui väljatöötatud tarkvara ei ole nõuete kohaselt rakendatud, siis öeldakse, et see on vale.
Lisa: See on tarkvara soovimatu või täpsustamata aspekt, mida kasutaja nõudes ei täpsustatud. Seda atribuuti võib kasutaja nõuda, kuid ei pruugi nõuda ja seetõttu peetakse seda defektiks.
Viga: Vead võivad põhjustada tõrkeid. See on programmi vale etapp, protsess või määratlus, mis põhjustab selle ebaõiget käitumist. Rike on anomaalia, mis põhjustab programmi ootamatu, ettenägematu või ettekavatsematu toimimise.
Puuduvad: Vastupidiselt lisale on puudumine defektide kategoriseerimine, kui tarkvara ei vasta kasutaja nõuetele. See juhtub siis, kui üht või mitut kasutaja vajadustest tulenevat spetsifikatsiooni ei rakendata.
Ebaõnnestumine: Kui mõni defekt jõuab lõpptarbijani, nimetatakse seda rikkeks. Seda määratletakse kui tarkvarasüsteemi või komponendi suutmatust toimida ettenähtud viisil, st kindlaksmääratud nõuete piires.
Sissejuhatus vea, defekti ja rikkesse
Keegi saab veast, defektist ja rikkest aru järgmise näite abil:
Kohalolekutarkvara loomisel unustab arendaja lisada poolepäevase funktsionaalsuse. See on viga või viga. See toob kaasa defekti või vea või vea tarkvaras, kuna see funktsioon on hädavajalik. Nüüd, kui see rakendus on välja töötatud ja kliendile tarnitud, märgitakse tarkvara puuduvaks, kui kellelgi organisatsioonis kulub pool päeva. Seega ei suuda süsteem teha seda, mida ta pidi tegema, ja see põhjustab tõrke.
Viga
Eksimine on inimlik.
Viga on inimlik viga, mille on põhjustanud arendaja eksimus, arusaamatus või väärarusaam.
Üksik viga võib põhjustada tarkvaras mitmeid defekte.
Selle põhjuseks võib olla:
Vigade tüübid
Vigade põhjused
Mõned võimalikud põhjused, miks tarkvaratootes tõrked ilmnevad, on järgmised:
Viga vs defekt vs rike
| Viga | Defekt | Ebaõnnestumine |
| See on viga. | Viga põhjustab defekti. | Defekt viib ebaõnnestumiseni. |
| Inimtegevus annab ootamatuid tulemusi. | Tootel või tarkvaral on konkreetne puudus, mille tõttu see ei vasta nõutavatele spetsifikatsioonidele. | Komponent või süsteem ei suuda eelmääratletud kriteeriumide raames nõutavaid tegevusi sooritada. |
| Kõik vead ei too kaasa defekte. Näiteks lihtsat grammatilist viga ei peeta veaks. | Kõik vead ei too kaasa tõrkeid. Näiteks võib konkreetne funktsioon nõuda teatud eeltingimusi, kuid need ei ole vajalikud ega põhjusta seega tõrkeid. | Kõik vead ei ole kriitilised. Näiteks võib klient vajada tarkvara kasutamise ajal süsteemi versiooni täiustamist, kuna kliendi versioon on aegunud. |
Lõpusõnad
Ühe ebakõla ilmnemine või esinemine toob kaasa muid probleeme ja seega on see kõik omavahel seotud.
Vead tulenevad inimlikest eksimustest, mis toovad kaasa nõuetest kõrvalekaldumise ja vead.
Defekt võib olla kriitiline või mitte ja seega ei tähenda see tingimata viga koodis.
See võib olla ka nõuetes määratletud rakendamata funktsioon.
Seega kontrollige hoolikalt, enne kui otsustate, et kood on ekslik.
Defekti aruanne
Veaaruanne või veaaruanne on dokument, mis tuvastab ja kirjeldab testija poolt tuvastatud defekti. Defekti aruannet saab kasutada sarnaste defektide tuvastamiseks tulevikus, et neid vältida.
Tarkvara testimise defekti määratlemine
Viga või defekt on kodeerimisvea tulemus või tagajärg, mis ei vasta tegelikele nõuetele.
Kui testijad viivad läbi testjuhtumite testimist, on defektiks rakenduse varieerumine või kõrvalekalle lõppkasutaja nõuetest, mis põhjustab valesid või ootamatuid tulemusi.
Probleeme, vigu, probleeme või intsidente nimetatakse tavaliselt tarkvara testimise defektide nimedeks.
Määratlege defektiaruanne
Dokumentatsiooni, mis määrab defekti esinemise, oleku ja olemuse läbipaistvalt, et arendajad saaksid seda hõlpsasti kopeerida ja parandada, nimetatakse defektiaruandeks.
Dokument sisaldab üksikasju defekti kohta, nagu selle kirjeldus, selle leidnud testija nimi, defekti avastamise kuupäev, selle parandanud arendaja ja palju muud.
Defekti aruande mall
Defektide aruannete mall võib tööriistati erineda. Üldine defektiaruande mall on aga järgmine:
| ID | Automaatne või käsitsi unikaalne identifikaator defekti tuvastamiseks |
| Projekt | Projekti nimi |
| Toode | Toote nimi |
| Väljalaske versioon | Toote väljalaske versioon |
| Moodul | Moodul, kus defekt tuvastati. |
| Tuvastatud järgu versioon | Toote ehitusversioon, milles defekt tuvastati. |
| Kokkuvõte | Selge ja sisutihe kokkuvõte leitud defektist. |
| Kirjeldus | Lihtne ja põhjalik defekti kirjeldus. Ärge kasutage midagi korduvalt ega kasutage keerulisi sõnu. |
| Paljundamise sammud | Samm-sammult kirjeldus defektide taasesitamiseks mitme sammuga. |
| Tegelikud tulemused | Tegelikud tulemused saadi pärast sammude järgimist. |
| oodatud tulemused | Need tulemused loodeti saada pärast sammude järgimist. |
| Manused | Lisateave, nagu ekraanipildid ja logid. |
| Märkused | Lisakommentaarid seoses defektiga. |
| Defekti tõenäosus | Defekti tõenäosus. |
| Defekti raskusaste | Defekti raskusaste. |
| Teatanud | Isiku nimi, kes puudusest teatas. |
| Määratud | Isiku nimi, kellele defekt on analüüsimiseks või parandamiseks määratud. |
| Olek | Defekti olek |
| Fikseeritud järgu versioon | Pärast defekti parandamist koostage toote versioon. |
Defektide haldamise protsess
Süstemaatilist vigade tuvastamise ja parandamise protsessi nimetatakse defektide haldamise protsessiks.
Defektide haldamise tsüklis on järgmised kuus etappi:
1. Avastus
See etapp hõlmab testijate poolt võimalikult paljude defektide väljaselgitamist enne, kui lõppkasutaja need avastab.
Kui arendajad on defekti tunnistanud ja aktsepteerinud, võib seda nimetada avastatuks.
2. Kategoriseerimine
Kategoriseerimine viitab erinevate defektide jagamisele nende prioriteedi järgi, et arendajad saaksid neid vastavalt parandada.
Kategooriaid on neli:
3. Resolutsioon
Tarkvara testimisel on defektide parandamine või defektide lahendamine üldiselt neljaastmeline protsess, mis aitab defekte hõlpsalt parandada ja jälgida.
Alustades defektide määramisest arendajatele, millele järgneb defektide parandamise ajakava, mille järel defektid parandatakse, lõpeb protsess, kui testihaldurile saadetakse lahenduse aruanne.
4. Kontrollimine
Testimismeeskond kontrollib, kas arendusmeeskonna poolt parandatud vead on lahendatud või mitte.
5. Sulgemine
Pärast edukat lahendamist ja defekti kontrollimist muudetakse defekti olekuks suletud. Kui seda ei juhtu, kontrollivad testijad defekti uuesti.
6. Aruandlus
Juhatus peaks mõistma defektide kõrvaldamise protsessi ja omama õigust teada puuduse staatust.
Testijuht koostab vearaporti ja saadab selle juhtkonnale tagasiside andmiseks. Juhtkond kontrollib defektide kõrvaldamise protsessi ja saadab vajadusel oma tagasisidet või tuge.
Defektidest teatamine viib parema suhtlemiseni ja defektide jälgimiseni.
Vajadus defektide haldamise protsessi järele
Konkreetse defektihaldusprotsessi nõuet saab paremini mõista järgmise näite abil:
Oletame, et testitakse tegumihalduri rakendust.
Testimise ajal leidis testimismeeskond mõned vead, näiteks 80, ja neist teavitati testihaldurit.
Testijuht teavitab defektidest arendusmeeskonda, kes reageerivad nädala pärast 70 parandatud defektiga.
Testijuht saadab selle teabe testimismeeskonnale.
Testimismeeskond vastas nädal hiljem, öeldes, et 70 defekti parandati, kuid tekkis 20 uut.
Nüüd võib kogu see protsess ainult verbaalse suhtluse tõttu olla veidi keeruline. Defektide jälgimine ja parandamine on keeruline.
Seega on vaja defektide haldamise protsessi.
Tõhus defektidest teatamine
Defekti aruanded tuleb koostada tõhusalt.
See aitab säästa aega ja tarbetut pingutust defekti mõistmisel ja taasesitamisel.
Kasulike veaaruannete tagamiseks võib järgida järgmisi meetmeid.
1. Mängi:
Kui defekt on avastanud, korrake seda kindluse mõttes veel kord. Kui replikatsioon pole võimalik, tuletage meelde täpsed testitingimused, mis defekti põhjustasid, ja proovige uuesti. Kui aga defekt ikka ei ilmne, saatke üksikasjalikud veaaruanded ja kõik katsetulemused edasiseks uurimiseks.
2. Olge konkreetne:
Iga defektiaruannete toiming peaks olema konkreetne.
Näiteks selle asemel, et öelda Logi sisse, peaks olema (1) Minge avalehele, (2) klõpsake nuppu sisselogimine, (3) sisestage kasutajatunnus ja parool ning (4) klõpsake nuppu Logi sisse.
Kui näiteks teid on mitu, mainige täpset rada, mida järgisite, ja viige defekti.
Hoiduge selliste ebamääraste asesõnade kasutamisest ja täpsustage, mida see tähistab.
3. Eesmärk:
Selle asemel, et kasutada selliseid subjektiivseid väiteid nagu Lousy rakendus, vältige emotsioone ja öelge objektiivselt jah või ei või Aktsepteeritud või Tagasilükatud.
4. Ülevaatus:
Pärast kirjutise kirjutamist esitage see alles pärast selle ülevaatamist ja kirjavigade eemaldamist.
5. Detailidele orienteeritud:
Esitage teavet üksikasjalikult. Arendajatel ei tohiks olla teabepuudust.
Defekti mõõdikud
Defekti mõõdikuid kasutatakse testi täitmise kvaliteedi mõõtmiseks. On kaks parameetrit:
Defektide tagasilükkamise suhe (DRR) = (tagasi lükatud defektide arv / tõstatatud defektide koguarv) * 100
Defektide lekkemäär (DLR) = (vastamata defektide arv / tarkvara defektide koguarv) * 100
Kui DRR ja DLR väärtused on väikesed, on testi täitmise kvaliteet parem. Testihaldur määratleb nende väärtuste aktsepteeritud vahemikud.
Neid suhteid saab vähendada
Meeskonnaliikmete testimisoskuste parandamine.
Kulutage rohkem aega testi läbiviimiseks ja tulemuste ülevaatamiseks.
Oletame näiteks, et tegumihalduri projektil on 80 defekti, kuid testimismeeskond suudab tuvastada vaid 60. Nendest lükkas arendusmeeskond tagasi 10 defekti. Seega jäi puudu 20 defekti.
Seega on DRR-i suhe järgmine:
(10/60) * 100 = 16,66%
Ja DLR-i suhe on:
(20/80) * 100 = 25%
Defekti KKK
Mis on defekti näide?
Tarkvaravea näide võib olla kasutajaliidese grammatikaviga või programmi kodeerimisvead.
Mis on teine sõna defekti jaoks?
Tarkvara testimisel võib defekti nimetada veaks, veaks, veaks ja paljuks muuks.
Mis on defektide parandamine?
Defekt loetakse parandatuks, kui selle olek on märgitud suletuks. Defekti olek muudetakse suletud olekuks, kui see on piisavalt kontrollitud või seda hoitakse järgmistes versioonides parandamiseks.
Mis on defekti elutsükkel?
Defekti elutsükkel või vea elutsükkel on teekond defekti tuvastamisest parandamiseni. Oma elutsükli jooksul muutub defekt tuvastamisest aktiivseks määramisest testimiseks, kontrollimiseks ja suletuks. Defekt võib minna ka tagasilükatud või edasilükatud olekusse või uuesti avatud olekusse. Need olekud on organisatsiooniti erinevad, olenevalt testimiseks kasutatavast tööriistast.
Kuidas kontrollite defekte?
Defekte saab vähendada järgmistel viisidel:
1. Tõhus defektide analüüsi teostamine
2. Tarkvaranõuete põhjalik analüüsimine
3. Vigade jälgimise tarkvara kasutamine
4. Agressiivne regressioonitest
5. Sage koodide ümbertöötamine.