Meny

Vad är defekt / bug-livscykel vid programvarutestning? Defekt livscykelhandledning

what is defect bug life cycle software testing

Prova Vårt Instrument För Att Eliminera Problem

Introduktion till Defect Life Cycle

I denna handledning kommer jag att prata om livscykeln för en defekt för att göra dig medveten om de olika faserna av en defekt som en testare måste hantera när han arbetar i en testmiljö.

Jag har också lagt till de vanligaste intervjufrågorna om Defect Life Cycle. Detta är viktigt att veta om de olika tillstånden för en defekt för att förstå livscykeln för en defekt. Huvudsyftet med att utföra en testaktivitet är att kontrollera om produkten har några problem / fel.

Defekt livscykelhandledning

När det gäller verkliga scenarier kallas fel / misstag / fel alla som buggar / defekter och därför kan vi säga att huvudmålet med att göra test är att försäkra att produkten är mindre benägen för defekter (inga defekter är en orealistisk situation ).

Nu uppstår frågan vad en defekt är?

Vad du kommer att lära dig:

Vad är en defekt?

En defekt är i enkla termer ett fel eller ett fel i en applikation som begränsar det normala flödet av en applikation genom att inte matcha det förväntade beteendet hos en applikation med den faktiska.

Defekten uppstår när ett misstag görs av en utvecklare under utformningen eller byggandet av en applikation och när denna brist upptäcks av en testare kallas den som en defekt.

Det är en testares ansvar att göra en grundlig testning av en applikation för att hitta så många defekter som möjligt för att säkerställa att en kvalitetsprodukt når kunden.

Det är viktigt att förstå om livscykeln för defekter innan du går till arbetsflödet och olika tillstånd för defekten.

Låt oss därför veta mer om Defect Life Cycle.

Hittills har vi diskuterat innebörden av defekt och dess relation i sammanhang med testaktiviteten. Låt oss nu gå till defektens livscykel och förstå arbetsflödet för en defekt och de olika tillstånden för en defekt.

Defekt livscykel i detalj

En defektlivscykel, även känd som en Bug-livscykel, är en cykel av en defekt från vilken den går genom att täcka de olika tillstånden under hela sitt liv. Detta börjar så snart varje ny defekt upptäcks av en testare och upphör när en testare stänger den defekten och försäkrar att den inte reproduceras igen.

bästa rengöringsverktyget för pc

Defekt arbetsflöde

Det är nu dags att förstå det faktiska arbetsflödet för en Defect Life Cycle med hjälp av ett enkelt diagram som visas nedan.

Defekt Livscykel

Defektstater

# 1) Nytt :Detta är det första tillståndet för en defekt i Defect Life Cycle. När någon ny defekt upptäcks, faller den i ett ”nytt” tillstånd, och valideringar och test utförs på denna defekt i de senare stadierna av Defect Life Cycle.

# 2) Tilldelad: I det här steget tilldelas utvecklingsgruppen en nyskapad defekt för att arbeta med defekten. Detta tilldelas av projektledaren eller chefen för testteamet till en utvecklare.

# 3) Öppna: Här startar utvecklaren processen att analysera defekten och arbetar med att åtgärda den, om det behövs. Om utvecklaren anser att defekten inte är lämplig kan den överföras till något av nedanstående fyra tillstånd, nämligen Duplicera, skjutas upp, avvisas eller inte ett fel -baserad på den specifika anledningen.

Jag kommer att diskutera dessa fyra stater på ett tag.

# 4) Fast: När utvecklaren avslutar uppgiften att åtgärda en defekt genom att göra de nödvändiga ändringarna kan han markera defektens status som 'Fixed'.

# 5) Väntande omprövning: Efter att ha åtgärdat defekten tilldelar utvecklaren defekten till testaren för att testa igen defekten i slutet, och tills testaren arbetar på att testa defekten kvarstår defektens tillstånd i 'Väntande omprövning'.

# 6) Testa om: Vid denna tidpunkt startar testaren uppgiften att arbeta med omprövning av defekten för att verifiera om defekten fixas korrekt av utvecklaren enligt kraven eller inte.

# 7) Öppna igen: Om något problem kvarstår i defekten kommer det att tilldelas utvecklaren igen för testning och statusen för defekten ändras till 'Öppna igen'.

# 8) Verifierad: Om testaren inte hittar något problem i defekten efter att ha tilldelats utvecklaren för omprövning och han känner att om defekten har åtgärdats exakt så tilldelas defektens status till 'Verifierad'.

# 9) Stängd: När defekten inte längre finns, ändrar testaren defektens status till 'Stängd'.

