Alvorlighetsgrad & Prioritet i testing: Forskjeller & Eksempel

Innholdsfortegnelse:

Anonim

Feil alvorlighetsgrad

Feil alvorlighetsgrad eller mangel Alvorlighetsgrad ved testing er en grad av innvirkning en feil eller en feil har på programvaren som testes. En høyere effekt av feil / mangel på systemfunksjonalitet vil føre til høyere alvorlighetsgrad. En kvalitetssikringsingeniør bestemmer vanligvis alvorlighetsgraden til en feil / mangel.

Hva er prioritet?

Prioritet er definert som rekkefølgen som en feil skal rettes i. Jo høyere prioritet jo raskere skal mangelen løses.

Mangler som lar programvaresystemet være ubrukelig, prioriteres høyere enn mangler som fører til at en liten funksjonalitet i programvaren mislykkes.

HOVEDFORSKJELL

  • Prioritet er rekkefølgen utvikleren skal løse en feil mens alvorlighetsgraden er graden av innvirkning som en mangel har på driften av produktet.
  • Prioritet er kategorisert i tre typer: lav, middels og høy mens alvorlighetsgrad er kategorisert i fem typer: kritisk. dur, moderat, mindre og kosmetisk.
  • Prioritet er knyttet til planlegging mens alvorlighetsgrad er assosiert med funksjonalitet eller standarder.
  • Prioritet indikerer hvor snart feilen skal rettes, mens alvorlighetsgrad indikerer alvorlighetsgraden av feilen på produktets funksjonalitet.
  • Prioritet for mangler avgjøres i samråd med leder / klient, mens alvorlighetsgraden av manglene bestemmes av kvalitetsingeniøren.
  • Prioritet er drevet av forretningsverdi mens Severity er drevet av funksjonalitet.
  • Prioritetsverdien er subjektiv og kan endres over en periode avhengig av endringen i prosjektsituasjonen, mens alvorlighetsverdien er objektiv og mindre sannsynlig å endre seg.
  • Høy prioritet og lav alvorlighetsstatus indikerer at feil må løses på umiddelbare baser, men påvirker ikke applikasjonen, mens status med høy alvorlighet og lav prioritet indikerer at feil må løses, men ikke på umiddelbar basis.
  • Prioritetsstatus er basert på kundekrav, mens alvorlighetsstatus er basert på produktets tekniske aspekt.

Typer alvorlighetsgrad

I programvaretesting kan typer alvorlighetsgrad av feil / feil defineres i fire deler:

  • Kritisk : Denne feilen indikerer fullstendig nedleggelse av prosessen, ingenting kan gå videre
  • Major : Det er en svært alvorlig feil og kollapser systemet. Visse deler av systemet forblir imidlertid funksjonelt
  • Medium : Det forårsaker uønsket oppførsel, men systemet er fortsatt funksjonelt
  • Lav : Det vil ikke føre til større sammenbrudd i systemet

Prioritetstyper

Typer av prioritering av feil / mangel kan kategoriseres i tre deler:

  • Lav: Defekten er irriterende, men reparasjon kan utføres når den mer alvorlige feilen er løst
  • Middels: I løpet av det normale løpet av utviklingsaktivitetene bør mangelen løses. Det kan vente til en ny versjon er opprettet
  • Høy: Feilen må løses så snart som mulig, da den påvirker systemet alvorlig og ikke kan brukes før den er løst

Tips for å bestemme alvorlighetsgraden av en feil

  • Bestem hyppigheten av forekomst: I noen tilfeller, hvis forekomsten av en mindre defekt er hyppig i koden, kan den være mer alvorlig. Så fra en brukers perspektiv er det mer alvorlig selv om det er en mindre mangel.
  • Isoler feilen: Å isolere feilen kan bidra til å finne ut hvor alvorlig det er.

Prioritet vs alvorlighetsgrad: nøkkelforskjell

