Forskjellen mellom alvorlighetsgrad og prioritet i testing (eksempel)

Alvorlighet vs. Prioritet: Forskjellen mellom dem

• Prioritet er rekkefølgen som utvikleren skal løse en defekt, mens alvorlighetsgrad er graden av innvirkning en defekt har på driften av produktet.
• Prioritet er kategorisert i tre typer: lav, middels og høy, mens alvorlighetsgrad er kategorisert i fem typer: kritisk, stor, moderat, liten og kosmetisk.
• Prioritet er assosiert med planlegging mens alvorlighetsgrad er assosiert med funksjonalitet eller standarder.
• Prioritet angir hvor snart feilen skal rettes, mens alvorlighetsgrad angir alvorlighetsgraden av defekten på produktfunksjonaliteten.
• Prioritet av defekter bestemmes i samråd med leder/klient, mens alvorlighetsgraden av defektene bestemmes av QA-ingeniøren.
• Prioritet er drevet av forretningsverdi mens alvorlighetsgrad er drevet av funksjonalitet.
• Prioritetsverdi 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 defekter må fikses på umiddelbar basis, men påvirker ikke applikasjonen, mens høy alvorlighetsgrad og lav prioritetsstatus indikerer at defekter må fikses, men ikke på umiddelbar basis.
• Prioritetsstatus er basert på kundekrav, mens alvorlighetsgrad er basert på det tekniske aspektet ved produktet.

Hva er Bug Alvorlighetsgrad

Feilens alvorlighetsgrad eller Defekt Alvorlighet i testing er en grad av påvirkning en feil eller en Defekt har på programvareapplikasjonen som testes. En høyere effekt av feil/defekt på systemfunksjonalitet vil føre til et høyere alvorlighetsnivå. EN Kvalitetssikring: ingeniør bestemmer vanligvis alvorlighetsgraden til en feil/defekt.

Hva er prioritet?

Prioritet er definert som rekkefølgen en mangel skal rettes i. Jo høyere prioritet jo raskere feilen bør løses.

Defekter som gjør programvaresystemet ubrukelig gis høyere prioritet fremfor defekter som gjør at en liten funksjonalitet i programvaren svikter.

Typer av alvorlighetsgrad

In Testing av programvare, Typer av alvorlighetsgrad av feil/defekt kan kategoriseres i følgende deler:

• Kritisk: Denne defekten indikerer fullstendig avslutning av prosessen, ingenting kan gå videre
• Major: Det er en svært alvorlig defekt og kollapser systemet. Imidlertid forblir visse deler av systemet funksjonelle
• Medium: Det forårsaker uønsket oppførsel, men systemet er fortsatt funksjonelt
• Lav: Det vil ikke forårsake noen større sammenbrudd i systemet

Prioriterte typer

Typer av prioritet for feil/defekt kan kategoriseres i tre deler:

• Lav: Defekten er irriterende, men reparasjon kan gjøres når den mer alvorlige defekten er rettet
• Medium: I løpet av det normale løpet av utviklingsaktivitetene bør feilen løses. Den 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 fikset

Tips for å fastslå alvorlighetsgraden av en defekt

• Bestem hyppigheten av forekomsten: 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 defekt.
• Isoler defekten: Å isolere defekten kan bidra til å finne ut hvor alvorlig konsekvensen er.

Forskjellen mellom alvorlighetsgrad og prioritet i testing

Eksempel på defektens alvorlighetsgrad og prioritet

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

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

Defekt Triage

Defekttriage er en prosess som prøver å gjøre rebalansering 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 defekttriage å prøve å få så mange defekter løst basert på defektparametere som alvorlighetsgrad og prioritet.

Slik bestemmer du defekttriage:

De fleste systemer bruker prioritet som hovedkriteriet for å vurdere defekten. En god triageprosess tar imidlertid også hensyn til alvorlighetsgraden.

Triage-prosessen inkluderer følgende trinn

• Revdvs. alle defektene inkludert avviste defekter av teamet
• Innledende vurdering av defektene er basert på innholdet og de respektive prioritets- og alvorlighetsinnstillingene
• Prioritering av defekten basert på inngangene
• Tilordne defekten til korrekt utgivelse av produktsjef
• Omdirigerer defekten til riktig eier/team for videre tiltak

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

Alvorlighetsparameteren vurderes av testeren, mens prioritetsparameteren vurderes av produktsjefen eller av triage-teamet. For å prioritere defekten er det avgjørende for en tester å velge riktig alvorlighetsgrad for å unngå forvirring med utviklingsteamet.

• Forstå begrepet prioritet og alvorlighetsgrad godt
• Tilordne alltid alvorlighetsgraden basert på problemtypen, da dette vil påvirke prioriteringen
• Forstå hvordan et bestemt scenario eller Testsak vil påvirke sluttbrukeren
• Må vurdere hvor lang tid det vil ta å fikse defekten basert på kompleksiteten og tiden det tar å verifisere defekten

Konklusjon

In Engineering programvare, Å tildele feil alvorlighetsgrad til defekt kan forsinke STLC prosess og kan ha noen drastiske implikasjoner på den generelle ytelsen til teamet. Så den ansvarlige personen må være presis og nøyaktig i oppfordringen om å tildele defekter.