Alvorlighed & Prioritet i test: Forskelle & Eksempel

Indholdsfortegnelse:

Anonim

Bug Alvorlighed

Fejlgrad eller defekt Alvorlighed ved test er en grad af indvirkning, som en fejl eller en fejl har på softwareapplikationen, der testes. En højere effekt af fejl / fejl på systemfunktionalitet vil føre til et højere sværhedsgrad. En kvalitetssikringsingeniør bestemmer normalt sværhedsgraden af ​​en fejl / mangel.

Hvad er prioritet?

Prioritet defineres som den rækkefølge, som en mangel skal rettes i. Jo højere prioritet, jo hurtigere skal manglen løses.

Fejl, der efterlader softwaresystemet ubrugeligt, får højere prioritet end mangler, der får en lille funktionalitet i softwaren til at mislykkes.

Nøgleforskel

  • Prioritet er den rækkefølge, hvor udvikleren skal løse en defekt, mens alvorligheden er graden af ​​indflydelse, som en defekt har på produktets funktion.
  • Prioritet er kategoriseret i tre typer: lav, medium og høj, mens alvor er kategoriseret i fem typer: kritisk. større, moderat, mindre og kosmetiske.
  • Prioritet er forbundet med planlægning, mens Alvorlighed er forbundet med funktionalitet eller standarder.
  • Prioritet angiver, hvor hurtigt fejlen skal rettes, mens Alvorlighed angiver alvorligheden af ​​manglen på produktets funktionalitet.
  • Prioritet for mangler bestemmes i samråd med lederen / klienten, mens alvorlighedsniveauerne for defekterne bestemmes af QA-ingeniøren.
  • Prioritet er drevet af forretningsværdi, mens Severity er drevet af funktionalitet.
  • Prioritetsværdien er subjektiv og kan ændre sig over en periode afhængigt af ændringen i projektsituationen, mens alvorlighedsværdien er objektiv og mindre tilbøjelig til at ændre sig.
  • Status med høj prioritet og lav sværhedsgrad angiver, defekt skal rettes på umiddelbare baser, men påvirker ikke applikationen, mens høj alvorlighedsgrad og lav prioritetsstatus angiver, at defekt skal rettes, men ikke på umiddelbare baser.
  • Prioritetsstatus er baseret på kundens krav, mens alvorlighedsstatus er baseret på produktets tekniske aspekt.

Typer af sværhedsgrad

I softwaretest kan typer af sværhedsgrad af bug / defekt kategoriseres i fire dele:

  • Kritisk : Denne fejl indikerer fuldstændig nedlukning af processen, intet kan gå videre
  • Major : Det er en meget alvorlig defekt og kollapser systemet. Visse dele af systemet forbliver dog funktionelt
  • Medium : Det forårsager uønsket adfærd, men systemet fungerer stadig
  • Lav : Det medfører ikke nogen større nedbrydning af systemet

Prioriterede typer

Typer af prioritet af bug / defekt kan kategoriseres i tre dele:

  • Lav: Fejlen er irriterende, men reparation kan udføres, når den mere alvorlige Fejl er rettet
  • Medium: Under det normale forløb af udviklingsaktiviteterne skal manglen løses. Det kan vente, indtil en ny version oprettes
  • Høj: Fejlen skal løses hurtigst muligt, da den påvirker systemet alvorligt og ikke kan bruges, før den er rettet

Tips til bestemmelse af sværhedsgraden af ​​en defekt

  • Beslut hyppigheden af ​​forekomst: I nogle tilfælde, hvis forekomsten af ​​en mindre defekt er hyppig i koden, kan den være mere alvorlig. Så fra en brugers perspektiv er det mere alvorligt, selvom det er en mindre defekt.
  • Isoler manglen: Isolering af manglen kan hjælpe med at finde ud af dens sværhedsgrad af påvirkningen.

Prioritet versus sværhedsgrad: nøgleforskel

