Forskel mellem sværhedsgrad og prioritet i test (eksempel)

Sværhedsgrad vs. Prioritet: Forskel mellem dem

  • Prioritet er den rækkefølge, hvori udvikleren skal løse en defekt, mens Alvor er graden af ​​indvirkning, som en defekt har på produktets funktion.
  • Prioritet er kategoriseret i tre typer: lav, medium og høj, mens sværhedsgrad er kategoriseret i fem typer: kritisk, større, moderat, mindre og kosmetisk.
  • Prioritet er forbundet med planlægning, mens sværhedsgrad er forbundet med funktionalitet eller standarder.
  • Prioritet angiver, hvor hurtigt fejlen skal rettes, mens Alvorlighed angiver alvoren af ​​defekten på produktfunktionaliteten.
  • Prioritet af defekter bestemmes i samråd med lederen/klienten, mens sværhedsgraden af ​​defekterne bestemmes af QA-ingeniøren.
  • Prioritet er drevet af forretningsværdi, mens Alvorlighed er drevet af funktionalitet.
  • Prioritetsværdien er subjektiv og kan ændre sig over en periode afhængig af ændringen i projektsituationen, hvorimod sværhedsgraden er objektiv og mindre tilbøjelig til at ændre sig.
  • Høj prioritet og lav prioritetsstatus angiver, at defekter skal rettes på øjeblikkelig basis, men påvirker ikke applikationen, mens High Severity og lav prioritetsstatus angiver, at defekter skal rettes, men ikke på øjeblikkelig basis.
  • Prioritetsstatus er baseret på kundekrav, mens alvorlighedsstatus er baseret på produktets tekniske aspekt.

Sværhedsgrad vs. Prioritet:

Hvad er Bug Alvor

Sværhedsgrad af fejl eller Defekt Alvor i test er en grad af påvirkning en fejl eller en Defekt har på softwareapplikationen, der testes. En højere effekt af fejl/defekt på systemfunktionalitet vil føre til et højere alvorlighedsniveau. EN Kvalitetssikring ingeniør bestemmer normalt sværhedsgraden af ​​en fejl/defekt.

Hvad er prioritet?

Prioritet defineres som den rækkefølge, hvori en defekt skal rettes. Jo højere prioritet, jo hurtigere skal fejlen være løst.

Defekter, der gør softwaresystemet ubrugeligt, prioriteres højere end defekter, der får en lille funktionalitet af softwaren til at svigte.

Typer af sværhedsgrad

In Software Testing, Typer af sværhedsgrad af fejl/defekter kan kategoriseres i følgende dele:

  • Kritisk: Denne defekt indikerer fuldstændig lukning af processen, intet kan fortsætte yderligere
  • Major: Det er en meget alvorlig defekt og kollapser systemet. Visse dele af systemet forbliver dog funktionelle
  • Medium: Det forårsager en vis uønsket adfærd, men systemet er stadig funktionelt
  • Lav: Det vil ikke forårsage nogen større nedbrydning af systemet

Prioriterede typer

Prioritetstyper for fejl/defekter kan kategoriseres i tre dele:

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

Tips til at bestemme alvoren af ​​en defekt

  • Bestem hyppigheden af ​​forekomsten: 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 defekten: Isolering af defekten kan hjælpe med at finde ud af, hvor alvorlig påvirkningen er.

Forskel mellem sværhedsgrad og prioritet i test

Prioritet Severity
Defektprioritet har defineret den rækkefølge, i hvilken udvikleren skal løse en defekt Defektalvor er defineret som graden af ​​indvirkning, som en defekt har på produktets funktion
Prioritet er forbundet med planlægning Alvorlighed er forbundet med funktionalitet eller standarder
Prioritet angiver, hvor hurtigt fejlen skal rettes Alvorlighed angiver, hvor alvorlig defekten er på produktets funktionalitet
Prioritering af mangler afgøres i samråd med leder/klient QA-ingeniør bestemmer sværhedsgraden af ​​defekten
Prioritet er drevet af forretningsværdi Sværhedsgrad er drevet af funktionalitet
Dens værdi er subjektiv og kan ændre sig over en periode afhængig af ændringen i projektsituationen Dens værdi er objektiv og mindre tilbøjelig til at ændre sig
Høj prioritet og lav alvorlighedsstatus indikerer, at defekter skal rettes med det samme, men påvirker ikke applikationen Høj sværhedsgrad og lav prioritetsstatus indikerer, at defekter skal rettes, men ikke umiddelbart
Prioritetsstatus er baseret på kundekrav Alvorlighedsstatus er baseret på det tekniske aspekt af produktet
Under UAT retter udviklingsteamet fejl baseret på prioritet Under SIT vil udviklingsteamet rette fejl baseret på sværhedsgraden og derefter prioritet
Prioritet er kategoriseret i tre typer

  • Lav
  • Medium
  • Høj
Sværhedsgrad er kategoriseret i fem typer

  • Kritisk
  • Major
  • Moderat
  • Minor
  • Kosmetisk

Eksempel på defektens sværhedsgrad og prioritet

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

Defektens sværhedsgrad og prioritet

  • En meget lav sværhedsgrad med høj prioritet: En logofejl for ethvert forsendelseswebsted kan være af lav alvor, da det ikke vil påvirke webstedets funktionalitet, 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 en lav prioritet: Ligeledes kan en defekt i reservationsfunktionaliteten for flyoperationswebsteder være af høj alvorlighed, men kan have lav prioritet, da den kan planlægges til at blive frigivet i en næste cyklus.

Defekt Triage

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

Sådan bestemmes fejltriage:

De fleste systemer bruger prioritet som hovedkriteriet til at vurdere defekten. Men en god triage-proces tager også hensyn til sværhedsgraden.

Defekt Triage

Triageprocessen omfatter følgende trin

  • Revdvs. alle defekterne inklusive afviste defekter af teamet
  • Den indledende vurdering af defekterne er baseret på dens indhold og respektive prioritets- og alvorlighedsindstillinger
  • Prioritering af defekten baseret på input
  • Tildel defekten til korrekt frigivelse af produktchefen
  • Omdirigerer defekten til den korrekte ejer/team for yderligere handling

Retningslinjer, som alle testere bør overveje, før de vælger en sværhedsgrad

Alvorlighedsparameteren vurderes af testeren, mens prioritetsparameteren 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 dets prioritet
  • Forstå, hvordan et bestemt scenarie eller Test sag vil påvirke slutbrugeren
  • Skal overveje, hvor lang tid det vil tage at rette defekten baseret på dens kompleksitet og tid at verificere defekten

Konklusion

In Software Engineering, Tildeling af forkert sværhedsgrad til defekt kan forsinke STLC proces og kan have nogle drastiske konsekvenser for teamets overordnede præstation. Så den ansvarlige person skal være præcis og præcis i sin opfordring til at tildele fejl.

Opsummer dette indlæg med: