defect severity priority testing with examples
I den här handledningen lär du dig vad som är Defekt-svårighetsgrad och prioritet vid testning, hur man ställer in defektprioritet och svårighetsgrad med exempel för att förstå konceptet tydligt.
Vi kommer också att beskriva i detalj hur man klassificerar defekterna under olika hinkar och deras relevans i Defect Life-cykeln. Vi kommer också att täcka klassificeringens viktiga roll med en levande uppsättning exempel.
Arkivering av fel är mycket integrerad del av programvarutestningens livscykel . Det finns flera bästa metoder som definierats för effektiv felrapportering via internet eller i organisationer.
Vad du kommer att lära dig:
- Översikt över defektspårning
Översikt över defektspårning
En av de viktiga aspekterna av defektlivscykeln på generisk nivå inkluderar spårning av defekter. Detta är viktigt eftersom testteam öppnar flera fel när de testar en mjukvara som bara multipliceras om det specifika systemet som testas är komplext. I ett sådant scenario kan det vara en skrämmande uppgift att hantera dessa defekter och analysera dessa defekter för att driva stängningen.
I linje med underhållsprocesser för defekter, när någon testare arkiverar en defekt, förutom metoden / beskrivningen för att återge den synliga frågan, måste han också tillhandahålla en viss kategoriinformation som skulle hjälpa till med felaktig klassificering av defekten. Detta skulle i sin tur hjälpa till med effektiva spårnings- / underhållsprocesser och skulle också utgöra grunden för snabbare vändningstid.
De två huvudparametrarna som ligger till grund för effektiv defektspårning och lösning är:
- Defektprioritet vid testning
- Defekt svårighetsgrad vid testning
Dessa är ofta ett förvirrande koncept och används nästan omväxlande bland inte bara testteam utan också utvecklingsteam. Det finns en fin linje mellan de två och det är viktigt att förstå att det verkligen finns skillnader mellan de två.
Låt oss förstå kort de teoretiska definitionerna av de två parametrarna i nästa avsnitt.
hur öppnar jag en bin-fil
Vad är svårighetsgrad och prioritet?
Prioritet enligt den engelska definitionen används vid jämförelse av två saker eller villkor, där den ena måste ges större vikt än den andra (n) och måste hanteras med / lösas först innan man går vidare till nästa (n). Därför, i samband med defekter, skulle prioriteten för en defekt indikera hur brådskande den skulle behöva åtgärdas.
Svårighetsgrad enligt den engelska definitionen används för att beskriva allvaret av en oönskad händelse. Följaktligen när det gäller buggar skulle allvaret av ett fel indikera vilken effekt det har på systemet när det gäller dess påverkan.
Vem definierar dessa?
QA klassificerar defekten under lämplig svårighetsgrad baserat på defektenas komplexitet och kritik.
Alla affärsintressenter inklusive projektledare, affärsanalytiker och produktägare definierar prioriteten för bristerna.
Nedanstående figur visar rollen som äger och klassificerar defektenes kritik och svårighetsgrad.
Hur väljer man dessa nivåer?
Som vi redan har diskuterat bedöms allvarlighetsparametern av testaren medan prioriteringsparametern huvudsakligen bedöms av Product Manager eller i princip triage-teamet. Även om detta är fallet är svårigheten hos en defekt definitivt en av de styrande och påverkande faktorerna för att prioritera defekten. Därför är det viktigt som testare att välja rätt svårighetsgrad för att undvika förvirring med utvecklingsteam.
Skillnad mellan svårighetsgrad och prioritet
Prioritet är förknippad med schemaläggning, och 'svårighetsgrad' är förknippad med standarder.
'Prioritet' betyder att något ges eller förtjänar förhandsuppmärksamhet; prioritet fastställd av ordning av betydelse (eller brådskande).
'Allvarlighet' är tillståndet eller kvaliteten på att vara allvarlig; allvarligt innebär att man följer strikta standarder eller höga principer och föreslår ofta hårdhet; allvarlig kännetecknas av eller kräver strikt efterlevnad av strikta standarder eller höga principer, Till exempel, en allvarlig uppförandekod.
Orden prioritet och svårighetsgrad kommer upp i felspårning.
Många kommersiella programverktyg för problemspårning / hantering finns tillgängliga. Dessa verktyg, med detaljerad inmatning från programvarutestingenjörer, ger teamet fullständig information så att utvecklare kan förstå felet, få en uppfattning om dess ”allvar”, reproducera det och fixa det.
Korrigeringarna baseras på projektet 'Prioriteter' och 'Allvarlighet' av buggar.
Problemets svårighetsgrad definieras i enlighet med kundens riskbedömning och registreras i deras valda spårningsverktyg.
Buggy-programvara kan 'allvarligt' påverka scheman, vilket i sin tur kan leda till en omvärdering och omförhandling av 'prioriteringar'.
Vad är prioritet?
Prioritet, som namnet antyder, handlar om att prioritera en defekt baserat på affärsbehov och svårighetsgraden. Prioritet betyder vikten eller brådskandet att åtgärda en defekt.
När en defekt öppnas, tilldelar testaren i allmänhet prioritet initialt när han ser produkten ur slutanvändarperspektivet. I linje med dessa finns det olika nivåer:
I stort sett kan bristens prioritet klassificeras enligt följande:
Prioritet # 1) Omedelbar / Kritisk (P1)
Detta måste åtgärdas omedelbart inom 24 timmar. Detta inträffar vanligtvis i fall då en hel funktionalitet är blockerad och ingen testning kan fortsätta som ett resultat av detta. Eller i vissa andra fall om det finns betydande minnesläckage klassificeras defekten i allmänhet som en prioritet -1, vilket betyder att programmet / funktionen är oanvändbar i nuvarande tillstånd.
Varje defekt som behöver omedelbar uppmärksamhet som påverkar testprocessen kommer att klassificeras under den omedelbara kategorin
Alla Kritisk svårighetsgrad defekter faller inom denna kategori (såvida inte företaget / intressenterna omprioriterar dem)
Prioritet # 2) Hög (P2)
När de kritiska defekterna har åtgärdats är en defekt med denna prioritet nästa kandidat som måste åtgärdas för att testaktiviteter ska matcha 'exit' -kriterierna. Normalt när en funktion inte kan användas som den ska, på grund av en programdefekt, eller att ny kod måste skrivas eller ibland till och med för att något miljöproblem måste hanteras genom koden, kan en defekt kvalificera sig för en prioritet 2 .
Detta är bristen eller problemet som ska lösas innan släppet görs. Dessa brister bör lösas när de kritiska problemen har lösts.
Alla Större Allvarlighetsgrad defekter faller inom denna kategori.
Prioritet # 3) Medium (P3)
En defekt med denna prioritet måste vara i strid för att åtgärdas eftersom den också kan hantera funktionalitetsfrågor som inte är enligt förväntan. Ibland kan även kosmetiska fel som att förvänta sig rätt felmeddelande under felet kvalificera som en prioritets 3-defekt.
Denna fel bör lösas efter att alla allvarliga buggar har åtgärdats.
När de kritiska och högprioriterade buggarna är klara kan vi gå efter de medelprioriterade buggarna.
Alla Mindre Allvarlighetsgrad defekter faller inom denna kategori.
Prioritet # 4) Låg (P4)
En defekt med låg prioritet indikerar att det definitivt finns ett problem, men det behöver inte åtgärdas för att matcha 'exit' -kriterierna. Detta måste dock åtgärdas innan GA är klar. Vanligtvis kan vissa skrivfel eller till och med kosmetiska fel som diskuterats tidigare kategoriseras här.
Ibland öppnas också defekter med låg prioritet för att föreslå några förbättringar av den befintliga designen eller en begäran om att implementera en liten funktion för att förbättra användarupplevelsen.
Denna defekt kan lösas i framtiden och behöver ingen omedelbar uppmärksamhet och Låg svårighetsgrad defekter faller inom denna kategori.
Som redan diskuterat avgör prioritet hur snabbt defektens omloppstid måste vara. Om det finns flera fel, avgör prioriteten vilken defekt som måste åtgärdas och verifieras omedelbart kontra vilken defekt som kan åtgärdas lite senare.
Vad är svårighetsgrad?
Svårighetsgrad definierar i vilken utsträckning en viss defekt skulle kunna påverka applikationen eller systemet.
Svårighetsgrad är en parameter för att beteckna implikationen av defekter i systemet - hur kritisk defekt är och vilken påverkan har defekten på hela systemets funktionalitet? Svårighetsgraden är en parameter som ställs in av testaren medan han öppnar en defekt och huvudsakligen kontrollerar testaren. Återigen har olika organisationer olika verktyg att använda för defekter, men på generisk nivå är dessa följande svårighetsgrader:
Till exempel, Tänk på följande scenarier
- Om användaren försöker göra onlineshopping och applikationen inte laddas eller servern är inte tillgänglig visas ett meddelande.
- Användaren utför att lägga till en artikel i kundvagnen, antalet mängder som läggs till är felaktigt / fel produkt läggs till.
- Användaren gör betalningen och efter betalningen förblir ordern i kundvagnen som reserverad istället bekräftad.
- Systemet accepterar beställningen men slutligen avbryter beställningen efter en halvtimme på grund av eventuella problem.
- Systemet accepterar ”Lägg i varukorg” endast genom att dubbelklicka istället för på ett enda klick.
- Knappen Lägg till i kundvagn är stavad som Lägg i kundvagn.
Vad skulle användarupplevelsen vara om något av ovanstående scenarier kunde hända?
I stort sett kan bristerna klassificeras enligt följande:
# 1) Kritisk (S1)
En defekt som helt hindrar eller blockerar testning av produkten / funktionen är en kritisk defekt. Ett exempel kan vara i fallet med UI-test där UI bara går igenom en guide eller hänger i en ruta eller inte går längre för att utlösa funktionen. Eller i vissa andra fall, när den utvecklade funktionen saknas i byggnaden.
Av någon anledning, om applikationen kraschar eller om den blir oanvändbar / inte kan gå vidare, kan defekten klassificeras under kritisk svårighetsgrad.
Eventuella katastrofala systemfel kan leda till att användaren inte kan använda applikationerna kan klassificeras under kritisk svårighetsgrad
Till exempel, I e-postleverantören som Yahoo eller Gmail, efter att ha skrivit rätt användarnamn och lösenord, istället för att logga in, kraschar systemet eller kastar felmeddelandet, denna defekt klassificeras som kritisk eftersom denna defekt gör hela applikationen oanvändbar.
Scenariot på punkt 1 som diskuterats ovan kan klassificeras som kritisk defekt, eftersom onlineapplikationen blir helt oanvändbar.
# 2) Major (S2)
Alla viktiga funktioner som implementeras och som inte uppfyller sina krav / användningsfall och beter sig annorlunda än förväntat kan klassificeras under större allvar.
En stor defekt uppstår när funktionaliteten fungerar grovt borta från förväntningarna eller inte gör vad den ska göra. Ett exempel kan vara: Säg att ett VLAN måste distribueras på växeln och att du använder en UI-mall som utlöser den här funktionen. När denna mall för att konfigurera VLAN misslyckas på omkopplaren klassificeras den som en allvarlig nackdel med funktionaliteten.
Till exempel, I e-postleverantören som Yahoo eller Gmail, när du inte får lägga till mer än en mottagare i CC-sektionen, klassificeras denna defekt som den stora defekten eftersom programmets huvudfunktion inte fungerar korrekt.
Vad förväntas beteendet för CC-avsnittet i e-post, det bör tillåta användaren att lägga till flera användare. Så när programmets huvudfunktionalitet inte fungerar ordentligt eller när den beter sig annorlunda än förväntat är det en stor defekt.
Scenarierna i punkt 2 och 3 som diskuterats ovan kan klassificeras som större defekter, eftersom ordern förväntas gå smidigt till nästa fas i orderlivscykeln men i verkligheten varierar den i beteende.
Varje defekt som kan leda till felaktig uthållighet, dataproblem eller fel applikationsbeteende kan i stort sett klassificeras under allvarlighetsgraden.
# 3) Mindre / måttlig (S3)
Alla funktioner som implementeras som inte uppfyller kraven / användningsfallet och beter sig annorlunda än förväntat men effekten är försumbar till viss del eller inte har någon större inverkan på applikationen, kan klassificeras under Mindre svårighetsgrad.
En måttlig defekt uppstår när produkten eller applikationen inte uppfyller vissa kriterier eller fortfarande uppvisar onaturligt beteende, men funktionaliteten som helhet påverkas inte. Till exempel i VLAN-mallen som distribueras ovan, skulle en måttlig eller normal defekt uppstå när mallen distribueras framgångsrikt på växeln, men det finns ingen indikation som skickas till användaren.
Till exempel, I e-postleverantören som Yahoo eller Gmail finns det ett alternativ som heter 'Villkor' och i det alternativet kommer det att finnas flera länkar angående villkoren och villkoren på webbplatsen, när en av de flera länkarna inte fungerar bra, det kallas som mindre svårighetsgrad eftersom det bara påverkar mindre funktionalitet i applikationen och det har ingen stor inverkan på applikationens användbarhet.
Scenariot på punkt 5 som diskuterats ovan kan klassificeras som mindre defekt, eftersom det inte finns någon dataförlust eller fel i systemflödesordningen utan ett litet besvär när det gäller användarupplevelse.
Dessa typer av defekter resulterar i minimal förlust av funktionalitet eller användarupplevelse.
# 4) Låg (S4)
Alla kosmetiska defekter inklusive stavfel eller inriktningsfrågor eller typsnitt kan klassificeras under låg svårighetsgrad.
Ett mindre fel med låg svårighetsgrad inträffar när det nästan inte påverkar funktionaliteten men det är fortfarande en giltig defekt som bör korrigeras. Exempel på detta kan inkludera stavfel i felmeddelanden som skrivs ut till användare eller defekter för att förbättra utseendet på en funktion.
Till exempel, I e-postleverantören som Yahoo eller Gmail skulle du ha lagt märke till 'Licenssidan'. Om det finns några stavfel eller feljustering på sidan klassificeras denna defekt som låg.
Scenariot på punkt 6 som diskuterats ovan kan klassificeras som låg defekt, eftersom knappen Lägg till visas i fel hölje. Denna typ av fel kommer inte att ha någon inverkan på systembeteende eller datapresentation eller dataförlust eller dataflöde eller ens användarupplevelse men kommer att vara mycket kosmetisk.
Sammanfattningsvis visar följande figur den breda defektklassificeringen baserat på svårighetsgrad och prioritet:
Exempel
Som redan nämnts, eftersom olika organisationer använder olika typer av verktyg för spårning av fel och dess relaterade processer, blir det ett vanligt spårningssystem mellan olika ledningsnivåer och teknisk personal.
Eftersom Defekt-svårighetsgrad ligger mer inom funktionaliteten, ställer testingenjören in svårighetsgraden för defekten. Ibland deltar utvecklarna i att påverka defektens svårighetsgrad, men mest beror det på testaren eftersom han utvärderar hur mycket en viss funktion kan påverka den övergripande funktionen.
Å andra sidan, när det gäller att ställa in defektprioritet, även om initialt defektupprätthållaren prioriterar, definieras den faktiskt av Product Manager eftersom han har en övergripande bild av produkten och hur snabbt en viss defekt måste åtgärdas . En testare är inte en idealisk person för att ställa in defektprioriteten.
Chockerande som detta kan tyckas, det finns två distinkta exempel på varför:
Exempel 1) Tänk på att det finns en situation där användaren finner ett fel i namnet på själva produkten eller något problem med UI-dokumentationen. En testare öppnar normalt en mindre / kosmetisk defekt och kan vara väldigt enkel att fixa, men när det gäller produktens utseende och känsla / användarupplevelse kan det orsaka allvarlig påverkan.
Exempel 2) Det kan finnas vissa förhållanden under vilka en viss defekt uppstår som kan vara en extremt sällsynt eller ingen möjlighet att träffa i kundmiljön. Även om det funktionellt sett kan detta verka som en högprioritetsfel för en testare, med tanke på dess sällsynthet och höga kostnader att fixa - detta skulle klassificeras som en lågprioritetsfel.
Följaktligen ställs defektprioriteten i allmänhet av produktchefen i ett möte med 'defekt triage'.
Olika nivåer
Prioritet och svårighetsgrad har några klassificeringar bland dem som hjälper till att avgöra hur defekten måste hanteras. Många olika organisationer har olika loggningsverktyg för fel , så nivåerna kan variera.
Låt oss ta en titt på de olika nivåerna för både prioritet och svårighetsgrad.
ny värld av Warcraft privat server
- Hög prioritet, hög svårighetsgrad
- Hög prioritet, låg svårighetsgrad
- Hög svårighetsgrad, låg prioritet
- Låg svårighetsgrad, låg prioritet
Följande figur visar klassificeringen av kategorierna i ett enda utdrag.
# 1) Hög svårighetsgrad och hög prioritet
Alla kritiska / större affärsfall misslyckas automatiskt till denna kategori.
Eventuella defekter på grund av vilka testningen inte kan fortsätta till någon kostnad eller orsakar att ett allvarligt systemfel faller inom denna kategori. Till exempel, att klicka på en viss knapp laddas inte själva funktionen. Eller att utföra en viss funktion tar ner servern konsekvent och orsakar dataförlust. De röda linjerna i figuren ovan indikerar sådana fel.
Till exempel,
Systemet kraschar efter att du har gjort betalningen eller när du inte kan lägga till artiklarna i kundvagnen, är denna defekt markerad som defekt med hög allvarlighetsgrad och hög prioritet.
Ett annat exempel skulle vara en ATM-försäljningsvalutafunktion där maskinen efter att ha angett rätt användarnamn och lösenord inte ger ut pengar utan drar av det överförda från ditt konto.
# 2) Hög prioritet och låg svårighetsgrad
Eventuella mindre allvarlighetsfel som direkt kan påverka användarupplevelsen marknadsförs automatiskt till denna kategori.
Fel som måste åtgärdas men som inte påverkar applikationen omfattas av denna kategori.
Till exempel, funktionen förväntas visa ett visst fel för användaren med avseende på dess returkod. I detta fall kommer koden att kasta ett fel, men meddelandet måste vara mer relevant för den genererade returkoden. De blå linjerna i figuren indikerar sådana fel.
Till exempel,
Företagets logotyp på förstasidan är fel, det anses vara Hög prioritet och låg svårighetsgrad defekt .
Exempel 1) På webbshoppingwebbplatsen när FrontPage-logotypen stavas fel, till exempel i stället för Flipkart stavas den som Flipkart.
Exempel 2) I banklogotypen, istället för ICICI, skrivs den som ICCCI.
När det gäller funktionalitet påverkar det inte någonting så vi kan markera som låg svårighetsgrad, men det har en inverkan på användarupplevelsen. Denna typ av fel måste fixas med hög prioritet även om de har mycket mindre inverkan på applikationssidan.
# 3) Hög svårighetsgrad och låg prioritet
Varje defekt som funktionellt inte uppfyller kraven eller som har några funktionella konsekvenser för systemet men som avaktiveras till baksätet av intressenterna när det gäller affärskritik, befordras automatiskt till denna kategori.
Fel som måste åtgärdas men inte omedelbart. Detta kan specifikt inträffa under ad hoc-testning. Det betyder att funktionaliteten påverkas i stor utsträckning, men observeras endast när vissa ovanliga ingångsparametrar används.
Till exempel, en viss funktionalitet kan endast användas i en senare version av firmware, så för att verifiera detta - testaren nedgraderar faktiskt sitt system och utför testet och observerar en allvarlig funktionalitetsproblem som är giltigt. I ett sådant fall klassificeras bristerna i denna kategori med rosa linjer, eftersom slutanvändare normalt förväntas ha en högre version av firmware.
Till exempel,
På en webbplats för sociala nätverk, om en betaversion av en ny funktion släpps med inte många aktiva användare som använder den anläggningen från och med idag. Varje defekt som finns i denna funktion kan klassificeras som låg prioritet eftersom funktionen tar sittplats på grund av att företagsklassificeringen inte är viktig.
Även om den här funktionen har en funktionsfel, eftersom den inte påverkar slutkunderna direkt, kan en affärsintressent klassificera defekten under låg prioritet, även om den har en allvarlig funktionell inverkan på applikationen.
Detta är ett fel med hög svårighetsgrad men kan prioriteras till låg prioritet eftersom det kan fixas med nästa release som en begäran om ändring. Affärsintressenter prioriterar också den här funktionen som en sällan använd funktion och påverkar inte andra funktioner som har direkt inverkan på användarupplevelsen. Denna typ av fel kan klassificeras under Hög svårighetsgrad men låg prioritet kategori.
# 4) Låg svårighetsgrad och låg prioritet
Eventuella stavfel / typsnitt / feljustering i avsnitt 3rdeller 4thsidan i applikationen och inte på huvudsidan eller förstasidan / titeln.
Dessa defekter klassificeras i de gröna linjerna som visas i figuren och uppstår när det inte finns någon funktionell påverkan, men fortfarande inte uppfyller standarderna i liten utsträckning. Generellt klassificeras kosmetiska fel eller säger dimensioner för en cell i en tabell på användargränssnittet här.
Till exempel,
Om webbplatsens sekretesspolicy har ett stavfel, ställs denna defekt in som Låg svårighetsgrad och låg prioritet.
Riktlinjer
Nedan följer vissa riktlinjer som varje testare måste försöka följa:
- Först och främst, förstå begreppen prioritet och svårighetsgrad. Undvik att förväxla varandra och använda dem omväxlande. I linje med detta följer du riktlinjerna för allvarlighetsgrad som din organisation / team har publicerat så att alla är på samma sida.
- Välj alltid svårighetsgraden baserat på frågestypen eftersom detta påverkar dess prioritet. Några exempel är:
- För en fråga som är kritisk, som att hela systemet går ner och ingenting kan göras - denna svårighetsgrad ska inte användas för att åtgärda programfel.
- För en fråga som är viktig, till exempel i de fall där funktionen inte fungerar som förväntat - kan denna svårighetsgrad användas för att ta itu med nya funktioner eller förbättringar av det nuvarande arbetet.
Kom ihåg att att välja rätt svårighetsgrad kommer i sin tur att ge defekten, det är rätt prioritet.
- Som testare - förstå hur en viss funktionalitet snarare drills ner ytterligare - förstå hur ett visst scenario eller testfall skulle påverka slutanvändaren. Detta innebär mycket samarbete och interaktion med utvecklingsteamet, affärsanalytiker, arkitekter, testledare, utvecklingsledare. I dina diskussioner måste du också ta hänsyn till hur mycket tid det skulle ta att åtgärda defekten baserat på dess komplexitet och tid för att verifiera denna defekt.
- Till sist , det är alltid produktägaren som har vetorätten att frigöra defekten ska åtgärdas. Men eftersom defekt-triagesessionerna innehåller olika medlemmar för att presentera sitt perspektiv på defekten i ett fall, vid en sådan tidpunkt om utvecklarna och testarna är synkroniserade, hjälper det säkert att påverka beslutet.
Slutsats
När du öppnar defekter är det en testares ansvar att tilldela rätt svårighetsgrad till defekterna. Felaktig svårighetsgrad och därmed prioriterad kartläggning kan ha mycket drastiska konsekvenser för den totala STLC-processen och produkten som helhet. I flera anställningsintervjuer - det ställs flera frågor om prioritet och svårighetsgrad för att säkerställa att du som testare har dessa begrepp oklanderligt tydliga i ditt sinne.
Vi hade också sett liveexempel på hur man klassificerar defekten under olika skopor för allvar / prioritet. Nu önskar jag att du hade tillräckligt med förtydliganden om defektklassificering både i svårighetsgraden / prioriterade skopor.
Hoppas att den här artikeln är en komplett guide för att förstå defektprioriteten och svårighetsgraden. Låt oss veta dina tankar / frågor i kommentarerna nedan.
Rekommenderad läsning
- Vad är testbaserad testteknik?
- Vad är defekt / bug-livscykel vid programvarutestning? Defekt livscykelhandledning
- Process för defekthantering: Hur man hanterar en defekt effektivt
- Hur man reproducerar en icke reproducerbar defekt och gör din testansträngning värt det
- 7 Principer för programvarutestning: Defektkluster och Pareto-princip
- Metoder och tekniker för förebyggande av defekter
- Exakt skillnad mellan verifiering och validering med exempel
- 3 strategier för att hantera ett blockeringsfel