what is defect bug life cycle software testing
Introduktion til defekt livscyklus
I denne vejledning vil jeg tale om en defekts livscyklus for at gøre dig opmærksom på de forskellige faser af en defekt, som en tester skal håndtere, mens han arbejder i et testmiljø.
Jeg har også tilføjet de hyppigst stillede interviewspørgsmål om Defect Life Cycle. Dette er vigtigt at vide om de forskellige tilstande for en defekt for at forstå en defekts livscyklus. Hovedintentionen med at udføre en testaktivitet er at kontrollere, om produktet har problemer / fejl.
Med hensyn til reelle scenarier kaldes fejl / fejl / fejl alle som bugs / defekter, og derfor kan vi sige, at hovedformålet med at udføre test er at sikre, at produktet er mindre tilbøjeligt til defekter (ingen defekter er en urealistisk situation ).
Nu opstår spørgsmålet, hvad en defekt er?
Hvad du lærer:
Hvad er en fejl?
En fejl er i enkle vendinger en fejl eller en fejl i en applikation, der begrænser den normale strøm af en applikation ved ikke at matche den forventede opførsel af en applikation med den aktuelle.
Fejlen opstår, når en udvikler begår en fejl under design eller opbygning af en applikation, og når denne fejl findes af en tester, betegnes den som en defekt.
Det er en testers ansvar at foretage en grundig test af en applikation for at finde så mange defekter som muligt for at sikre, at et kvalitetsprodukt når ud til kunden.
Det er vigtigt at forstå, om defektets livscyklus, før du går til workflowet og forskellige tilstande for defekten.
Lad os derfor vide mere om Defect Life Cycle.
Indtil videre diskuterede vi betydningen af defekt og dens relation i sammenhæng med testaktiviteten. Lad os nu gå til defektets livscyklus og forstå workflowet for en defekt og de forskellige tilstande for en defekt.
Defekt livscyklus i detaljer
En defekt livscyklus, også kendt som en bug livscyklus, er en cyklus af en defekt, hvorfra den går gennem at dække de forskellige tilstande i hele sit liv. Dette starter, så snart en ny defekt er fundet af en tester og slutter, når en tester lukker den defekt, hvilket sikrer, at den ikke bliver reproduceret igen.
Defekt arbejdsgang
Det er nu tid til at forstå den faktiske arbejdsgang i en Defect Life Cycle ved hjælp af et simpelt diagram som vist nedenfor.
Defektstater
# 1) Ny :Dette er den første tilstand af en defekt i Defect Life Cycle. Når der findes en ny defekt, falder den i en 'Ny' tilstand, og valideringer og test udføres på denne defekt i de senere stadier af Defect Life Cycle.
# 2) Tildelt: I dette trin tildeles udviklingsholdet en nyoprettet defekt til at arbejde på defekten. Dette tildeles af projektledelsen eller lederen af testteamet til en udvikler.
# 3) Åbn: Her starter udvikleren processen med at analysere defekten og arbejder om nødvendigt på at rette den. Hvis udvikleren føler, at manglen ikke er passende, kan den blive overført til en af nedenstående fire stater, nemlig Duplikat, udsat, afvist eller ikke en fejl -baseret på den specifikke grund.
Jeg vil diskutere disse fire stater om et stykke tid.
# 4) Fast: Når udvikleren er færdig med at løse en defekt ved at foretage de nødvendige ændringer, kan han markere defektens status som 'Fixed'.
# 5) Afventer gentest: Efter afhjælpning af defekten tildeler udvikleren defekten til testeren for at genprøve defekten ved deres afslutning, og indtil testeren arbejder på at genprøve defekten, forbliver defektens tilstand i 'Afventer gentest'.
# 6) Gentest: På dette tidspunkt starter testeren opgaven med at arbejde på gentest af defekten for at kontrollere, om defekten er rettet nøjagtigt af udvikleren i henhold til kravene eller ej.
# 7) Åbn igen: Hvis et problem fortsætter med manglen, tildeles det udvikleren igen til test, og defektens status ændres til 'Genåbning'.
# 8) Bekræftet: Hvis testeren ikke finder noget problem i defekten, efter at den er tildelt udvikleren til gentest, og han føler, at hvis fejlen er rettet nøjagtigt, bliver status for fejlen tildelt 'Bekræftet'.
# 9) Lukket: Når manglen ikke længere eksisterer, ændrer testeren status for manglen til 'Lukket'.
Få flere:
- Afvist: Hvis defekten ikke betragtes som en ægte fejl af udvikleren, markeres den som 'Afvist' af udvikleren.
- Duplikere: Hvis udvikleren finder manglen som den samme som enhver anden mangel, eller hvis begrebet defekten svarer til enhver anden defekt, ændres defektens status til 'Duplicate' af udvikleren.
- Udskudt: Hvis udvikleren føler, at manglen ikke er af meget vigtig prioritet, og den kan blive rettet i de næste udgivelser eller deromkring i et sådant tilfælde, kan han ændre defektens status som 'Udskudt'.
- Ikke et bug: Hvis defekten ikke har indflydelse på applikationens funktionalitet, ændres defektens status til 'Not a Bug'.
Det obligatoriske felter når en tester logger, er en ny fejl Build-version, Submit On, Product, Module, Severity, Synopsis og Description to Reproducer
På listen ovenfor kan du tilføje nogle valgfrie felter hvis du bruger en manuel fejlindsendelsesskabelon. Disse valgfri felter inkluderer kundenavn, browser, operativsystem, filvedhæftninger eller skærmbilleder.
Følgende felter forbliver enten specificerede eller tomme:
Hvis du har tilladelse til at tilføje felter Status for status, Prioritet og 'Tildelt til', kan du angive disse felter. Ellers indstiller Test Manager status, Fejlprioritet og tildeler fejlen til den respektive modulejer.
Se på den følgende defektcyklus
Ovenstående billede er ret detaljeret, og når du overvejer de vigtige trin i Bug Life Cycle, får du en hurtig idé om det.
Ved vellykket logføring gennemgås fejlen af udviklings- eller testmanageren. Testadministratoren kan indstille fejlstatus som Åben, kan tildele bug til udvikler, eller fejl kan udsættes indtil næste udgivelse.
Når en fejl tildeles en udvikler, og han / hun kan begynde at arbejde på den. Udvikleren kan indstille fejlstatus, som den ikke løser, kunne ikke reproducere, har brug for flere oplysninger eller 'løst'.
Hvis fejlstatus, der er indstillet af udvikleren, enten er 'Brug for mere information' eller Rettet, svarer QA med en bestemt handling. Hvis fejlen er rettet, bekræfter QA fejlen og kan indstille fejlstatus som bekræftet lukket eller genåbne.
Retningslinjer for implementering af defekt livscyklus
Nogle vigtige retningslinjer kan vedtages, inden du begynder at arbejde med Defect Life Cycle.
Disse er som følger:
- Det er meget vigtigt, at inden teamet begynder at arbejde på defektets livscyklus, forstår hele teamet tydeligt de forskellige tilstande for en defekt (diskuteret ovenfor).
- Defektets livscyklus bør dokumenteres korrekt for at undgå enhver forvirring i fremtiden.
- Sørg for, at hver person, der har fået tildelt en opgave, der er relateret til defektets livscyklus, skal forstå sit ansvar meget klart for bedre resultater.
- Hver person, der ændrer status for en defekt, skal være ordentligt opmærksom på denne status og skal give tilstrækkelige detaljer om status og grunden til at sætte denne status, så alle, der arbejder på den pågældende fejl, kan forstå årsagen til en sådan status af en fejl meget let.
- Fejlsporingsværktøjet skal håndteres med forsigtighed for at opretholde konsistensen mellem defekterne og dermed i workflowet i Defect Life Cycle.
Lad os derefter diskutere interviewspørgsmålene baseret på Defect Life Cycle.
sql udvikler interview spørgsmål og svar pdf
Vigtige ofte stillede spørgsmål eller interviewspørgsmål om bug livscyklus
Q # 1) Hvad er en defekt i perspektivet af softwaretest?
Svar: En defekt er enhver form for fejl eller fejl i applikationen, der begrænser den normale strøm af en applikation ved ikke at matche den forventede opførsel af en applikation med den aktuelle.
Spørgsmål nr. 2) Hvad er den største forskel mellem fejl, fejl og fejl?
Svar: Fejl: Hvis udviklerne finder ud af, at der er en uoverensstemmelse i den aktuelle og forventede opførsel af en applikation i udviklingsfasen, kalder de det en fejl.
Defekt: Hvis testere finder en uoverensstemmelse i den faktiske og forventede opførsel af en applikation i testfasen, kalder de det som en defekt.
Fiasko: Hvis kunder eller slutbrugere finder en uoverensstemmelse i den faktiske og forventede opførsel af en applikation i produktionsfasen, kalder de det en fiasko.
Q # 3) Hvad er status for en defekt, når den oprindeligt blev fundet?
Svar: Når en ny defekt er fundet, er den i 'Ny' tilstand. Dette er den oprindelige tilstand af en nyligt fundet defekt.
Spørgsmål nr. 4) Hvad er de forskellige tilstande for en defekt i defektens livscyklus, når en defekt er godkendt og løst af en udvikler?
Svar: Forskellige tilstande for en defekt, i dette tilfælde, er nye, tildelte, åbne, faste, afventende gentest, gentest, verificeret og lukket.
Spørgsmål nr. 5) Hvad sker der, hvis en tester stadig finder et problem i den fejl, der er rettet af en udvikler?
Svar: Testeren kan markere defektens tilstand som 'Genåbning', hvis han stadig finder et problem i den faste fejl, og manglen tildeles en udvikler til gentest.
Q # 6) Hvad er en producerbar defekt?
Svar: En defekt, der gentagne gange forekommer i hver udførelse, og hvis trin kan fanges i hver udførelse, så kaldes en sådan defekt en 'producerbar' defekt.
Q # 7) Hvilken type defekt er en ikke reproducerbar defekt?
Svar: En defekt, der ikke forekommer gentagne gange i hver udførelse og kun producerer i nogle tilfælde, og hvis trin som bevis skal fanges ved hjælp af skærmbilleder, kaldes en sådan defekt som en 'ikke reproducerbar' defekt.
Q # 8) Hvad er en fejlrapport?
Svar: En defektrapport er et dokument, der inkluderer rapporteringsoplysninger om defekten eller fejlen i applikationen, der forårsager den normale strøm af en applikation, der afviger fra dens forventede adfærd.
Q # 9) Hvilke detaljer er inkluderet i en fejlrapport?
Svar: En fejlrapport består af følgende detaljer:
Defekt-id, beskrivelse af defekten, funktionsnavn, testsagens navn, reproducerbar defekt eller ej, status for en defekt, sværhedsgrad og prioritet for en defekt, testers navn, testdato for manglen, build-version, hvor defekten blev fundet .
Og udvikleren, som manglen er tildelt, navnet på den person, der har rettet manglen, skærmbilleder af en defekt, der viser trinstrømmen, fastsættelse af datoen for en defekt, og den person, der har godkendt manglen.
Spørgsmål nr. 10) Hvornår ændres en defekt til en 'udsat' tilstand i defektens livscyklus?
Svar: Når en defekt, der er fundet, ikke er af meget stor betydning, og den, der kan blive løst i de senere udgivelser, flyttes til en 'udsat' tilstand i Defect Life Cycle.
Yderligere oplysninger om fejl eller fejl
- En defekt kan introduceres når som helst i Softwareudviklings livscyklus.
- Tidligere defekten er opdaget og fjernet, vil lavere være de samlede omkostninger ved kvalitet.
- Omkostningerne ved kvalitet minimeres, når manglen fjernes i samme fase, som den blev introduceret.
- Statisk test finder manglen, ikke en fejl. Omkostningerne minimeres, da fejlretning ikke er involveret.
- Ved dynamisk test afsløres tilstedeværelsen af en defekt, når den forårsager en fejl.
Defekter
| S. nr. | Oprindelig tilstand | Returneret stat | Bekræftelsestilstand |
|---|---|---|---|
| en | Indsaml information til den person, der er ansvarlig for reproduktion af manglen | Defekt afvises eller beder om mere information | Fejlen er løst og skal testes og lukkes |
| to | Stater er åbne eller nye | Stater afvises eller afklaring. | Stater er løst og verificeret. |
Ugyldig og duplikatrapport
- Nogle gange opstår der mangler, ikke på grund af kode, men på grund af testmiljø eller misforståelse, bør en sådan rapport lukkes som en ugyldig fejl.
- I tilfælde af duplikatrapport opbevares en, og en lukkes som duplikat. Nogle ugyldige rapporter accepteres af manager.
- Testmanageren ejer den overordnede defektstyring og proces, og det tværfunktionelle team for defektstyringsværktøj er generelt ansvarlig for styring af rapporterne.
- Deltagerne inkluderer Test Manager, Developers, PM, Production Manager og andre interessenter, der har interesse.
- Komité for mangelforvaltning skal bestemme gyldigheden af hver defekt og afgøre, hvornår der skal rettes eller udsættes. For at bestemme dette skal du overveje omkostninger, risici og fordele ved ikke at rette en fejl.
- Hvis manglen skal afhjælpes, skal dens prioritet bestemmes.
Defektdata
- Personens navn.
- Testtype
- Problemoversigt
- Detaljeret beskrivelse af defekt.
- Trin til reproduktion
- Livscyklusfase
- Arbejdsprodukt, hvor Defekt blev introduceret.
- Alvorlighed og prioritet
- Delsystem eller komponent, hvor defekten introduceres.
- Projektaktivitet, der opstår, når fejlen introduceres.
- Identifikationsmetode
- Fejltype
- Projekt og produkt, hvor problemet findes
- Nuværende ejer
- Den aktuelle rapporttilstand
- Arbejdsprodukt, hvor defekt opstod.
- Indflydelse på projektet
- Risiko, tab, mulighed og fordele forbundet med at rette eller ikke rette manglen.
- Datoer, hvor der opstår forskellige defekte livscyklusfaser.
- Beskrivelsen af, hvordan fejlen blev løst, og anbefalinger til test.
- Referencer
Process kapacitet
- Introduktion, påvisning og fjernelse af oplysninger -> Forbedre detektering af defekter og omkostninger ved kvalitet.
- Introduktion -> Prædatoranalyse af den proces, hvor det største antal defekter introduceres for at reducere det samlede antal defekter.
- Fejlrodsinfo -> find understregede grunde til manglen for at reducere det samlede antal fejl.
- Defektkomponentoplysninger -> Udfør defektklyngeanalyse.
Konklusion
Dette handler om Defect Life Cycle og Management.
Jeg håber, du skal have fået enorm viden om en mangels livscyklus. Denne tutorial hjælper dig igen, mens du arbejder med manglerne i fremtiden på en nem måde.
Anbefalet læsning
- Hvad er defektbaseret testteknik?
- Hvad er STLC (Software Testing Life Cycle)?
- Bugzilla Tutorial: Defect Management Tool Hands-on Tutorial
- Java-tråde med metoder og livscyklus
- Softwaretest handler om ideer (og hvordan man genererer dem)
- Dybdegående formørkelsesvejledninger til begyndere
- Process for defekthåndtering: Sådan håndteres en defekt effektivt
- Eksempel på fejlrapporter til web- og produktapplikationer