Meny

Defekt alvorlighetsgrad og prioritet ved testing med eksempler og forskjeller

defect severity priority testing with examples

Prøv Instrumentet Vårt For Å Eliminere Problemer

I denne opplæringen lærer du hva som er Defekt alvorlighetsgrad og prioritet i testing, hvordan du setter defektprioritet og alvorlighetsnivåer med eksempler for å forstå konseptet tydelig.

Vi vil også dekke i detalj hvordan man klassifiserer manglene under forskjellige bøtter og deres relevans i Defect Life-syklusen. Vi vil også dekke den viktige rollen klassifiseringen har med et live sett med eksempler.

Arkiveringsfeil er veldig integrert del av programvaretestets livssyklus . Det er flere beste praksis definert for effektiv feilrapportering over internett eller i organisasjoner.

Defekt alvorlighetsgrad og prioritet

pl / sql intervju spørsmål og svar

Hva du vil lære:

Oversikt over mangelsporing

En av de viktige aspektene av Defect Life-syklusen på et generisk nivå inkluderer mangelsporing. Dette er viktig fordi testteamene åpner flere feil når de tester en programvare som bare multipliseres hvis det spesifikke systemet som testes er komplekst. I et slikt scenario kan det være en skremmende oppgave å håndtere disse feilene og analysere disse feilene for å få stengt.

I tråd med vedlikeholdsprosesser for mangler, når noen tester arkiverer en feil, bortsett fra metoden / beskrivelsen for å reprodusere problemet, må han også gi litt kategorisk informasjon som kan hjelpe unøyaktig klassifisering av feilen. Dette vil igjen hjelpe til med effektive sporing / vedlikeholdsprosesser for mangler og vil også danne grunnlaget for raskere leveringstid for mangler.

De to hovedparametrene som danner grunnlaget for effektiv feilsporing og løsning er:

  • Defektprioritet i testing
  • Defekt alvorlighetsgrad i testing

Dette er ofte et forvirrende konsept og brukes nesten om hverandre blant ikke bare testteam, men også utviklingsteam. Det er en fin linje mellom de to, og det er viktig å forstå at det faktisk er forskjeller mellom de to.

La oss forstå kort de teoretiske definisjonene av de to parametrene i neste avsnitt.

Hva er alvorlighetsgrad og prioritet?

Prioritet etter den engelske definisjonen brukes i sammenligningen av to ting eller forhold, der den ene må tillegges mer betydning enn den andre (nene) og må takles med / løses først før du går videre til neste (e). Derfor, i sammenheng med mangler, vil prioriteten til en mangel indikere hvor raskt det må løses.

Alvorlighetsgrad etter den engelske definisjonen brukes til å beskrive alvoret av en uønsket hendelse. Derfor når det gjelder feil, vil alvorlighetsgraden av en feil indikere effekten den har på systemet når det gjelder innvirkning.

Hvem definerer disse?

QA klassifiserer feilen under passende alvorlighetsgrad basert på mangelenes kompleksitet og kritikk.

Eventuelle forretningsinteressenter, inkludert prosjektledere, forretningsanalytikere, produkteier, definerer prioriteten til manglene.

Figuren nedenfor viser rollen som eier og klassifiserer mangelenes kritikk og alvorlighetsgrad.

ALVORHET & PRIORITET

Hvordan velge disse nivåene?

Som vi allerede har diskutert, vurderes alvorlighetsparameteren av testeren, mens prioritetsparameteren hovedsakelig vurderes av produktsjefen eller i utgangspunktet triageteamet. Selv om dette er tilfelle, er alvorlighetsgraden av en mangel definitivt en av de styrende og påvirkende faktorene for å prioritere mangelen. Derfor er det viktig som tester å velge riktig alvorlighetsgrad for å unngå forveksling med utviklingsteam.

Forskjellen mellom alvorlighetsgrad og prioritet

Prioritet er knyttet til planlegging, og 'alvorlighetsgrad' er knyttet til standarder.

'Prioritet' betyr at noe gis eller fortjener forhåndsoppmerksomhet; forrang etablert etter rekkefølge av betydning (eller haster).

'Alvorlighetsgrad' er tilstanden eller kvaliteten til å være alvorlig; alvorlig innebærer overholdelse av strenge standarder eller høye prinsipper og antyder ofte hardhet; alvorlig er preget av eller krever streng overholdelse av strenge standarder eller høye prinsipper, For eksempel, en alvorlig atferdskodeks.

