what is defect bug life cycle software testing
Inleiding tot de levenscyclus van defecten
In deze tutorial ga ik in op de levenscyclus van een defect om je bewust te maken van de verschillende stadia van een defect waar een tester mee te maken krijgt tijdens het werken in een testomgeving.
Ik heb ook de meest gestelde interviewvragen over de Defect Life Cycle toegevoegd. Dit is belangrijk om te weten over de verschillende toestanden van een defect om de levenscyclus van een defect te begrijpen. De belangrijkste bedoeling van het uitvoeren van een testactiviteit is om te controleren of het product problemen / fouten heeft.
In termen van echte scenario's worden fouten / fouten / fouten allemaal bugs / defecten genoemd en daarom kunnen we zeggen dat het belangrijkste doel van testen is om ervoor te zorgen dat het product minder vatbaar is voor defecten (geen defecten is een onrealistische situatie ).
Nu rijst de vraag wat een defect is?
dubbel gelinkte lijst c ++ code
Wat je leert:
- Wat is een defect?
- Defecte levenscyclus in detail
- Aanvullende informatie over defect of bug
- Gevolgtrekking
Wat is een defect?
Een defect is, in eenvoudige bewoordingen, een fout of een fout in een applicatie die de normale stroom van een applicatie beperkt door het verwachte gedrag van een applicatie niet overeen te laten komen met het daadwerkelijke gedrag.
Het defect treedt op wanneer een ontwikkelaar een fout maakt tijdens het ontwerpen of bouwen van een applicatie en wanneer deze fout door een tester wordt gevonden, wordt dit een defect genoemd.
Het is de verantwoordelijkheid van een tester om een applicatie grondig te testen om zoveel mogelijk defecten te vinden om ervoor te zorgen dat een kwaliteitsproduct de klant bereikt.
Het is belangrijk om de levenscyclus van een defect te begrijpen voordat u naar de workflow en de verschillende statussen van het defect gaat.
Laten we daarom meer te weten komen over Defect Life Cycle.
Tot dusver hebben we de betekenis van defecten en de relatie in verband met de testactiviteit besproken. Laten we nu naar de defectlevenscyclus gaan en de workflow van een defect en de verschillende toestanden van een defect begrijpen.
Defecte levenscyclus in detail
Een defectlevenscyclus, ook wel bekend als een buglevenscyclus, is een cyclus van een defect waarvan het doorloopt en de verschillende toestanden in zijn hele leven bestrijkt. Dit begint zodra een nieuw defect door een tester wordt gevonden en eindigt wanneer een tester dat defect sluit, zodat het niet opnieuw wordt gereproduceerd.
Defecte workflow
Het is nu tijd om de feitelijke workflow van een Defect Life Cycle te begrijpen met behulp van een eenvoudig diagram zoals hieronder weergegeven.
Defecte staten
# 1) Nieuw Dit is de eerste toestand van een defect in de Defect Life Cycle. Wanneer een nieuw defect wordt gevonden, valt het in een ‘nieuwe’ staat en worden validaties en tests op dit defect uitgevoerd in de latere stadia van de defectlevenscyclus.
# 2) Toegekend: In deze fase wordt een nieuw gemaakt defect toegewezen aan het ontwikkelteam om aan het defect te werken. Dit wordt door de projectleider of de manager van het testteam toegewezen aan een ontwikkelaar.
# 3) Openen: Hier begint de ontwikkelaar het proces van het analyseren van het defect en werkt hij aan het repareren ervan, indien nodig. Als de ontwikkelaar van mening is dat het defect niet geschikt is, kan het worden overgedragen naar een van de onderstaande vier staten, namelijk Duplicaat, uitgesteld, afgewezen of geen bug -gebaseerd op de specifieke reden.
Ik zal deze vier staten straks bespreken.
# 4) Opgelost: Wanneer de ontwikkelaar klaar is met het repareren van een defect door de vereiste wijzigingen aan te brengen, kan hij de status van het defect markeren als ‘Opgelost’.
# 5) In afwachting van nieuwe test: Nadat het defect is verholpen, wijst de ontwikkelaar het defect toe aan de tester om het defect aan hun einde opnieuw te testen, en totdat de tester aan het opnieuw testen van het defect werkt, blijft de toestand van het defect in ‘Opnieuw in behandeling’.
# 6) Opnieuw testen: Op dit punt begint de tester te werken aan het opnieuw testen van het defect om te controleren of het defect nauwkeurig is verholpen door de ontwikkelaar volgens de vereisten of niet.
# 7) Heropenen: Als een probleem zich blijft voordoen in het defect, wordt het opnieuw toegewezen aan de ontwikkelaar om te testen en wordt de status van het defect gewijzigd in ‘Heropenen’.
# 8) Geverifieerd: Als de tester geen enkel probleem in het defect vindt nadat hij aan de ontwikkelaar is toegewezen om opnieuw te testen, en hij vindt dat als het defect nauwkeurig is verholpen, de status van het defect wordt toegewezen aan ‘Geverifieerd’.
# 9) Gesloten: Als het defect niet meer bestaat, verandert de tester de status van het defect naar ‘Gesloten’.
Wat meer:
- Afgekeurd: Als het defect door de ontwikkelaar niet als een echt defect wordt beschouwd, wordt het door de ontwikkelaar gemarkeerd als ‘Afgewezen’.
- Duplicaat: Als de ontwikkelaar vindt dat het defect hetzelfde is als elk ander defect of als het concept van het defect overeenkomt met een ander defect, wordt de status van het defect door de ontwikkelaar gewijzigd in 'Dupliceren'.
- Uitgesteld: Als de ontwikkelaar van mening is dat het defect geen erg belangrijke prioriteit heeft en het in een dergelijk geval in de volgende releases of zo kan worden verholpen, kan hij de status van het defect wijzigen in ‘Uitgesteld’.
- Geen bug: Als het defect geen invloed heeft op de functionaliteit van de applicatie, wordt de status van het defect gewijzigd in ‘Geen bug’.
De verplichte velden wanneer een tester een nieuwe bug registreert, zijn Build-versie, Indienen op, Product, Module, Ernst, Synopsis en Beschrijving om te reproduceren
In de bovenstaande lijst kunt u er enkele toevoegen optionele velden als u een handmatige sjabloon voor het indienen van bugs gebruikt. Deze optionele velden omvatten de naam van de klant, de browser, het besturingssysteem, de bestandsbijlagen of schermafbeeldingen.
De volgende velden blijven gespecificeerd of blanco:
Als u de bevoegdheid heeft om bugstatus, prioriteit en ‘toegewezen aan’ velden toe te voegen, kunt u deze velden specificeren. Anders stelt de Test Manager de status en Bugprioriteit in en wijst de bug toe aan de respectievelijke module-eigenaar.
Bekijk de volgende Defect-cyclus
wat is kwaliteitscontrole en kwaliteitsborging
De bovenstaande afbeelding is vrij gedetailleerd en als je de belangrijke stappen in Bug Life Cycle overweegt, krijg je er snel een idee van.
Bij een succesvolle logboekregistratie wordt de bug beoordeeld door de ontwikkelings- of testmanager. De testmanager kan de bugstatus instellen op Open, kan de bug toewijzen aan de ontwikkelaar of de bug kan worden uitgesteld tot de volgende release.
Wanneer een bug wordt toegewezen aan een ontwikkelaar en hij / zij eraan kan gaan werken. De ontwikkelaar kan de bugstatus instellen als 'zal niet herstellen', 'Kan niet reproduceren', heeft meer informatie nodig of 'Opgelost'.
Als de door de ontwikkelaar ingestelde bugstatus ‘Meer info nodig’ of Fixed is, reageert de QA met een specifieke actie. Als de bug is verholpen, verifieert QA de bug en kan de bugstatus instellen als geverifieerd gesloten of opnieuw geopend.
Richtlijnen voor het implementeren van Defect Life Cycle
Voordat u met de Defect Life Cycle gaat werken, kunnen enkele belangrijke richtlijnen worden aangenomen.
Dit zijn de volgende:
- Het is erg belangrijk dat het hele team, voordat het aan de Defect Life Cycle begint, duidelijk de verschillende toestanden van een defect begrijpt (hierboven besproken).
- Defect Life Cycle moet correct worden gedocumenteerd om verwarring in de toekomst te voorkomen.
- Zorg ervoor dat iedereen aan wie een taak is toegewezen die verband houdt met de Defect Life Cycle, zijn / haar verantwoordelijkheid heel duidelijk begrijpt voor betere resultaten.
- Elke persoon die de status van een defect verandert, moet zich goed bewust zijn van die status en voldoende details verstrekken over de status en de reden voor het toekennen van die status, zodat iedereen die aan dat specifieke defect werkt, de reden van een dergelijke status kan begrijpen. van een defect heel gemakkelijk.
- De defectopsporingstool moet met zorg worden behandeld om de consistentie tussen de defecten en dus in de workflow van de Defect Life Cycle te behouden.
Laten we vervolgens de interviewvragen bespreken op basis van de Defect Life Cycle.
Belangrijke veelgestelde vragen of interviewvragen over de levenscyclus van bugs
V # 1) Wat is een defect in het perspectief van softwaretests?
Antwoord: Een defect is elke fout of fout in de applicatie die de normale stroom van een applicatie beperkt doordat het verwachte gedrag van een applicatie niet overeenkomt met het daadwerkelijke gedrag.
V # 2) Wat is het belangrijkste verschil tussen fout, defect en mislukking?
Antwoord: Fout: Als de ontwikkelaars ontdekken dat er een discrepantie is in het werkelijke en verwachte gedrag van een applicatie in de ontwikkelingsfase, noemen ze dit een fout.
wat is de beste virtual reality-app
Defect: Als testers een mismatch vinden in het werkelijke en verwachte gedrag van een applicatie in de testfase, noemen ze dit een Defect.
Mislukking: Als klanten of eindgebruikers een mismatch vinden in het daadwerkelijke en verwachte gedrag van een applicatie in de productiefase, noemen ze dit een Failure.
V # 3) Wat is de status van een defect wanneer het voor het eerst wordt gevonden?
Antwoord: Als er een nieuw defect wordt gevonden, bevindt het zich in de status ‘Nieuw’. Dit is de begintoestand van een nieuw gevonden defect.
V # 4) Wat zijn de verschillende toestanden van een defect in de defectlevenscyclus wanneer een defect wordt goedgekeurd en verholpen door een ontwikkelaar?
Antwoord: Verschillende toestanden van een defect zijn in dit geval Nieuw, Toegekend, Open, Opgelost, In afwachting van nieuwe test, Opnieuw testen, Geverifieerd en Gesloten.
V # 5) Wat gebeurt er als een tester nog steeds een probleem vindt in het defect dat is verholpen door een ontwikkelaar?
Antwoord: De tester kan de staat van het defect markeren als ‘Heropenen’ als hij nog steeds een probleem vindt in het gerepareerde defect en het defect wordt toegewezen aan een ontwikkelaar voor opnieuw testen.
V # 6) Wat is een produceerbaar defect?
Antwoord: Een defect dat herhaaldelijk voorkomt in elke uitvoering en waarvan de stappen in elke uitvoering kunnen worden vastgelegd, dan wordt zo'n defect een ‘produceerbaar’ defect genoemd.
V # 7) Welk type defect is een niet reproduceerbaar defect?
Antwoord: Een defect dat niet herhaaldelijk in elke uitvoering voorkomt en slechts in sommige gevallen wordt geproduceerd en waarvan de stappen als bewijs moeten worden vastgelegd met behulp van schermafbeeldingen, dan wordt een dergelijk defect een ‘niet reproduceerbaar’ defect genoemd.
V # 8) Wat is een defectrapport?
Antwoord: Een defectrapport is een document dat rapportage-informatie bevat over het defect of de fout in de applicatie waardoor de normale stroom van een applicatie afwijkt van het verwachte gedrag.
V # 9) Welke details zijn opgenomen in een defectrapport?
Antwoord: Een defectrapport bestaat uit de volgende gegevens:
Defect-ID, beschrijving van het defect, functienaam, naam testcase, reproduceerbaar defect of niet, status van een defect, ernst en prioriteit van een defect, testernaam, datum waarop het defect is getest, buildversie waarin het defect is aangetroffen .
En de ontwikkelaar aan wie het defect is toegewezen, de naam van de persoon die het defect heeft verholpen, screenshots van een defect die het verloop van de stappen weergeven, de datum van een defect vaststellen en de persoon die het defect heeft goedgekeurd.
V # 10) Wanneer wordt een defect in de defectlevenscyclus gewijzigd in een ‘uitgestelde’ status?
Antwoord: Wanneer een defect dat wordt gevonden niet van erg groot belang is en het defect dat in de latere releases kan worden verholpen, in de Defect Life Cycle naar een ‘uitgestelde’ staat worden verplaatst.
Aanvullende informatie over defect of bug
- Een defect kan op elk moment in de levenscyclus van softwareontwikkeling worden geïntroduceerd.
- Eerder het defect wordt gedetecteerd en verwijderd, zullen de algehele kwaliteitskosten lager zijn.
- De kwaliteitskosten worden geminimaliseerd wanneer het defect wordt verwijderd in dezelfde fase waarin het werd geïntroduceerd.
- Bij statisch testen wordt het defect gevonden, geen fout. De kosten worden geminimaliseerd omdat er geen sprake is van foutopsporing.
- Bij dynamisch testen wordt de aanwezigheid van een defect onthuld wanneer het een storing veroorzaakt.
Staat van defect
| S.No. | Oorspronkelijke toestand | Geretourneerde staat | Bevestigingsstatus |
|---|---|---|---|
| een | Verzamel informatie voor de persoon die verantwoordelijk is voor het reproduceren van het Defect | Defect wordt afgewezen of om meer informatie gevraagd | Defect is opgelost en moet worden getest en gesloten |
| twee | Staten zijn open of nieuw | Staten worden afgewezen of verduidelijkt. | Staten zijn opgelost en verificatie. |
Ongeldig en dubbel defectrapport
- Soms treedt er een defect op, niet vanwege code maar vanwege een testomgeving of misverstanden, een dergelijk rapport moet worden afgesloten als een ongeldig defect.
- In het geval van een duplicaatrapport wordt er één bewaard en wordt één gesloten als duplicaat. Een ongeldig rapport wordt geaccepteerd door de manager.
- De testmanager is eigenaar van het algemene defectbeheer en -proces en het multifunctionele team van de tool voor defectbeheer is over het algemeen verantwoordelijk voor het beheer van de rapporten.
- Deelnemers zijn onder meer Test Manager, Developers, PM, Productiemanager en andere belanghebbenden die een belang hebben.
- Het Defect Management Committee moet de geldigheid van elk defect bepalen en bepalen wanneer het moet worden hersteld of uitgesteld. Om dit te bepalen, moet u rekening houden met de kosten, risico's en voordelen van het niet repareren van een defect.
- Als het defect moet worden verholpen, moet de prioriteit worden bepaald.
Defecte gegevens
- Naam van de persoon.
- Type testen
- Probleem Samenvatting
- Gedetailleerde beschrijving van het defect.
- Stappen om te reproduceren
- Levenscyclusfase
- Werkproduct waar Defect werd geïntroduceerd.
- Ernst en prioriteit
- Subsysteem of component waar het defect wordt geïntroduceerd.
- Projectactiviteit die plaatsvindt wanneer het defect wordt geïntroduceerd.
- Identificatiemethode
- Soort defect
- Project en product waarin een probleem bestaat
- Huidige eigenaar
- De huidige stand van zaken
- Werkproduct waar een defect is opgetreden.
- Impact op project
- Risico's, verlies, kansen en voordelen verbonden aan het al dan niet verhelpen van het defect.
- Datums waarop verschillende fasen in de levenscyclus van defecten optreden.
- De beschrijving van hoe het defect is verholpen en aanbevelingen voor testen.
- Referenties
Procesmogelijkheden
- Inleiding, detectie en verwijderingsinformatie -> Verbeter defectdetectie en kwaliteitskosten.
- Inleiding -> Praetoranalyse van het proces waarin het grootste aantal defecten wordt geïntroduceerd om het totale aantal defecten te verminderen.
- Defect Root-info -> vind onderstreepte redenen voor het defect om het totale aantal defecten te verminderen.
- Info over defectcomponenten -> Voer analyse van defectclusters uit.
Gevolgtrekking
Dit gaat allemaal over Defect Life Cycle and Management.
Ik hoop dat je een enorme kennis hebt opgedaan over de levenscyclus van een defect. Deze tutorial zal je op zijn beurt helpen om in de toekomst op een gemakkelijke manier met de defecten te werken.
Aanbevolen literatuur
- Wat is een op defecten gebaseerde testtechniek?
- Wat is Software Testing Life Cycle (STLC)?
- Bugzilla-zelfstudie: Praktische zelfstudie voor hulpprogramma voor defectbeheer
- Java-threads met methoden en levenscyclus
- Bij softwaretests draait alles om ideeën (en hoe u ze kunt genereren)
- Diepgaande Eclipse-zelfstudies voor beginners
- Defect Management Process: hoe u een defect effectief kunt beheren
- Voorbeelden van bugrapporten voor web- en producttoepassingen