Några fler:

  • Avvisade: Om defekten inte betraktas som en verklig defekt av utvecklaren markeras den som ”Avvisad” av utvecklaren.
  • Duplicera: Om utvecklaren finner att defekten är densamma som alla andra defekter eller om konceptet med defekten matchar någon annan defekt ändras defektens status till 'Duplicate' av utvecklaren.
  • Uppskjuten: Om utvecklaren upplever att defekten inte är av mycket viktig prioritet och den kan fixas i nästa version eller så i ett sådant fall kan han ändra defektens status som 'Uppskjuten'.
  • Inte ett fel: Om defekten inte påverkar applikationens funktionalitet ändras defektens status till 'Not a Bug'.

De obligatoriska fält när en testare loggar är något nytt fel byggversion, skicka på, produkt, modul, svårighetsgrad, översikt och beskrivning som ska reproduceras

I listan ovan kan du lägga till några valfria fält om du använder en manuell mall för inlämning av fel. Dessa valfria fält inkluderar kundnamn, webbläsare, operativsystem, filbilagor eller skärmdumpar.

Följande fält förblir antingen angivna eller tomma:
Om du har behörighet att lägga till felstatus-, prioritets- och 'Tilldelad till' -fält kan du ange dessa fält. I annat fall kommer Testhanteraren att ställa in status, felprioritet och tilldela felet till respektive modulägare.

Titta på följande defektcykel

Defekt / Bug Livscykel

Ovanstående bild är ganska detaljerad och när du överväger de viktiga stegen i Bug Life Cycle får du en snabb uppfattning om det.

Vid lyckad loggning granskas felet av utvecklings- eller testhanteraren. Testhanteraren kan ställa in felstatusen som Open, kan tilldela buggen till utvecklaren eller fel kan skjutas upp till nästa release.

När ett fel tilldelas en utvecklare och han / hon kan börja arbeta med det. Utvecklaren kan ställa in felstatusen så att den inte fixas, det gick inte att reproducera, behöver mer information eller 'fixad'.

Om felstatusen som utvecklaren har ställt in antingen är ”Behöver du mer information” eller Fixad, svarar QA med en specifik åtgärd. Om felet är rättat verifierar QA felet och kan ställa in buggstatusen som verifierad stängd eller öppna igen.

Riktlinjer för implementering av defektlivscykel

Några viktiga riktlinjer kan antas innan du börjar arbeta med Defect Life Cycle.

Dessa är som följer:

  • Det är mycket viktigt att hela teamet förstår de olika tillstånden för en defekt (diskuteras ovan) innan de börjar arbeta med Defect Life Cycle.
  • Defektlivscykeln bör dokumenteras ordentligt för att undvika förvirring i framtiden.
  • Se till att varje person som har tilldelats någon uppgift relaterad till livscykeln för defekter bör förstå sitt ansvar mycket tydligt för bättre resultat.
  • Varje person som ändrar status för en defekt bör vara medveten om den statusen och bör ge tillräckligt med information om statusen och anledningen till att sätta den statusen så att alla som arbetar med just den defekten kan förstå orsaken till en sådan status av en defekt mycket lätt.
  • Verktyget för spårning av defekter bör hanteras med försiktighet för att bibehålla enhetligheten mellan defekterna och därmed i arbetsflödet för Defect Life Cycle.

Låt oss sedan diskutera intervjufrågorna baserat på Defect Life Cycle.

Viktiga frågor eller intervjufrågor om bug-livscykeln

F # 1) Vad är en defekt i perspektivet av programvarutestning?

Svar: En defekt är någon form av fel eller fel i applikationen som begränsar det normala flödet av en applikation genom att matcha det förväntade beteendet hos en applikation med den faktiska.

F # 2) Vad är den största skillnaden mellan fel, fel och fel?

Svar: Fel: Om utvecklarna upptäcker att det saknas en matchning mellan det faktiska och förväntade beteendet hos en applikation i utvecklingsfasen kallar de det ett fel.

Defekt: Om testare hittar en ojämnhet i det faktiska och förväntade beteendet hos en applikation i testfasen kallar de det som en defekt.

Fel: Om kunder eller slutanvändare hittar en ojämnhet i det faktiska och förväntade beteendet hos en applikation i produktionsfasen kallar de det ett misslyckande.

F # 3) Vilken status har en defekt när den ursprungligen hittas?

Svar: När en ny defekt upptäcks är den i ”Nytt” tillstånd. Detta är det initiala tillståndet för en nyligen upptäckt defekt.

F # 4) Vilka är de olika tillstånden för en defekt i defektens livscykel när en defekt godkänns och fixas av en utvecklare?

Svar: Olika tillstånd för en defekt, i detta fall, är nya, tilldelade, öppna, fasta, väntande omprövning, omprövning, verifierad och stängd.

F # 5) Vad händer om en testare fortfarande hittar ett problem i defekten som åtgärdas av en utvecklare?

Svar: Testaren kan markera defektens tillstånd som ”Återöppna” om han fortfarande hittar ett problem i den fixade defekten och defekten tilldelas en utvecklare för omprövning.

F # 6) Vad är en produktionsbar defekt?

Svar: En defekt som uppträder upprepade gånger i varje utförande och vars steg kan fångas i varje utförande, då kallas en sådan defekt en ”producerbar” defekt.