Ordene prioritet og alvorlighetsgrad kommer opp i feilsporing.

En rekke kommersielle programvareverktøy for problemsporing / administrasjon er tilgjengelig. Disse verktøyene, med detaljert innspill fra programvaretestingeniører, gir teamet fullstendig informasjon slik at utviklere kan forstå feilen, få en ide om 'Severity', reprodusere den og fikse den.

Løsningene er basert på prosjekt 'Prioriteter' og 'Alvorlighetsgrad' av feil.

'Alvorlighetsgraden' av et problem er definert i samsvar med kundens risikovurdering og registrert i det valgte sporingsverktøyet.

Buggy-programvare kan 'alvorlig' påvirke tidsplaner, noe som igjen kan føre til en revurdering og reforhandling av 'prioriteringer'.

Hva er prioritet?

Prioritet, som navnet antyder, handler om å prioritere en mangel basert på forretningsbehov og alvorlighetsgraden av mangelen. Prioritet betyr viktigheten eller haster med å fikse en feil.

Mens du åpner en defekt, tildeler testeren generelt prioritet først da han ser på produktet fra sluttbrukerperspektivet. I tråd med disse er det forskjellige nivåer:

Generelt kan prioriteten til manglene klassifiseres som følger:

Prioritet nr. 1) Umiddelbar / kritisk (P1)

Dette må løses umiddelbart innen 24 timer. Dette skjer vanligvis i tilfeller der en hel funksjonalitet er blokkert og ingen testing kan fortsette som et resultat av dette. Eller i visse andre tilfeller, hvis det er betydelige minnelekkasjer, blir defekten generelt klassifisert som en prioritet -1, noe som betyr at programmet / funksjonen er ubrukelig i gjeldende tilstand.

Enhver feil som trenger øyeblikkelig oppmerksomhet som påvirker testprosessen, vil bli klassifisert under den umiddelbare kategorien

Alle de Kritisk alvorlighetsgrad feil faller inn under denne kategorien (med mindre de blir prioritert på nytt av virksomhet / interessenter)

Prioritet # 2) Høy (P2)

Når de kritiske feilene er løst, er en defekt som har denne prioriteten den neste kandidaten som må løses for at en testaktivitet skal matche 'exit' -kriteriene. Normalt når en funksjon ikke er brukbar som den skal, på grunn av en programfeil, eller at ny kode må skrives eller noen ganger til og med fordi noe miljøproblem må håndteres gjennom koden, kan en feil kvalifisere for en prioritet 2 .

Dette er feilen eller problemet som skal løses før løslatelsen skjer. Disse feilene bør løses når de kritiske problemene er løst.

Alle de Major alvorlighetsgrad feil faller inn i denne kategorien.

Prioritet # 3) Middels (P3)

En feil med denne prioriteten må være i strid for å bli løst, da den også kan håndtere funksjonalitetsproblemer som ikke er som forventet. Noen ganger kan til og med kosmetiske feil som å forvente riktig feilmelding under feilen kvalifisere til å være en prioritets 3-feil.

Denne feilen bør løses etter at alle de alvorlige feilene er løst.

Når de kritiske feilene og høyprioriterte feilene er ferdige, kan vi gå for de middels prioriterte feilene.

Alle de Liten alvorlighetsgrad feil faller inn i denne kategorien.

Prioritet # 4) Lav (P4)

En mangel med lav prioritet indikerer at det definitivt er et problem, men det trenger ikke å bli løst for å matche 'exit' -kriteriene. Dette må imidlertid løses før GA er ferdig. Vanligvis kan noen skrivefeil eller til og med kosmetiske feil som diskutert tidligere kategoriseres her.

Noen ganger blir også defekter med lav prioritet åpnet for å foreslå forbedringer i eksisterende design eller en forespørsel om å implementere en liten funksjon for å forbedre brukeropplevelsen.

Denne feilen kan løses i fremtiden og trenger ikke øyeblikkelig oppmerksomhet og Lav alvorlighetsgrad feil faller inn i denne kategorien.

Som allerede diskutert, prioriterer det hvor raskt defekten skal være. Hvis det er flere mangler, bestemmer prioriteten hvilken feil som må løses og bekreftes umiddelbart mot hvilken feil som kan løses litt senere.

Defektprioritets- og alvorlighetsnivåer

