what is defect bug life cycle software testing
Introduksjon til defekt livssyklus
I denne opplæringen vil jeg snakke om livssyklusen til en defekt for å gjøre deg oppmerksom på de forskjellige stadiene av en defekt som en tester må håndtere mens han arbeider i et testmiljø.
Jeg har også lagt til de ofte stilte intervjuspørsmålene om Defect Life Cycle. Dette er viktig å vite om de forskjellige tilstandene til en mangel for å forstå livssyklusen til en mangel. Hovedintensjonen med å utføre en testaktivitet er å kontrollere om produktet har problemer / feil.
Når det gjelder reelle scenarier, blir feil / feil / feil referert til som bugs / defekter, og derfor kan vi si at hovedmålet med å gjøre testing er å sikre at produktet er mindre utsatt for mangler (ingen feil er en urealistisk situasjon ).
Nå oppstår spørsmålet om hva en defekt er?
Hva du vil lære:
Hva er en feil?
En feil er i enkle termer en feil eller en feil i et program som begrenser den normale strømmen til et program ved å ikke matche den forventede oppførselen til en applikasjon med den faktiske.
Mangelen oppstår når en feil gjøres av en utvikler under utformingen eller byggingen av en applikasjon, og når denne feilen blir funnet av en tester, blir den betegnet som en mangel.
Det er en testers ansvar å gjøre grundige tester av en applikasjon for å finne så mange mangler som mulig for å sikre at et kvalitetsprodukt når kunden.
Det er viktig å forstå om livssyklusen til mangler før du går til arbeidsflyten og forskjellige tilstander til feilen.
java server side programmering intervju spørsmål
La oss derfor få vite mer om Defect Life Cycle.
Så langt diskuterte vi betydningen av defekt og dens forhold i sammenheng med testaktiviteten. La oss nå gå til defektenes livssyklus og forstå arbeidsflyten til en defekt og de forskjellige tilstandene til en defekt.
Defekt livssyklus i detalj
En defeks livssyklus, også kjent som en bug livssyklus, er en syklus av en defekt som den går gjennom dekker de forskjellige tilstandene i hele sitt liv. Dette starter så snart en ny defekt blir funnet av en tester og slutter når en tester lukker den feilen, og forsikrer at den ikke blir reprodusert igjen.
Defekt arbeidsflyt
Det er nå på tide å forstå den faktiske arbeidsflyten til en defekt livssyklus ved hjelp av et enkelt diagram som vist nedenfor.
Defektstater
# 1) Nyhet :Dette er den første tilstanden til en defekt i Defect Life Cycle. Når en ny defekt blir funnet, faller den i ‘Ny’ tilstand, og valideringer og testing utføres på denne feilen i de senere stadiene av Defect Life Cycle.
# 2) Tildelt: I dette stadiet tildeles utviklingsteamet en nyopprettet mangel for å jobbe med feilen. Dette tildeles av prosjektlederen eller lederen av testteamet til en utvikler.
# 3) Åpne: Her starter utvikleren prosessen med å analysere feilen og arbeider med å fikse den, om nødvendig. Hvis utvikleren føler at mangelen ikke er hensiktsmessig, kan den bli overført til noen av de fire statene nedenfor, nemlig Dupliser, utsatt, avvist eller ikke en feil -basert på den spesifikke årsaken.
Jeg vil diskutere disse fire statene på en stund.
# 4) Fast: Når utvikleren fullfører oppgaven med å fikse en feil ved å gjøre de nødvendige endringene, kan han markere statusen til feilen som 'Fixed'.
# 5) Venter på nytt test: Etter å ha løst feilen tildeler utvikleren defekten til testeren for å teste feilen på slutten, og til testeren arbeider med å teste feilen, forblir feilstatusen i 'Venter på nytt test'.
# 6) Test på nytt: På dette tidspunktet starter testeren oppgaven med å jobbe med omprøving av feilen for å verifisere om feilen er løst nøyaktig av utvikleren i henhold til kravene eller ikke.
# 7) Åpne på nytt: Hvis et problem vedvarer feilen, vil den bli tildelt utvikleren igjen for testing, og statusen til feilen blir endret til 'Åpne igjen'.
# 8) Bekreftet: Hvis testeren ikke finner noe problem i mangelen etter å ha blitt tildelt utvikleren for ny testing, og han føler at hvis feilen er løst nøyaktig, blir statusen til feilen tildelt 'Bekreftet'.
# 9) Stengt: Når mangelen ikke eksisterer lenger, endrer testeren statusen til feilen til 'Stengt'.
Få til:
- Avvist: Hvis mangelen ikke blir ansett som en reell mangel av utvikleren, blir den markert som 'Avvist' av utvikleren.
- Duplisere: Hvis utvikleren finner mangelen som den samme som enhver annen mangel, eller hvis konseptet med mangelen samsvarer med en hvilken som helst annen mangel, endres statusen til mangelen til ‘Dupliser’ av utvikleren.
- Utsatt: Hvis utvikleren føler at mangelen ikke er av veldig viktig prioritet, og den kan bli løst i de neste utgivelsene eller så i et slikt tilfelle, kan han endre statusen til feilen som 'Utsatt'.
- Ikke et feil: Hvis mangelen ikke har noen innvirkning på funksjonaliteten til applikasjonen, blir statusen til feilen endret til 'Not a Bug'.
De obligatoriske felt når en tester logger, er en hvilken som helst ny feil Build-versjon, Send inn, produkt, modul, alvorlighetsgrad, synopsis og beskrivelse som skal reproduseres
I listen ovenfor kan du legge til noen valgfrie felt hvis du bruker en manuell mal for innsending av feil. Disse valgfrie feltene inkluderer kundenavn, nettleser, operativsystem, filvedlegg eller skjermbilder.
Følgende felt forblir enten spesifiserte eller blanke:
Hvis du har myndighet til å legge til feilstatus-, prioritets- og ‘tildelt til’ -felt, kan du spesifisere disse feltene. Ellers vil Test Manager sette status, Feilprioritet og tildele feilen til den respektive moduleieren.
Se på følgende defekte syklus
Ovenstående bilde er ganske detaljert, og når du vurderer de viktige trinnene i Bug Life Cycle, vil du få en rask ide om det.
Ved vellykket logging blir feilen gjennomgått av utviklings- eller testansvarlig. Testansvarlig kan sette feilstatusen som Åpen, kan tilordne feilen til utvikler eller feil kan bli utsatt til neste utgivelse.
Når en feil blir tildelt en utvikler, og han / hun kan begynne å jobbe med den. Utvikleren kan angi at feilstatusen ikke vil bli løst, ikke kunne reprodusere, trenger mer informasjon eller 'løst'.
Hvis feilstatusen som er satt av utvikleren, er enten 'Trenger mer info' eller Fixed, svarer QA med en bestemt handling. Hvis feilen er løst, verifiserer QA feilen og kan angi feilstatusen som bekreftet lukket eller gjenåpne.
Retningslinjer for implementering av manglende livssyklus
Noen viktige retningslinjer kan vedtas før du begynner å arbeide med Defect Life Cycle.
Disse er som følger:
- Det er veldig viktig at hele teamet før de begynner å jobbe med Defect Life Cycle, forstår de forskjellige tilstandene til en defekt (diskutert ovenfor).
- Defekt livssyklus bør være riktig dokumentert for å unngå forvirring i fremtiden.
- Forsikre deg om at hver person som har fått tildelt en hvilken som helst oppgave relatert til defektets livssyklus, skal forstå sitt ansvar veldig tydelig for bedre resultater.
- Hver person som endrer statusen til en mangel, bør være riktig klar over denne statusen og bør gi nok detaljer om statusen og årsaken til å sette den statusen, slik at alle som jobber med den aktuelle feilen kan forstå årsaken til en slik status av en defekt veldig lett.
- Feilsøkingsverktøyet skal håndteres med forsiktighet for å opprettholde konsistens blant feilene og dermed i arbeidsflyten til Defect Life Cycle.
Deretter skal vi diskutere intervjuspørsmålene basert på Defect Life Cycle.
Viktige spørsmål eller intervjuspørsmål om feil i livssyklusen
Q # 1) Hva er en feil i perspektivet av programvaretesting?
Svar: En defekt er enhver form for feil eller feil i applikasjonen som begrenser den normale strømmen til en applikasjon ved å ikke matche den forventede oppførselen til en applikasjon med den faktiske.
Q # 2) Hva er den største forskjellen mellom feil, feil og feil?
Svar: Feil: Hvis utviklerne finner ut at det ikke er samsvar med den faktiske og forventede oppførselen til en applikasjon i utviklingsfasen, kaller de det en feil.
Defekt: Hvis testere finner en uoverensstemmelse i den faktiske og forventede oppførselen til en applikasjon i testfasen, kaller de det som en defekt.
Feil: Hvis kunder eller sluttbrukere finner en uoverensstemmelse i den faktiske og forventede oppførselen til en applikasjon i produksjonsfasen, kaller de det en feil.
Q # 3) Hva er statusen til en feil når den først ble funnet?
Svar: Når en ny feil blir funnet, er den i ‘Ny’ tilstand. Dette er den opprinnelige tilstanden til en nylig funnet feil.
Q # 4) Hva er de forskjellige tilstandene til en mangel i mangelens livssyklus når en mangel er godkjent og løst av en utvikler?
Svar: Ulike tilstander av en defekt, i dette tilfellet, er nye, tildelte, åpne, faste, venter på nytt, test på nytt, bekreftet og lukket.
Spørsmål nr. 5) Hva skjer hvis en tester fremdeles finner et problem i feilen som er løst av en utvikler?
Svar: Testeren kan markere feilstatusen som 'Gjenåpne' hvis han fremdeles finner et problem i den faste mangelen og mangelen blir tildelt en utvikler for ny testing.
Q # 6) Hva er en produserbar feil?
Svar: En mangel som forekommer gjentatte ganger i hver utførelse og hvis trinn kan fanges i hver utførelse, så kalles en slik mangel en 'produserbar' mangel.
Q # 7) Hvilken type mangel er en ikke reproduserbar feil?
Svar: En mangel som ikke forekommer gjentatte ganger i hver utførelse og bare produserer i noen tilfeller og hvis trinn som bevis må fanges ved hjelp av skjermbilder, kalles en slik feil som en 'ikke reproduserbar' defekt.
Q # 8) Hva er en feilrapport?
Svar: En feilrapport er et dokument som inkluderer rapporteringsinformasjon om feilen eller mangelen i applikasjonen som forårsaker normal flyt av en applikasjon som avviker fra den forventede oppførselen.
Sp # 9) Hvilke detaljer er inkludert i en feilrapport?
Svar: En feilrapport består av følgende detaljer:
Defekt-ID, beskrivelse av feilen, funksjonsnavn, testsaksnavn, reproduserbar feil eller ikke, status for en mangel, alvorlighetsgrad og prioritet for en defekt, testernavn, testdato for feilen, byggeversjon der feilen ble funnet .
Og utvikleren som mangelen er tildelt, navn på personen som har løst feilen, Skjermbilder av en mangel som viser trinnstrømmen, fikser datoen for en feil, og personen som har godkjent mangelen.
Sp # 10) Når endres en mangel til en 'utsatt' tilstand i mangelens livssyklus?
Svar: Når en mangel som er funnet ikke er av veldig stor betydning, og den som kan fikses i de senere utgivelsene, flyttes til en 'utsatt' tilstand i Defect Life Cycle.
Tilleggsinformasjon om feil eller feil
- En feil kan bli introdusert når som helst i programvarens utviklingslivssyklus.
- Tidligere defekten ble oppdaget og fjernet, vil lavere kostnadene for kvalitet være lavere.
- Kostnadene for kvalitet minimeres når feilen fjernes i samme fase som den ble introdusert.
- Statisk testing finner feilen, ikke en feil. Kostnaden minimeres ettersom feilsøking ikke er involvert.
- I dynamisk testing avsløres tilstedeværelsen av en defekt når den forårsaker en feil.
States Of Defect
| S.No. | Opprinnelige tilstand | Returnert stat | Bekreftelsesstat |
|---|---|---|---|
| 1 | Samle informasjon til personen som er ansvarlig for å reprodusere feilen | Defekt avvises eller blir bedt om mer informasjon | Feilen er løst og skal testes og lukkes |
| to | Stater er åpne eller nye | Stater avvises eller avklaring. | Stater er løst og bekreftet. |
Ugyldig og duplikatfeilrapport
- Noen ganger oppstår feil, ikke på grunn av kode, men på grunn av testmiljø eller misforståelse, bør en slik rapport lukkes som en ugyldig feil.
- I tilfelle duplikatrapport holdes en og en lukkes som duplikat. Enkelte ugyldige rapporter godtas av lederen.
- Testansvarlig eier den generelle mangelforvaltningen og prosessen, og det tverrfunksjonelle teamet for mangelforvaltning er generelt ansvarlig for å administrere rapportene.
- Deltakere inkluderer Test Manager, Developers, PM, Production Manager og andre interessenter, som har interesse.
- Mangelforvaltningskomiteen bør fastslå gyldigheten av hver mangel og bestemme når den skal rettes eller utsettes. For å fastslå dette, bør du vurdere kostnad, risiko og fordel ved ikke å fikse feil.
- Hvis mangelen må løses, må dens prioritet bestemmes.
Defektdata
- Navnet på personen.
- Type testing
- Problemoversikt
- Detaljert beskrivelse av feil.
- Steg for å reprodusere
- Livssyklusfase
- Arbeidsprodukt der Defekt ble introdusert.
- Alvorlighetsgrad og prioritet
- Delsystem eller komponent der feilen blir introdusert.
- Prosjektaktivitet som oppstår når feilen introduseres.
- Identifikasjonsmetode
- Type feil
- Prosjekt og produkt der problemet eksisterer
- Nåværende eier
- Gjeldende rapporttilstand
- Arbeidsprodukt der Defekt oppstod.
- Innvirkning på prosjektet
- Risiko, tap, mulighet og fordeler forbundet med å fikse eller ikke fikse mangelen.
- Datoer når ulike defekte livssyklusfaser oppstår.
- Beskrivelsen av hvordan feilen ble løst og anbefalinger for testing.
- Referanser
Prosessevne
- Introduksjon, deteksjon og fjerningsinfo -> Forbedre deteksjon av feil og kvalitetskostnader.
- Introduksjon -> Pretoranalyse av prosessen der det største antallet mangler er introdusert for å redusere det totale antallet feil.
- Info om rotfeil -> finn understreket årsaker til mangelen for å redusere det totale antallet feil.
- Feilkomponentinfo -> Utfør analyse av mangelklynger.
Konklusjon
Dette handler om Defect Life Cycle and Management.
Jeg håper du må ha fått enorm kunnskap om en mangels livssyklus. Denne opplæringen vil i sin tur hjelpe deg mens du arbeider med manglene i fremtiden på en enkel måte.
Anbefalt lesing
- Hva er feilbasert testteknikk?
- Hva er programvaretesting livssyklus (STLC)?
- Bugzilla Tutorial: Defect Management Tool Hands-on Tutorial
- Java-tråder med metoder og livssyklus
- Programvaretesting handler om ideer (og hvordan du kan generere dem)
- In-Depth Eclipse Tutorials For Beginners
- Process for defect management: Hvordan håndtere en feil effektivt
- Eksempel på feilrapporter for nett- og produktapplikasjoner