Prioritet Alvorlighetsgrad
  • Defektprioritet har definert rekkefølgen utvikleren skal løse en feil i
  • Defekt alvorlighetsgrad er definert som graden av innvirkning som en feil har på driften av produktet
  • Prioritet er kategorisert i tre typer
    • Lav
    • Medium
    • Høy
  • Alvorlighetsgrad er kategorisert i fem typer
    • Kritisk
    • Major
    • Moderat
    • Liten
    • Kosmetisk
  • Prioritet er knyttet til planlegging
  • Alvorlighetsgrad er assosiert med funksjonalitet eller standarder
  • Prioritet indikerer hvor snart feilen skal løses
  • Alvorlighetsgrad indikerer alvorlighetsgraden av feilen på produktets funksjonalitet
  • Prioritet for mangler avgjøres i samråd med leder / klient
  • QA-ingeniør bestemmer alvorlighetsgraden av feilen
  • Prioritet er drevet av forretningsverdi
  • Alvorlighetsgraden er drevet av funksjonalitet
  • Verdien er subjektiv og kan endres over en periode avhengig av endringen i prosjektsituasjonen
  • Verdien er objektiv og mindre sannsynlig å endre seg
  • Høy prioritet og lav alvorlighetsstatus indikerer at feil må rettes på umiddelbare baser, men påvirker ikke applikasjonen
  • Høy alvorlighetsgrad og lav prioritetsstatus indikerer at feil må løses, men ikke på umiddelbar basis
  • Prioritetsstatus er basert på kundens krav
  • Alvorlighetsstatus er basert på det tekniske aspektet ved produktet
  • Under UAT løser utviklingsteamet feil basert på prioritering
  • Under SIT vil utviklingsteamet fikse feil basert på alvorlighetsgraden og deretter prioriteten

Eksempel på alvorlighetsgrad og prioritet

La oss se et eksempel på lav alvorlighetsgrad og høy prioritet og omvendt

  • En veldig lav alvorlighetsgrad med høy prioritet: En logofeil for ethvert forsendelsesnettsted, kan være av lav alvorlighetsgrad, da det ikke vil påvirke funksjonaliteten til nettstedet, men kan ha høy prioritet, ettersom du ikke vil at ytterligere forsendelse skal fortsette med feil logo.
  • En veldig høy alvorlighetsgrad med lav prioritet: På samme måte som for flyoperasjonsnettsteder kan en feil i reservasjonsfunksjonaliteten være av høy alvorlighetsgrad, men kan ha lav prioritet ettersom den kan planlegges utgitt i neste syklus.

Defekt Triage

Defekt triage er en prosess som prøver å gjøre en balansering av prosessen der testteamet står overfor problemet med begrenset tilgjengelighet av ressurser. Så når det er et stort antall defekter og begrensede testere for å verifisere dem, hjelper defekt triage å prøve å få så mange feil løst basert på defektparametere som alvorlighetsgrad og prioritet.

Hvordan bestemme Defekt Triage:

De fleste systemer bruker prioritet som hovedkriterium for å vurdere mangelen. Imidlertid vurderer en god triage-prosess også alvorlighetsgraden.

Triageprosessen inkluderer følgende trinn

  • Gjennomgang av alle feilene inkludert avviste feil fra teamet
  • Første vurdering av manglene er basert på innholdet og respektive prioritets- og alvorlighetsinnstillinger
  • Prioritering av feilen basert på inngangene
  • Tilordne feilen til korrekt utgivelse av produktsjef
  • Omdirigerer feilen til riktig eier / team for videre handling

Retningslinjer som hver tester bør vurdere før du velger en alvorlighetsgrad

Alvorlighetsparameteren blir vurdert av testeren, mens prioritetsparameteren blir vurdert av produktsjefen eller av triage-teamet. For å prioritere feilen er det viktig at en tester velger riktig alvorlighetsgrad for å unngå forvirring med utviklingsteamet.

  • Forstå begrepet prioritet og alvorlighetsgrad
  • Tildel alltid alvorlighetsgraden basert på problemtypen, da dette vil påvirke prioriteten
  • Forstå hvordan et bestemt scenario eller Test Case vil påvirke sluttbrukeren
  • Må vurdere hvor lang tid det vil ta å fikse feilen basert på dens kompleksitet og tid til å bekrefte feilen

Konklusjon:

  • I programvareteknikk kan tildeling av feil alvorlighetsgrad til mangler forsinke STLC-prosessen, og det kan ha en drastisk betydning for teamets samlede ytelse. Så den ansvarlige personen må være presis og nøyaktig i sin oppfordring til å tildele feil.