Prioritet Alvorlighed
  • Defektprioritet har defineret den rækkefølge, som udvikleren skal løse en fejl
  • Defekt Alvorlighed defineres som graden af ​​indflydelse, som en defekt har på produktets funktion
  • Prioritet er kategoriseret i tre typer
    • Lav
    • Medium
    • Høj
  • Alvorligheden er kategoriseret i fem typer
    • Kritisk
    • Major
    • Moderat
    • Mindre
    • Kosmetik
  • Prioritet er forbundet med planlægning
  • Alvorlighed er forbundet med funktionalitet eller standarder
  • Prioritet angiver, hvor hurtigt fejlen skal rettes
  • Alvorlighed angiver alvorligheden af ​​manglen på produktets funktionalitet
  • Prioritet for mangler bestemmes i samråd med leder / klient
  • QA-ingeniør bestemmer sværhedsgraden af ​​defekten
  • Prioritet er drevet af forretningsværdi
  • Alvorligheden er drevet af funktionalitet
  • Dens værdi er subjektiv og kan ændre sig over en periode afhængigt af ændringen i projektsituationen
  • Dens værdi er objektiv og mindre tilbøjelig til at ændre sig
  • Høj prioritet og lav sværhedsgrad angiver, defekt skal rettes på umiddelbare baser, men påvirker ikke applikationen
  • Høj sværhedsgrad og lav prioritetsstatus indikerer, at defekter skal løses, men ikke på umiddelbare baser
  • Prioritetsstatus er baseret på kundens krav
  • Alvorlighedsstatus er baseret på produktets tekniske aspekt
  • Under UAT løser udviklingsteamet fejl baseret på prioritet
  • Under SIT vil udviklingsteamet rette fejl baseret på sværhedsgraden og derefter prioriteten

Eksempel på mangel på sværhedsgrad og prioritet

Lad os se et eksempel på lav sværhedsgrad og høj prioritet og omvendt

  • En meget lav sværhedsgrad med høj prioritet: En logofejl for ethvert forsendelseswebsted kan have lav sværhedsgrad, da det ikke påvirker webstedsfunktionaliteten, men kan have høj prioritet, da du ikke ønsker, at yderligere forsendelse skal fortsætte med det forkerte logo.
  • En meget høj sværhedsgrad med lav prioritet: Ligeledes for flyveoperationswebsite kan en fejl i reservationsfunktionaliteten være af høj sværhedsgrad, men kan have lav prioritet, da den kan planlægges frigivet i en næste cyklus.

Defekt forstyrrelse

Defekt triage er en proces, der forsøger at foretage en afbalancering af processen, hvor testteamet står over for problemet med begrænset tilgængelighed af ressourcer. Så når der er et stort antal defekter og begrænsede testere til at verificere dem, hjælper defekt triage med at forsøge at få så mange fejl løst baseret på defektparametre som sværhedsgrad og prioritet.

Sådan bestemmes defektforstyrrelse:

De fleste systemer bruger prioritet som de vigtigste kriterier for at vurdere manglen. En god triageproces overvejer imidlertid også sværhedsgraden.

Triageprocessen inkluderer følgende trin

  • Gennemgang af alle mangler inklusive afviste mangler fra holdet
  • Første vurdering af manglerne er baseret på dens indhold og respektive prioritets- og sværhedsindstillinger
  • Prioritering af fejlen baseret på input
  • Tildel defekten til korrekt frigivelse af produktchefen
  • Omdirigerer defekten til den korrekte ejer / hold til yderligere handling

Retningslinjer, som hver tester skal overveje, før de vælger en sværhedsgrad

Alvorlighedsparameter vurderes af testeren, mens prioritetsparameter vurderes af produktchefen eller af triage-teamet. For at prioritere defekten er det bydende nødvendigt for en tester at vælge den rigtige sværhedsgrad for at undgå forvirring med udviklingsteamet.

  • Forstå begrebet prioritet og sværhedsgrad godt
  • Tildel altid sværhedsgraden baseret på problemtypen, da dette vil påvirke dens prioritet
  • Forstå, hvordan et bestemt scenario eller en testsag vil påvirke slutbrugeren
  • Brug for at overveje, hvor lang tid det ville tage at rette manglen på baggrund af dens kompleksitet og tid til at bekræfte manglen

Konklusion:

  • I Software Engineering kan tildeling af forkert sværhedsgrad til defekt forsinke STLC-processen og kan have en drastisk indflydelse på holdets samlede præstation. Så den ansvarlige person skal være præcis og præcis i sin opfordring til at tildele fejl.