Hva er Bug?
En feil er konsekvensen / utfallet av en kodefeil.
Feil ved programvaretesting
En mangel ved programvaretesting er en variasjon eller avvik fra programvaren fra sluttbrukerens krav eller opprinnelige forretningskrav. En programvarefeil er en feil i kodingen som forårsaker feil eller uventede resultater fra et program som ikke oppfyller faktiske krav. Testere kan komme over slike feil mens de utfører testsakene.
Disse to begrepene har en veldig tynn skillelinje. I bransjen er begge feil som må løses, og så utvekslingsbalanse brukes av noen av testteamene.
Når testere utfører testtilfellene, kan de komme over slike testresultater som er i strid med forventede resultater. Denne variasjonen i testresultater blir referert til som en programvaredefekt. Disse feilene eller variasjonene er referert til med forskjellige navn i forskjellige organisasjoner, for eksempel problemer, problemer, feil eller hendelser.
I denne veiledningen vil du lære-
- Feilrapport
- Process for defekthåndtering
- Oppdagelse
- Kategorisering
- Vedtak
- Bekreftelse
- Lukking
- Rapportering
- Viktige feilmålinger
Feilrapport i programvaretesting
En feilrapport i programvaretesting er et detaljert dokument om feil som finnes i programvaren. Feilrapport inneholder hver detalj om feil som beskrivelse, dato da feil ble funnet, navnet på testeren som fant den, navnet på utvikleren som fikste den osv. Feilrapporten hjelper til med å identifisere lignende feil i fremtiden, slik at den kan unngås.
Mens du rapporterer feilen til utvikleren, bør feilrapporten din inneholde følgende informasjon
- Defect_ID - Unikt identifikasjonsnummer for feilen.
- Defektbeskrivelse - Detaljert beskrivelse av feilen, inkludert informasjon om modulen der feil ble funnet.
- Versjon - Versjon av applikasjonen der feil ble funnet.
- Trinn - Detaljerte trinn sammen med skjermbilder som utvikleren kan reprodusere feilene med.
- Dato hevet - Dato da mangelen oppheves
- Referanse - hvor i deg Gi referanse til dokumentene som. krav, design, arkitektur eller kanskje til og med skjermbilder av feilen for å forstå feilen
- Oppdaget av - Navn / ID på testeren som reiste feilen
- Status - Status for feilen, mer om dette senere
- Fikset av - Navn / ID på utvikleren som fikset det
- Dato stengt - Dato da mangelen er lukket
- Alvorlighetsgrad som beskriver feilens innvirkning på applikasjonen
- Prioritet som er relatert til presserende hastighet. Alvorlighetsprioritet kan være høy / middels / lav basert på hvor presserende det er hvor mangelen skal løses
Klikk her hvis videoen ikke er tilgjengelig
Ressurser
Last ned et eksempel på mal for rapporteringsfeil
Tenk på følgende som testleder
Teamet ditt fant feil mens du testet Guru99 Banking-prosjektet.
Etter en uke svarer utvikleren -
I neste uke reagerer testeren
Som i det ovennevnte tilfellet, hvis feilkommunikasjonen skjer muntlig, blir ting snart veldig kompliserte. For å kontrollere og effektivt håndtere bugs trenger du en defekt livssyklus.
Hva er feilbehandlingsprosess?
Defect Management er en systematisk prosess for å identifisere og fikse feil. En defektstyringssyklus inneholder følgende trinn 1) Discovery of Defect, 2) Defect Categorization 3) Fixing of Defect by developers 4) Verification by Testers, 5) Defect Closure 6) Defect Reports at the end of project
Dette emnet vil veilede deg om hvordan du bruker prosessen for mangelforvaltning på prosjektet Guru99 Bank. Du kan følge trinnene nedenfor for å håndtere feil.
Oppdagelse
I oppdagelsesfasen må prosjektgruppene oppdage så mange mangler som mulig, før sluttkunden kan oppdage det. En mangel sies å være oppdaget og endre til status akseptert når den blir 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å Guru99 Banks nettsted. De anser dem som mangler og rapportert til utviklingsteamet, men det er en konflikt -
I så fall, som testleder, hva vil du gjøre?
A) Enig med testteamet at det er en mangel
B) Testleder tar rollen som dommer for å avgjøre om problemet er feil eller ikke
C) Enig med utviklingsteamet som ikke er en feil Korrekt feil
I slike tilfeller bør en løsningsprosess brukes for å løse konflikten. Du tar rollen som dommer for å avgjøre om nettstedsproblemet er en mangel eller ikke.
Kategorisering
Defektkategorisering hjelper programvareutviklerne med å prioritere oppgavene sine. Det betyr at denne typen prioritet hjelper utviklerne med å fikse de manglene først som er svært avgjørende.
Feil kategoriseres vanligvis av Test Manager -
La oss gjøre en liten øvelse som følger Dra og slipp defektprioriteten nedenfor
- Kritisk
- Høy
- Medium
- Lav
| 1) Nettstedsytelsen er for treg |
|
| 2) Innloggingsfunksjonen til nettstedet fungerer ikke som den skal |
|
| 3) GUI for nettstedet vises ikke riktig på mobile enheter |
|
| 4) Nettstedet kunne ikke huske brukerinnloggingsøkten |
|
| 5) Noen lenker fungerer ikke |
|
Her er de anbefalte svarene
| Nei. | Beskrivelse | Prioritet | Forklaring |
|---|---|---|---|
| 1 | Nettstedsytelsen er for treg | Høy | Ytelsesfeilen kan forårsake store ulemper for brukeren. |
| 2 | Innloggingsfunksjonen til nettstedet fungerer ikke som den skal | Kritisk | Pålogging er en av hovedfunksjonene til banknettstedet hvis denne funksjonen ikke fungerer, er det alvorlige feil |
| 3 | GUI på nettstedet vises ikke riktig på mobile enheter | Medium | Mangelen påvirker brukeren som bruker Smartphone for å se nettstedet. |
| 4 | Nettstedet kunne ikke huske brukerinnloggingsøkten | Høy | Dette er et alvorlig problem siden brukeren vil være i stand til å logge på, men ikke være i stand til å utføre ytterligere transaksjoner |
| 5 | Noen lenker fungerer ikke | Lav | Dette er en enkel løsning for utviklingsgutta, og brukeren kan fortsatt få tilgang til nettstedet uten disse koblingene |
Feiloppløsning
Defektløsning i programvaretesting er en trinnvis prosess for å fikse feilene. Prosessen med mangeloppløsning starter med å tilordne mangler til utviklere, deretter planlegger utviklere feilen som skal løses i henhold til prioritet, så blir mangler løst, og til slutt sender utviklere en rapport om løsning til testansvarlig. Denne prosessen hjelper deg med å løse og spore feil enkelt.
Du kan følge følgende trinn for å fikse feilen.
- Oppgave : Tilordnet en utvikler eller annen tekniker for å fikse, og endret status til Svar .
- Tidsplanfiksing : Utviklersiden tar ansvar i denne fasen. De vil lage en tidsplan for å fikse disse feilene, avhengig av feilprioriteten.
- Løs feilen : Mens utviklingsteamet løser feilene, sporer Test Manager prosessen med å fikse feil sammenlignet med planen ovenfor.
- Rapporter oppløsningen : Få en rapport om oppløsningen fra utviklere når feil er løst.
Bekreftelse
Etter at utviklingsteamet har løst og rapportert feilen, verifiserer testteamet at manglene faktisk er løst.
For eksempel, i scenarioet ovenfor, da utviklingsteamet rapporterte at de allerede løste 61 feil, ville teamet ditt teste igjen for å bekrefte at disse feilene faktisk var løst eller ikke.
Lukking
Når en mangel er løst og bekreftet, endres mangelen som lukket . Hvis ikke, har du sendt en melding til utviklingen for å sjekke feilen igjen.
Feilrapportering
Defektrapportering i programvaretesting er en prosess der testledere forbereder og sender manglerapporten til ledergruppen for tilbakemelding på prosessen med mangler og mangler. Deretter sjekker ledergruppen feilrapporten og sender tilbakemelding eller gir ytterligere støtte om nødvendig. Feilrapportering hjelper deg med å bedre kommunisere, spore og forklare mangler i detalj.
Styret har rett til å kjenne feilstatusen. De må forstå prosessen for mangelforvaltning for å støtte deg i dette prosjektet. Derfor må du rapportere dem om den aktuelle mangelsituasjonen for å få tilbakemelding fra dem.
Viktige feilmålinger
Tilbake ovennevnte scenario. Utvikleren og testteamene har gjennomgått rapporterte mangler. Her er resultatet av den diskusjonen
Hvordan måle og evaluere kvaliteten på utførelsen av testen?
Dette er et spørsmål som hver testansvarlig vil vite. Det er to parametere som du kan vurdere som følger
I scenariet ovenfor kan du beregne at avvisningsforkastelsesforholdet (DRR) er 20/84 = 0,238 (23,8%).
Et annet eksempel antas at Guru99 Bank-nettstedet har totalt 64 feil, men testteamet ditt oppdager bare 44 feil, det vil si at de savnet 20 feil. Derfor kan du beregne defektlekkasje-forholdet (DLR) er 20/64 = 0,312 (31,2%).
Konklusjon, kvaliteten på testutførelsen blir evaluert ved å følge to parametere
Jo mindre verdi DRR og DLR har, jo bedre kvalitet er testutførelsen. Hva er forholdsområdet som er akseptabelt ? Dette området kan defineres og aksepteres i prosjektmålet, eller du kan referere beregningene 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 testferdighetene til medlemmet.
- Bruk mer tid på testutførelse, spesielt til å gjennomgå resultatene av testutførelsen.