Svårighetsgrad & Prioritet vid testning: Skillnader & Exempel

Innehållsförteckning:

Anonim

Bug Severity

Bug-allvar eller defekt Allvarlighetsgrad vid testning är en viss inverkan som ett fel eller en defekt har på programvaran som testas. En högre effekt av fel / defekt på systemfunktionaliteten kommer att leda till en högre svårighetsgrad. En kvalitetssäkringsingenjör bestämmer vanligtvis svårighetsgraden för ett fel / defekt.

Vad är prioritet?

Prioritet definieras som den ordning i vilken en defekt ska åtgärdas. Ju högre prioritet desto snabbare ska felet lösas.

Fel som gör att programvarusystemet är oanvändbart prioriteras högre än defekter som gör att programvaran inte fungerar som den ska.

NYCKELSKILL

  • Prioritet är den ordning i vilken utvecklaren ska lösa en defekt medan svårighetsgraden är graden av inverkan som en defekt har på produktens funktion.
  • Prioritet kategoriseras i tre typer: låg, medium och hög medan svårighetsgrad kategoriseras i fem typer: kritisk. major, måttlig, mindre och kosmetisk.
  • Prioritet är associerad med schemaläggning medan Severity är associerad med funktionalitet eller standarder.
  • Prioritet indikerar hur snart fel ska åtgärdas medan svårighetsgrad indikerar allvaret av defekten på produktfunktionaliteten.
  • Prioritet för defekter bestäms i samråd med chefen / klienten medan svårighetsgraden av defekterna bestäms av QA-ingenjören.
  • Prioritet drivs av affärsvärde medan Severity drivs av funktionalitet.
  • Prioritetsvärdet är subjektivt och kan förändras över en tidsperiod beroende på förändringen i projektsituationen medan allvarlighetsvärdet är objektivt och mindre troligt att det ändras.
  • Status med hög prioritet och låg svårighetsgrad indikerar att defekter måste åtgärdas på omedelbara baser men påverkar inte applikationen medan status med hög svårighetsgrad och låg prioritet indikerar att fel måste fixas men inte på omedelbara baser.
  • Prioritetsstatus baseras på kundkrav medan svårighetsstatus baseras på produktens tekniska aspekt.

Typer av svårighetsgrad

I programvarutestning kan typer av svårighetsgrad av fel / defekt delas in i fyra delar:

  • Kritiskt : Denna defekt indikerar fullständig avstängning av processen, ingenting kan gå vidare
  • Major : Det är en mycket allvarlig defekt och kollapsar systemet. Vissa delar av systemet är dock fortfarande funktionella
  • Medium : Det orsakar en del oönskat beteende, men systemet är fortfarande funktionellt
  • Låg : Det orsakar ingen större nedbrytning av systemet

Prioriterade typer

Typer av prioritet för fel / defekt kan delas in i tre delar:

  • Låg: Defekten är irriterande men reparation kan göras när den allvarligare Defekten har åtgärdats
  • Medium: Under den normala utvecklingsfasen bör defekten lösas. Det kan vänta tills en ny version skapas
  • Hög: Felet måste lösas så snart som möjligt eftersom det påverkar systemet allvarligt och inte kan användas förrän det har åtgärdats

Tips för att bestämma svårighetsgraden av en defekt

  • Bestäm frekvensen av händelse: I vissa fall, om förekomsten av en mindre defekt är frekvent i koden, kan den vara allvarligare. Så ur en användares perspektiv är det allvarligare trots att det är en mindre defekt.
  • Isolera defekten: Isolering av defekten kan hjälpa till att ta reda på hur allvarlig den är.

Prioritet kontra svårighetsgrad: Nyckelskillnad