Hva er alvorlighetsgrad?

Alvorlighetsgrad definerer i hvilken grad en bestemt feil kan påvirke applikasjonen eller systemet.

Alvorlighetsgrad er en parameter for å betegne implikasjonen av mangel på systemet - hvor kritisk mangel er, og hvilken innvirkning har mangelen på hele systemets funksjonalitet? Alvorlighetsgraden er en parameter som er satt av testeren mens han åpner en defekt og hovedsakelig har kontroll over testeren. Igjen har forskjellige organisasjoner forskjellige verktøy å bruke til mangler, men på et generelt nivå er dette følgende alvorlighetsnivåer:

For eksempel, Tenk på følgende scenarier

  • Hvis brukeren prøver å handle på nettet og applikasjonen ikke lastes inn eller serveren utilgjengelig vises en melding.
  • Brukeren utfører å legge til en vare i handlekurven, antall tilførte mengder er feil / feil produkt blir lagt til.
  • Brukeren betaler og etter betalingen forblir bestillingen i handlekurven som reservert i stedet bekreftet.
  • Systemet godtar bestillingen, men til slutt kansellerer bestillingen etter en halvtime på grunn av eventuelle problemer.
  • Systemet godtar 'Legg i handlekurven' ved dobbeltklikk bare i stedet for på et enkelt klikk.
  • Knappen Legg i handlekurv er stavet som Legg i handlekurven.

Hva ville være brukeropplevelsen hvis noen av scenariene ovenfor kunne skje?

Generelt kan feilene klassifiseres som følger:

# 1) Kritisk (S1)

En mangel som hemmer eller blokkerer testing av produktet / funksjonen er en kritisk feil. Et eksempel kan være i tilfelle UI-testing der etter å ha gått gjennom en veiviser, brukergrensesnittet bare henger i en rute eller ikke går lenger for å utløse funksjonen. Eller i noen andre tilfeller når funksjonen utviklet seg selv, mangler i bygningen.

Av en eller annen grunn, hvis applikasjonen krasjer eller den blir ubrukelig / ikke kan fortsette videre, kan feilen klassifiseres under kritisk alvorlighetsgrad.

Eventuelle katastrofale systemfeil kan føre til at brukerne ikke bruker programmene, kan klassifiseres under kritisk alvorlighetsgrad.

For eksempel, I e-postleverandøren som Yahoo eller Gmail, etter å ha skrevet riktig brukernavn og passord, krasjer systemet eller kaster feilmeldingen i stedet for å logge på. Denne feilen er klassifisert som kritisk da denne feilen gjør hele applikasjonen ubrukelig.

Scenariet på punkt 1 diskutert ovenfor kan klassifiseres som kritisk mangel, ettersom den elektroniske applikasjonen blir helt ubrukelig.

# 2) Major (S2)

Ethvert hovedfunksjon implementert som ikke oppfyller kravene / brukssaken (e) og oppfører seg annerledes enn forventet, kan klassifiseres under alvorlighetsgrad.

En større feil oppstår når funksjonaliteten fungerer grovt borte fra forventningene eller ikke gjør det den skal gjøre. Et eksempel kan være: Si at et VLAN må distribueres på bryteren, og at du bruker en UI-mal som utløser denne funksjonen. Når denne malen for å konfigurere VLAN mislykkes på bryteren, blir den klassifisert som en alvorlig funksjonalitet.

For eksempel, I e-posttjenesteleverandøren som Yahoo eller Gmail, når du ikke har lov til å legge til mer enn en mottaker i CC-delen, er denne feilen klassifisert som den store feilen, da hovedfunksjonaliteten til applikasjonen ikke fungerer som den skal.

Hva som forventes oppførselen til CC-delen i posten, bør det tillate brukeren å legge til flere brukere. Så når hovedfunksjonaliteten til applikasjonen ikke fungerer som den skal, eller når den oppfører seg annerledes enn forventet, er det en stor feil.

Scenariene på punkt 2 og 3 diskutert ovenfor kan klassifiseres som større feil, da ordren forventes å gå jevnt til neste fase av ordrenes livssyklus, men i realiteten varierer den i oppførsel.

Enhver feil som kan føre til ukorrekt datapåvirkning, dataproblemer eller feil applikasjonsatferd kan i stor grad klassifiseres under alvorlighetsgraden.

# 3) Mindre / moderat (S3)