F # 7) Vilken typ av defekt är en inte reproducerbar defekt?

Svar: En defekt som inte uppträder upprepade gånger i varje utförande och endast producerar i vissa fall och vars steg som bevis måste fångas med hjälp av skärmdumpar, kallas en sådan defekt som en ”inte reproducerbar” defekt.

F # 8) Vad är en felrapport?

Svar: En defektrapport är ett dokument som innehåller rapporteringsinformation om felet eller felet i applikationen som orsakar det normala flödet av en applikation som avviker från dess förväntade beteende.

F # 9) Vilka detaljer ingår i en felrapport?

Svar: En felrapport består av följande detaljer:

Defekt-ID, beskrivning av defekten, funktionsnamn, testfallets namn, reproducerbar defekt eller inte, status för en defekt, svårighetsgrad och prioritet för en defekt, testarens namn, testdatum för defekten, byggversion som defekten upptäcktes i .

Och utvecklaren till vilken defekten har tilldelats, namnet på den person som har åtgärdat defekten, skärmdumpar av en defekt som visar flödet av stegen, fastställande av datumet för en defekt och den person som har godkänt defekten.

F # 10) När ändras en defekt till ett 'uppskjuten' tillstånd i defektens livscykel?

Svar: När en defekt som upptäcks inte är av mycket stor betydelse och den som kan fixas i de senare utsläppen flyttas till ett ”uppskjuten” tillstånd i Defect Life Cycle.

Ytterligare information om fel eller fel

  • En defekt kan införas när som helst i livscykeln för programvaruutveckling.
  • Tidigare defekten upptäcktes och avlägsnades kommer den totala kostnaden för kvalitet att vara lägre.
  • Kvaliteten på kvalitet minimeras när defekten avlägsnas i samma fas som den infördes.
  • Statisk testning finner defekten, inte ett misslyckande. Kostnaden minimeras eftersom felsökning inte är involverad.
  • Vid dynamisk testning avslöjas närvaron av en defekt när den orsakar ett fel.

Defekter

S.No. Initialtillstånd Återvänt stat Bekräftelsestatus
ettSamla information till den person som är ansvarig för att reproducera defektenDefekt avvisas eller begärs mer informationDefekten är fixad och bör testas och stängas
tvåStaterna är öppna eller nyaStater avvisas eller förtydligande.Stater är lösta och verifierade.

Ogiltig och duplicerad felrapport

  • Ibland uppstår fel, inte på grund av kod utan på grund av testmiljö eller missförstånd, en sådan rapport bör stängas som en ogiltig defekt.
  • När det gäller Duplicate Report hålls en och en stängs som en duplikat. Någon ogiltig rapport accepteras av chefen.
  • Testchefen äger den övergripande defekthanteringen och processen och det tvärfunktionella teamet för defekthanteringsverktyg ansvarar generellt för hanteringen av rapporterna.
  • Deltagare inkluderar Test Manager, Developers, PM, Production Manager och andra intressenter som har intresse.
  • Kommittén för defekthantering bör bestämma giltigheten för varje defekt och avgöra när den ska fixas eller skjutas upp. För att fastställa detta, överväga kostnad, risker och nytta av att inte åtgärda fel.
  • Om defekten måste åtgärdas måste dess prioritet bestämmas.

Defektdata

  • Personens namn.
  • Typ av testning
  • Problemöversikt
  • Detaljerad beskrivning av defekt.
  • Steg för att reproducera
  • Livscykelfas
  • Arbetsprodukt där Defect introducerades.
  • Svårighetsgrad och prioritet
  • Delsystem eller komponent där defekten införs.
  • Projektaktivitet som inträffar när defekten introduceras.
  • Identifieringsmetod
  • Typ av defekt
  • Projekt och produkt där problemet finns
  • Nuvarande ägare
  • Den nuvarande rapporten
  • Arbetsprodukt där Defekt uppstod.
  • Påverkan på projektet
  • Risk, förlust, möjlighet och fördelar förknippade med att fixa eller inte fixa defekten.
  • Datum när olika defekts livscykelfaser inträffar.
  • Beskrivningen av hur felet åtgärdades och rekommendationer för testning.
  • Referenser

Processkapacitet

  • Introduktion, upptäckt och borttagningsinformation -> Förbättra upptäckt av defekter och kvalitetskostnad.
  • Inledning -> Prätoranalys av processen där det största antalet defekter införs för att minska det totala antalet defekter.
  • Felinformation rot -> hitta understrykningsskäl för defekten för att minska det totala antalet fel.
  • Defektkomponentinformation -> Utför analys av defektkluster.

Slutsats

Det här handlar om Defect Life Cycle and Management.

Jag hoppas att du måste ha fått enorm kunskap om en livscykel för en defekt. Denna handledning kommer i sin tur att hjälpa dig när du arbetar med defekterna i framtiden på ett enkelt sätt.

Rekommenderad läsning

^