Prioritet Allvarlighetsgrad
  • Defektprioritet har definierat i vilken ordning utvecklaren ska lösa en defekt
  • Defektgrad definieras som graden av inverkan som en defekt har på produktens funktion
  • Prioritet kategoriseras i tre typer
    • Låg
    • Medium
    • Hög
  • Svårighetsgrad kategoriseras i fem typer
    • Kritisk
    • Större
    • Måttlig
    • Mindre
    • Kosmetisk
  • Prioritet är förknippad med schemaläggning
  • Svårighetsgrad är förknippad med funktionalitet eller standarder
  • Prioritet indikerar hur snart felet ska åtgärdas
  • Allvarlighet indikerar allvaret av defekten på produktens funktionalitet
  • Prioritet för brister bestäms i samråd med chef / klient
  • QA-ingenjör bestämmer defektens svårighetsgrad
  • Prioritet drivs av affärsvärde
  • Allvarlighet drivs av funktionalitet
  • Dess värde är subjektivt och kan förändras över en tidsperiod beroende på förändringen i projektsituationen
  • Dess värde är objektivt och mindre troligt att det förändras
  • Hög prioritet och låg svårighetsgrad indikerar att defekter måste åtgärdas omedelbart men inte påverkar applikationen
  • Hög svårighetsgrad och låg prioritetsstatus indikerar att defekter måste åtgärdas men inte på omedelbara baser
  • Prioritetsstatus baseras på kundkrav
  • Allvarlighetsstatus baseras på produktens tekniska aspekt
  • Under UAT fixar utvecklingsgruppen defekter baserat på prioritet
  • Under SIT kommer utvecklingsteamet att fixa defekter baserat på svårighetsgrad och sedan prioritet

Exempel på svårighetsgrad och prioritet

Låt oss se ett exempel på låg svårighetsgrad och hög prioritet och vice versa

  • En mycket låg allvarlighetsgrad med hög prioritet: Ett logotypfel för alla leveranswebbplatser kan ha låg allvarlighet eftersom det inte kommer att påverka webbplatsens funktionalitet men kan ha hög prioritet eftersom du inte vill att någon ytterligare försändelse ska fortsätta med fel logotyp.
  • En mycket hög svårighetsgrad med låg prioritet: Likaså kan en defekt i bokningsfunktionaliteten för flygoperationswebbplatsen vara av hög svårighetsgrad men kan ha låg prioritet eftersom den kan planeras att släppas i nästa cykel.

Defekt Triage

Defekt triage är en process som försöker göra ombalanseringen av processen där testteamet står inför problemet med begränsad tillgång på resurser. Så när det finns ett stort antal defekter och begränsade testare för att verifiera dem, hjälper defekt triage att försöka få så många fel som kan lösas baserat på defektparametrar som svårighetsgrad och prioritet.

Hur man bestämmer Defekt Triage:

De flesta system använder prioritet som huvudkriterium för att bedöma defekten. En bra triageprocess tar dock också hänsyn till svårighetsgraden.

Triageprocessen innehåller följande steg

  • Granska alla brister inklusive avvisade brister av teamet
  • Den första bedömningen av bristerna baseras på dess innehåll och respektive prioritets- och svårighetsinställningar
  • Prioritera defekten baserat på ingångarna
  • Tilldela defekten för att korrigera frigöringen av produktchefen
  • Omdirigerar defekten till rätt ägare / team för ytterligare åtgärder

Riktlinjer som varje testare bör överväga innan de väljer en svårighetsgrad

Allvarlighetsparametern bedöms av testaren medan prioriteringsparametern bedöms av produktchefen eller av triage-teamet. För att prioritera defekten är det absolut nödvändigt för en testare att välja rätt svårighetsgrad för att undvika förvirring med utvecklingsteamet.

  • Förstå begreppet prioritet och svårighetsgrad väl
  • Tilldela alltid svårighetsgraden baserat på frågestypen eftersom detta påverkar dess prioritet
  • Förstå hur ett visst scenario eller testfall skulle påverka slutanvändaren
  • Måste överväga hur mycket tid det skulle ta att fixa defekten baserat på dess komplexitet och tid för att verifiera defekten

Slutsats:

  • Inom Software Engineering kan tilldelning av fel svårighetsgrad till defekter fördröja STLC-processen och kan ha en viss drastisk inverkan på teamets övergripande prestanda. Så den ansvariga personen måste vara exakt och exakt när det gäller att tilldela fel.