Alle funksjoner som er implementert som ikke oppfyller kravene / bruksområdene og oppfører seg annerledes enn forventet, men effekten er ubetydelig til en viss grad, eller hvis den ikke har stor innvirkning på applikasjonen, kan klassifiseres under Mindre alvor.

En moderat feil oppstår når produktet eller applikasjonen ikke oppfyller visse kriterier eller fremdeles viser unaturlig oppførsel, men funksjonaliteten som helhet påvirkes ikke. For eksempel i VLAN-malen som distribueres ovenfor, vil det oppstå en moderat eller normal feil når malen distribueres med suksess på bryteren, men det er ingen indikasjon på at den sendes til brukeren.

For eksempel, I e-posttjenesteleverandøren som Yahoo eller Gmail er det et alternativ som heter 'Vilkår og betingelser', og i det alternativet vil det være flere lenker angående vilkårene og tilstanden til nettstedet, når en av de flere koblingene ikke fungerer bra, det kalles som mindre alvorlighetsgrad, da det bare påvirker mindre funksjonalitet i applikasjonen, og det ikke har stor innvirkning på brukervennligheten til applikasjonen.

Scenariet på punkt 5 diskutert ovenfor kan klassifiseres som mindre defekt, da det ikke er datatap eller svikt i systemflytrekkefølgen, men en liten ulempe når det gjelder brukeropplevelse.

Disse typer feil resulterer i minimalt tap av funksjonalitet eller brukeropplevelse.

# 4) Lav (S4)

Kosmetiske feil, inkludert stavefeil eller justeringsproblemer eller fonthylser, kan klassifiseres under Lav alvorlighetsgrad.

En mindre feil med lav alvorlighetsgrad oppstår når det nesten ikke er noen innvirkning på funksjonaliteten, men det er fortsatt en gyldig feil som bør rettes. Eksempler på dette kan inkludere stavefeil i feilmeldinger som er skrevet ut til brukere eller mangler for å forbedre utseendet og følelsen til en funksjon.

For eksempel, I e-postleverandøren som Yahoo eller Gmail, ville du ha lagt merke til 'Lisenssiden'. Hvis det er noen stavefeil eller feiljustering på siden, er denne feilen klassifisert som Lav.

Scenariet på punkt 6 diskutert ovenfor kan klassifiseres som lav defekt, siden Legg til-knappen vises i feil foringsrør. Denne typen feil vil ikke ha noen innvirkning på systematferd eller datapresentasjon eller datatap eller dataflyt eller til og med brukeropplevelse, men vil være veldig kosmetisk.

Defektprioritet og alvorlighetsgrad

For å oppsummere viser følgende figur den brede defektklassifiseringen basert på alvorlighetsgrad og prioritet:

Feilklassifisering

Eksempler

Som allerede nevnt, siden forskjellige organisasjoner bruker forskjellige typer verktøy for mangelfølgning og tilhørende prosesser, blir det et vanlig sporingssystem mellom ulike ledelsesnivåer og teknisk personell.

Siden mangel på alvor er mer innenfor funksjonaliteten, setter testingeniøren alvorlighetsgraden av feilen. Noen ganger er utviklerne med på å påvirke alvorlighetsgraden, men det er for det meste avhengig av testeren da han vurderer hvor mye en bestemt funksjon kan påvirke den generelle funksjonen.

På den annen side, når det gjelder å sette defektprioritet, selv om opprinnelig defektopprinneren setter prioritet, defineres den faktisk av produktsjefen da han har et helhetsbilde av produktet og hvor raskt en bestemt mangel må løses. . En tester er ikke en ideell person for å sette defektprioriteten.

hva du skal bruke i stedet for rengjøringsmiddel

Sjokkerende som dette kan virke, det er to forskjellige eksempler på hvorfor:

Eksempel 1) Tenk på at det er en situasjon der brukeren finner en feil i navngivningen av selve produktet eller noe problem med UI-dokumentasjonen. En tester vil normalt åpne en mindre / kosmetisk defekt og kan være veldig enkel å fikse, men når det gjelder produktets utseende / brukeropplevelse, kan det føre til alvorlig innvirkning.

Eksempel 2) Det kan være visse forhold under hvilke en bestemt feil oppstår som kan være en ekstremt sjelden eller ingen mulighet for å treffe i kundemiljøet. Selv om funksjonalitet kan virke som en høyprioritetsfeil for en tester, med tanke på dens sjeldenhet og høye kostnader å fikse - dette vil bli klassifisert som en lavprioritetsfeil.

