Defekthåndteringsprosess i programvaretesting

Hva er defekthåndteringsprosess?

Defekthåndtering er en systematisk prosess for å identifisere og fikse feil. En defektbehandlingssyklus inneholder følgende trinn: 1) Oppdagelse av defekt, 2) Defektkategorisering 3) Utbedring av defekter av utviklere 4) Verifisering av testere, 5) Feillukking 6) Defektrapporter ved slutten av prosjektet

Dette emnet vil veilede deg om hvordan du bruker defekthåndteringsprosessen på prosjektet Guru99 Bank-nettstedet. Du kan følge trinnene nedenfor for å håndtere defekter.

Trinn 1) Oppdagelse

I oppdagelsesfasen må prosjektgruppene oppdage som mange defekter som mulig, før sluttkunden kan oppdage det. En defekt sies å bli oppdaget og endret til status akseptert når det er anerkjent og akseptert av utviklerne

I scenariet ovenfor oppdaget testerne 84 feil på nettstedet Guru99.

La oss ta en titt på følgende scenario; testteamet ditt oppdaget noen problemer på nettstedet til Guru99 Bank. De anser dem som mangler og rapporteres til utviklingsteamet, men det er en konflikt –

I slike tilfeller bør en løsningsprosess brukes for å løse konflikten, du tar rollen som dommer for å avgjøre om nettstedets problem er en defekt eller ikke.

Trinn 2) Kategorisering

Defektkategorisering hjelper programvareutviklerne til å prioritere oppgavene sine. Det betyr at denne typen prioritering hjelper utviklerne med å fikse de feilene først som er svært avgjørende.

Defekter kategoriseres vanligvis av testlederen –

La oss gjøre en liten øvelse som følger

Her er de anbefalte svarene

Trinn 3) Feilløsning

Defektløsning i programvaretesting er en trinnvis prosess for å fikse feilene. Feilløsningsprosessen starter med å tildele defekter til utviklere, deretter planlegger utviklere at defekten skal rettes etter prioritet, deretter blir feilene fikset og til slutt sender utviklere en rapport om løsning til testlederen. Denne prosessen hjelper til med å fikse og spore defekter enkelt.

Du kan følge trinnene nedenfor for å fikse feilen.

• Oppdrag: Tildelt en utvikler eller annen tekniker for å fikse, og endret status til svare.
• Planfesting: Utbyggersiden tar ansvar i denne fasen. De vil lage en tidsplan for å fikse disse manglene, avhengig av defektprioriteten.
• Rett opp feilen: Mens utviklingsteamet fikser defektene, sporer testlederen prosessen med å fikse defekter sammenlignet med planen ovenfor.
• Rapporter vedtaket: Få en rapport om oppløsningen fra utviklere når feil er fikset.

Trinn 4) Verifisering

Etter utviklingsteamet fikset og rapportert defekten, testteamet bekrefter at manglene faktisk er løst.

For eksempel, i scenariet ovenfor, når utviklingsteamet rapporterte at de allerede fikset 61 defekter, ville teamet ditt teste igjen for å bekrefte at disse feilene faktisk var rettet eller ikke.

Trinn 5) Lukking

Når en defekt er løst og verifisert, endres defekten status som stengt. Hvis ikke, må du sende en melding til utviklingen for å sjekke feilen på nytt.

Trinn 6) Feilrapportering

Feilrapportering i programvaretesting er en prosess der testledere forbereder og sender feilrapporten til ledergruppen for tilbakemelding om feilhåndteringsprosessen og defekters status. Deretter kontrollerer ledergruppen mangelrapporten og sender tilbakemelding eller gir ytterligere støtte ved behov. Feilrapportering bidrar til å bedre kommunisere, spore og forklare mangler i detalj.

Styret har rett til å få kjennskap til mangelstatusen. De må forstå feilhåndteringsprosessen for å støtte deg i dette prosjektet. Derfor må du rapportere dem om gjeldende mangelsituasjon for å få tilbakemelding fra dem.

Hvorfor trenger du Defect Management Process?

Teamet ditt fant feil mens de testet Guru99 Banking-prosjektet.

Etter en uke svarer utvikleren -

I neste uke svarer testeren

Som i tilfellet ovenfor, hvis feilkommunikasjonen gjøres verbalt, blir ting snart veldig komplisert. For å kontrollere og effektivt håndtere feil trenger du en defekt livssyklus.

Viktige feilmålinger

Tilbake til scenariet ovenfor. Utvikleren og testteamene har gjennomgått de rapporterte defektene. Her er resultatet av den diskusjonen

Hvordan måle og evaluere kvaliteten på testutførelsen?

Dette er et spørsmål som hver Testleder ønsker å vite. Det er 2 parametere som du kan vurdere som følger

I scenariet ovenfor kan du beregne avvisningsforholdet (DRR) er 20/84 = 0.238 (23.8 %).

Et annet eksempel, antatt at Guru99 Bank-nettstedet har totalt 64 defekter, men testteamet ditt oppdager bare 44 defekter dvs. de bommet 20 defekter. Derfor kan du beregne defektlekkasjeforholdet (DLR) er 20/64 = 0.312 (31.2%).

Konklusjon, kvaliteten på testutførelsen blir evaluert via følgende to parametere

Jo mindre verdi av DRR og DLR er, desto bedre er kvaliteten på testutførelsen. Hva er forholdsområdet som er akseptabelt? Dette området kan være definert og akseptert som utgangspunkt i prosjektmålet, eller du kan referere til beregninger for lignende prosjekter.

I dette prosjektet er den anbefalte verdien av akseptabelt forhold 5 ~ 10 %. Det betyr at kvaliteten på testutførelsen er lav. Du bør finne mottiltak for å redusere disse forholdstallene som f.eks

• Forbedre testingsferdighetene til medlemmet.
• Bruk mer tid for testkjøring, spesielt for gjennomgang av testutførelsesresultatene.

Spørsmål og svar

Klikk her. hvis videoen ikke er tilgjengelig

Ressurser:

Last ned en eksempelmal for feilrapportering