Derfor blir defektprioriteten generelt sett av produktsjefen i et 'defekt triage' -møte.

Ulike nivåer

Prioritet og alvorlighetsgrad har noen klassifiseringer blant dem som hjelper til med å bestemme hvordan mangelen må håndteres. Mange forskjellige organisasjoner har forskjellige feilloggingsverktøy , så nivåene kan variere.

La oss ta en titt på de forskjellige nivåene for både prioritet og alvorlighetsgrad.

  • Høy prioritet, høy alvorlighetsgrad
  • Høy prioritet, lav alvorlighetsgrad
  • Høy alvorlighetsgrad, lav prioritet
  • Lav alvorlighetsgrad, lav prioritet

Følgende figur viser klassifiseringen av kategoriene i et enkelt utdrag.

klassifisering av kategoriene

# 1) Høy alvorlighetsgrad og høy prioritet

Enhver kritisk / større sakssvikt blir automatisk forfremmet til denne kategorien.

Eventuelle feil som testingen ikke kan fortsette for enhver pris eller forårsaker at en alvorlig systemfeil faller inn i denne kategorien. For eksempel, ved å klikke på en bestemt knapp lastes ikke selve funksjonen inn. Eller å utføre en bestemt funksjon bringer ned serveren konsekvent og forårsaker tap av data. De røde linjene i figuren ovenfor indikerer slike feil.

For eksempel,

Systemet krasjer etter at du har betalt, eller når du ikke kan legge varene i handlekurven, er denne feilen merket som høy alvorlighetsgrad og høy prioritetsfeil.

Et annet eksempel vil være en minibankautomats funksjon for valuta, hvor maskinen etter å ha tastet inn riktig brukernavn og passord ikke gir ut penger, men trekker de overførte fra kontoen din.

# 2) Høy prioritet og lav alvorlighetsgrad

Eventuelle mindre alvorlighetsfeil som direkte kan påvirke brukeropplevelsen blir automatisk promotert til denne kategorien.

Mangler som må løses, men som ikke påvirker applikasjonen, faller inn under denne kategorien.

For eksempel, funksjonen forventes å vise en bestemt feil for brukeren med hensyn til returkoden. I dette tilfellet vil koden funksjonelt kaste en feil, men meldingen må være mer relevant for den genererte returkoden. De blå linjene i figuren indikerer slike feil.

For eksempel,

Logoen til selskapet på forsiden er feil, det anses å være Høy prioritet og lav alvorlighetsgrad defekt .

Eksempel 1) På nettbutikknettstedet når FrontPage-logoen er stavet feil, for eksempel i stedet for Flipkart, er det stavet som Flipkart.

Eksempel 2) I banklogoen, i stedet for ICICI, skrives den som ICCCI.

Når det gjelder funksjonalitet, påvirker det ikke noe, så vi kan merke som lav alvorlighetsgrad, men det har en innvirkning på brukeropplevelsen. Denne typen feil må løses med høy prioritet, selv om de har veldig mindre innvirkning på applikasjonssiden.

# 3) Høy alvorlighetsgrad og lav prioritet

Enhver feil som funksjonelt ikke oppfyller kravene eller har noen funksjonelle implikasjoner på systemet, men som blir satt til baksetet av interessentene når det gjelder forretningskritisk, blir automatisk forfremmet til denne kategorien.

Mangler som må løses, men ikke umiddelbart. Dette kan spesifikt skje under ad hoc-testing. Det betyr at funksjonaliteten påvirkes i stor grad, men observeres bare når visse uvanlige inngangsparametere brukes.

For eksempel, en bestemt funksjonalitet kan bare brukes på en senere versjon av firmwaren, så for å bekrefte dette - testeren nedgraderer faktisk systemet og utfører testen og observerer et alvorlig funksjonalitetsproblem som er gyldig. I et slikt tilfelle vil feilene bli klassifisert i denne kategorien betegnet med rosa linjer, da det normalt forventes sluttbrukere å ha en høyere versjon av firmwaren.

For eksempel,

På et nettsted for sosiale nettverk, hvis en betaversjon av en ny funksjon blir utgitt med ikke mange aktive brukere som bruker dette anlegget per i dag. Enhver feil som finnes på denne funksjonen kan klassifiseres som lav prioritet ettersom funksjonen tar baksetet på grunn av virksomhetsklassifisering som ikke viktig.

Selv om denne funksjonen har en funksjonsfeil, siden den ikke påvirker sluttkundene direkte, kan en forretningsinteressent klassifisere feilen under lav prioritet, selv om den har en alvorlig funksjonell innvirkning på applikasjonen.

Dette er en høy alvorlighetsfeil, men kan prioriteres til lav prioritet, da den kan løses med neste utgivelse som en endringsforespørsel. Virksomhetsinteressenter prioriterer også denne funksjonen som en sjelden brukt funksjon og påvirker ikke andre funksjoner som har direkte innvirkning på brukeropplevelsen. Denne typen feil kan klassifiseres under Høy alvorlighetsgrad, men lav prioritet kategori.

# 4) Lav alvorlighetsgrad og lav prioritet

Eventuelle stavefeil / skrifttype / feiljustering i avsnitt 3rdeller 4thsiden til applikasjonen og ikke på hovedsiden eller forsiden / tittelen.

Disse feilene er klassifisert i de grønne linjene som vist på figuren og oppstår når det ikke er noen funksjonalitetspåvirkning, men fremdeles ikke oppfyller standardene i liten grad. Generelt er kosmetiske feil eller si dimensjoner til en celle i en tabell på brukergrensesnittet klassifisert her.

For eksempel,

Hvis personvernreglene på nettstedet har en stavefeil, settes denne feilen som Lav alvorlighetsgrad og lav prioritet.

Retningslinjer

Nedenfor er det visse retningslinjer som hver tester må prøve å følge:

  • For det første, forstå begrepene prioritet og alvorlighetsgrad. Unngå å forveksle hverandre og bruke dem om hverandre. I tråd med dette, følg strenghetsretningslinjene som er publisert av organisasjonen / teamet ditt, slik at alle er på samme side.
  • Velg alltid alvorlighetsgraden basert på problemtypen, da dette vil påvirke prioriteten. Noen eksempler er:
    • For et problem som er kritisk, for eksempel at hele systemet går ned og ingenting kan gjøres - denne alvorlighetsgraden bør ikke brukes til å løse programfeil.
    • For et problem som er viktig, for eksempel i tilfeller der funksjonen ikke fungerer som forventet, kan denne alvorlighetsgraden brukes til å adressere nye funksjoner eller forbedring av det nåværende arbeidet.
      Husk at det å velge riktig alvorlighetsgrad vil i sin tur gi feilen, det er den rette prioritet.
  • Som tester - forstå hvordan en bestemt funksjonalitet, snarere å bore ned ytterligere - forstå hvordan et bestemt scenario eller testtilfelle vil påvirke sluttbrukeren. Dette innebærer mye samarbeid og samhandling med utviklingsteamet, forretningsanalytikere, arkitekter, testledelse, utviklingsledelse. I diskusjonene dine må du også ta i betraktning hvor lang tid det ville ta å fikse feilen basert på dens kompleksitet og tid til å bekrefte denne feilen.
  • Endelig , det er alltid produktseieren som har vetoret for frigjøringen, som mangelen skal løses. Men siden defekt-triagesesjonene inneholder varierte medlemmer for å presentere sitt perspektiv på feilen på et saksbasis, på et slikt tidspunkt hvis utviklerne og testerne er synkroniserte, hjelper det sikkert å påvirke avgjørelsen.

Konklusjon

Når du åpner feil, er det en testers ansvar å tildele feil alvorlighetsgrad. Feil alvorlighetsgrad og dermed prioritert kartlegging kan ha svært drastiske konsekvenser for den generelle STLC-prosessen og produktet som helhet. I flere jobbintervjuer - det er flere spørsmål som blir stilt om prioritering og alvorlighetsgrad for å sikre at du som tester har disse begrepene uklanderlig klare i tankene dine.

Vi hadde også sett live eksempler på hvordan man kunne klassifisere feilen under forskjellige alvorlighets- / prioritetsbøtter. Nå skulle jeg ønske du hadde nok avklaring om feilklassifisering både i alvorlighetsgrad / prioritetsbøtter.

Håper denne artikkelen er en komplett guide for å forstå defektprioriteten og alvorlighetsgraden. Gi oss beskjed om dine tanker / spørsmål i kommentarene nedenfor.

Anbefalt lesing

^