Waarom een goed Bug Report?

Als je Bug report effectief is, dan is de kans groter dat het wordt opgelost. Dus het oplossen van een bug hangt af van hoe effectief u het melden. Het melden van een bug is niets anders dan vaardigheid en ik zal uitleggen hoe deze vaardigheid te bereiken.

“Het punt van het schrijven van probleemrapport (bugrapport) is om bugs opgelost te krijgen” – Door Cem Kaner. Als een tester een bug niet correct rapporteert, zal de programmeur deze bug hoogstwaarschijnlijk afwijzen door hem als onreproduceerbaar aan te merken.

Dit kan de moraal van de tester schaden en soms ook zijn ego. (Ik stel voor om geen enkele vorm van ego te houden. Ego’s zoals “Ik heb de bug correct gerapporteerd”, “Ik kan het reproduceren”, “Waarom heeft hij/zij de bug afgekeurd?”, “Het is niet mijn fout” enz.).

Wat zijn de kwaliteiten van een goed software-infectierapport?

Iedereen kan een insectenrapport schrijven. Maar niet iedereen kan een effectief Bug report schrijven.

Je zou onderscheid moeten kunnen maken tussen een gemiddeld bug report en een goed bug report. Hoe onderscheid je een goed van een slecht Bug Report? Het is zeer eenvoudig, pas de volgende kenmerken en technieken toe om een bug te melden.

De kenmerken en de Technieken omvatten

#1) Het hebben van een duidelijk gespecificeerd Bug Number: Wijs altijd een uniek aantal aan elk insectenrapport toe. Dit, beurtelings, zal u helpen om het insectenverslag te identificeren. Als u om het even welk geautomatiseerd insect-rapporterend hulpmiddel gebruikt dan zal dit unieke aantal automatisch telkens worden geproduceerd terwijl u het insect meldt.

Noteer het aantal en een korte beschrijving van elk insect dat u reported.

#2) Reproduceerbaar: Als uw bug niet reproduceerbaar is, dan zal het nooit opgelost worden.

U zou duidelijk de stappen moeten vermelden om de bug te reproduceren. Veronderstel of sla geen reproducerende stap over. Een insect dat stap voor stap wordt beschreven is gemakkelijk te reproduceren en te bevestigen.

#3) Ben Specifiek: Schrijf geen opstel over het probleem.

Be Specifiek en to the point. Probeer het probleem samen te vatten in een minimum aan woorden maar op een effectieve manier. Combineer niet meerdere problemen, ook al lijken ze op elkaar. Schrijf verschillende rapporten voor elk probleem.

Effectieve Bug Reporting

Bug reporting is een belangrijk aspect van Software Testing. Een effectief Bug-rapport communiceert goed met het ontwikkelingsteam en voorkomt verwarring of miscommunicatie.

Een goed Bug-rapport moet duidelijk en beknopt zijn zonder ontbrekende hoofdpunten. Elk gebrek aan duidelijkheid leidt tot misverstanden en vertraagt ook het ontwikkelingsproces. Het schrijven en rapporteren van defecten is een van de belangrijkste maar meest verwaarloosde gebieden in de test life cycle.

Goed schrijven is zeer belangrijk voor het indienen van een bug. Het belangrijkste punt dat een tester in gedachten moet houden is om geen gebiedende toon te gebruiken in het rapport. Dit breekt het moreel en creëert een ongezonde werkrelatie. Gebruik een suggestieve toon.

Ga er niet van uit dat de ontwikkelaar een fout heeft gemaakt en dat je daarom harde woorden kunt gebruiken. Alvorens te melden, is het even belangrijk om te controleren of dezelfde bug is gemeld of niet.

Een dubbele bug is een last in de testcyclus. Controleer de hele lijst van bekende bugs. Soms hebben de ontwikkelaars misschien de kwestie gekend en voor een toekomstige versie genegeerd. Tools zoals Bugzilla die automatisch zoeken naar dubbele bugs kunnen ook worden gebruikt. Echter, het is het beste om handmatig te zoeken naar elke dubbele bug.

De invoerinformatie die een bugrapport moet communiceren is “Hoe?” en “Waar?” Het rapport moet duidelijk beantwoorden hoe de test werd uitgevoerd en waar het defect zich precies voordeed. De lezer zou de bug gemakkelijk moeten kunnen reproduceren en vinden waar de bug zich bevindt.

Houd in gedachten dat het doel van het schrijven van het Bug report is om de ontwikkelaar in staat te stellen het probleem te visualiseren. Hij/zij zou het defect duidelijk uit het Bug-rapport moeten begrijpen. Vergeet niet om alle relevante informatie te geven waar de ontwikkelaar naar op zoek is.

Bedenk ook dat een bugrapport voor toekomstig gebruik bewaard zou worden en goed geschreven zou moeten zijn met de vereiste informatie. Gebruik zinvolle zinnen en eenvoudige woorden om uw bugs te beschrijven. Gebruik geen verwarrende verklaringen die de tijd van de recensent verspillen.

Raporteer elke bug als een afzonderlijke kwestie. In het geval van veelvoudige kwesties in één enkel Bug-rapport, kunt u het niet sluiten tenzij alle kwesties worden opgelost.

Hence is het beste om de kwesties in afzonderlijke bugs te splitsen. Dit zorgt ervoor dat elke bug afzonderlijk kan worden behandeld. Een goed geschreven bugrapport helpt een ontwikkelaar om de bug te reproduceren op hun terminal. Dit helpt hen ook om het probleem te diagnostiseren.

Hoe rapporteer je een bug?

Gebruik de volgende eenvoudige Bug report template:

Dit is een eenvoudige Bug report format. Het kan variëren afhankelijk van het Bug report tool dat u gebruikt. Als u een insectenrapport manueel schrijft dan sommige gebieden moeten specifiek zoals het insectenaantal worden vermeld, dat manueel zou moeten worden toegewezen.

Reporter: Uw naam en e-mailadres.

Product: In welk product u deze bug heeft gevonden.

Versie: De productversie indien aanwezig.

Component: Dit zijn de belangrijkste submodules van het product.

Platform: Vermeld het hardware platform waar u deze bug heeft gevonden. De verschillende platforms zoals ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.

Besturingssysteem: Noem alle besturingssystemen waar u de bug heeft gevonden. Besturingssystemen zoals Windows, Linux, Unix, SunOS, Mac OS. Vermeld ook de verschillende OS versies zoals Windows NT, Windows 2000, Windows XP etc, indien van toepassing.

Prioriteit: Wanneer moet een bug worden opgelost? De prioriteit wordt over het algemeen gesteld van P1 tot P5. P1 als “repareer de bug met de hoogste prioriteit” en P5 als “repareer wanneer de tijd het toelaat”.

Severity: Dit beschrijft de impact van de bug.
Types van Severity:

• Blokker: Er kan geen verder testwerk worden gedaan.
• Kritiek: Applicatie crash, Verlies van data.
• Major: Major verlies van functie.
• Minor: Klein verlies van functie.
• Triviaal: Enkele UI verbeteringen.
• Uitbreiding: Verzoek om een nieuwe functie of enige verbetering in de bestaande.

Status: Wanneer u de bug in om het even welk bug tracking systeem registreert dan standaard zal de bugstatus ‘Nieuw’ zijn.
Later, gaat de bug door diverse stadia zoals Vast, Geverifieerd, Heropen, Zal niet bevestigen, enz.

=> Klik hier om meer over de gedetailleerde Bug Life Cycle te lezen.

Toewijzen aan: Als u weet welke ontwikkelaar verantwoordelijk is voor die bepaalde module waarin de bug zich voordeed, dan kunt u het emailadres van die ontwikkelaar opgeven. Anders kunt u het leeg laten, want dan wordt de bug toegewezen aan de eigenaar van de module. Zo niet, dan wijst de Manager de bug toe aan de ontwikkelaar. Voeg eventueel het email adres van de manager toe in de CC lijst.

URL: De pagina URL waarop de bug zich voordeed.

Samenvatting: Een korte samenvatting van de bug meestal in 60 woorden of minder. Zorg ervoor dat uw samenvatting weergeeft wat het probleem is en waar het zich bevindt.

Description: Een gedetailleerde beschrijving van de bug.

Gebruik de volgende velden voor het beschrijvingsveld:

• Reproduceer stappen: Vermeld duidelijk de stappen om de bug te reproduceren.
• Verwacht resultaat: Hoe de applicatie zich zou moeten gedragen bij de hierboven genoemde stappen.
• Werkelijk resultaat: Wat is het werkelijke resultaat van het uitvoeren van de bovenstaande stappen, d.w.z. het gedrag van de bug.

Dit zijn de belangrijke stappen in het bugrapport. U kunt ook het “Rapporttype” toevoegen als een extra veld dat het bugtype zal beschrijven.

Rapporttypes omvatten:

1) Codeerfout
2) Ontwerpfout
3) Nieuwe Suggestie
4) Documentatieprobleem
5) Hardwareprobleem

Belangrijke Eigenschappen In Uw Bugrapport

Hieronder staan de belangrijke eigenschappen in het Bugrapport:

#1) Bug Number/id

Een Bug nummer of een identificatienummer (zoals swb001) maakt het rapporteren van bugs en het verwijzen naar een bug veel gemakkelijker. De ontwikkelaar kan gemakkelijk controleren of een bepaald insect al dan niet is bevestigd. Het maakt het gehele het testen en het opnieuw testen proces vlotter en gemakkelijker.

#2) Titel van het insect

Een titel van het insect wordt gelezen vaker dan om het even welk ander deel van het insectenrapport. Het zou alles moeten zeggen over wat in de insect komt.

De titel van het insect zou suggestief genoeg moeten zijn dat de lezer het kan begrijpen. Een duidelijke bugtitel maakt het gemakkelijk te begrijpen en de lezer kan weten of de bug eerder is gemeld of is bevestigd.

#3) Prioriteit

Gebaseerd op de strengheid van de bug, kan een prioriteit voor het worden geplaatst. Een bug kan een blokkerend, kritiek, belangrijk, minder belangrijk, triviaal, of een suggestie zijn. Een insectenprioriteit van P1 tot P5 kan worden gegeven zodat de belangrijke eerst worden bekeken.

#4) Platform/Omgeving

De OS en browserconfiguratie zijn noodzakelijk voor een duidelijk insectenrapport. Het is de beste manier om mee te delen hoe de bug kan worden gereproduceerd.

Zonder het exacte platform of milieu, kan de toepassing zich anders gedragen en de bug op het eind van de tester kan niet op het eind van de ontwikkelaar worden gerepliceerd. Zo is het best om duidelijk het milieu te vermelden waarin de bug werd ontdekt.

#5) Beschrijving

De beschrijving van de bug helpt de ontwikkelaar om de bug te begrijpen. Het beschrijft het ondervonden probleem. De slechte beschrijving zal verwarring veroorzaken en zal de tijd van de ontwikkelaars en de testers verspillen ook.

Het is noodzakelijk om duidelijk over het effect van de beschrijving te communiceren. Het is altijd nuttig om volledige zinnen te gebruiken. Het is een goede gewoonte om elk probleem afzonderlijk te beschrijven in plaats van ze samen te voegen. Gebruik geen termen als “ik denk” of “ik geloof”.

#6) Stappen om te reproduceren

Een goed foutenrapport zou duidelijk de stappen moeten vermelden om te reproduceren. De stappen zouden acties moeten omvatten die de bug veroorzaken. Maak geen algemene verklaringen. Wees specifiek in de te volgen stappen.

Een goed voorbeeld van een goed geschreven procedure wordt hieronder gegeven

Stappen:

• Selecteer product Abc01.
• Klik op Toevoegen aan winkelwagen.
• Klik op Verwijderen om het product uit de winkelwagen te verwijderen.

#7) Verwachte en Feitelijke resultaten

Een bugbeschrijving is onvolledig zonder de Verwachte en Feitelijke resultaten. Het is noodzakelijk te schetsen wat het resultaat van de test is en wat de gebruiker mag verwachten. De lezer moet weten wat de juiste uitkomst van de test is. Vermeld duidelijk wat er tijdens de test is gebeurd en wat het resultaat was.

#8) Screenshot

Een beeld zegt meer dan duizend woorden. Maak een screenshot van het geval van mislukking met de juiste bijschriften om het defect te markeren. Markeer onverwachte foutmeldingen met een lichtrode kleur. Dit vestigt de aandacht op het vereiste gebied.

Enkele Bonus Tips Om Een Goed Verslag van de Insect te Schrijven

Hieronder zijn nog enkele extra tips om een goed Verslag van de Insect te schrijven:

#1) Meld het probleem onmiddellijk

Als u om het even welke insect vindt terwijl het testen, dan te hoeven niet wachten om een detail later insectenrapport te schrijven. In plaats daarvan, schrijf het bugrapport onmiddellijk. Dit zal zorgen voor een goed en reproduceerbaar foutenrapport. Als u beslist om het rapport van het insect later te schrijven dan zijn er hoge kansen om de belangrijke stappen in uw report.

#2) Reproduceer het insect drie keer alvorens een rapport van het insect te schrijven

Uw insect zou reproduceerbaar moeten zijn. Zorg ervoor dat uw stappen robuust genoeg zijn om de bug zonder enige dubbelzinnigheid te reproduceren. Als uw insect niet elke keer reproduceerbaar is kunt u nog een insect indienen dat de periodieke aard van bug.

#3) Test het zelfde insect voorkomen op andere gelijkaardige modules

Soms gebruikt de ontwikkelaar de zelfde code voor verschillende gelijkaardige modules. Zo zijn er hogere kansen voor de insect in één module om in andere gelijkaardige modules eveneens voor te komen. U kunt zelfs proberen om de strengere versie van de bug te vinden die u hebt gevonden.

#4) Schrijf een goede bugsamenvatting

De bugsamenvatting zal de ontwikkelaars helpen om de aard van de bug snel te analyseren. Een verslag van slechte kwaliteit zal onnodig de ontwikkeling en de testende tijd verhogen. Communiceer goed met uw bugrapport samenvatting. Houd in mening dat de insectensamenvatting als verwijzing wordt gebruikt om het insect in insecteninventaris.

#5) te zoeken Lees het Rapport van het insect alvorens de knoop voor te leggen te raken

Lees alle zinnen, formuleringen en stappen die in het insectenrapport worden gebruikt. Zie of om het even welke zin ambiguïteit creëert die tot verkeerde interpretatie kan leiden. Misleidende woorden of zinnen zouden moeten worden vermeden om een duidelijk foutenrapport te hebben.

#6) Gebruik geen beledigende taal

Het is aardig dat u goed werk hebt verricht en een insect hebt gevonden maar gebruik dit krediet niet om de ontwikkelaar te bekritiseren of om een individu aan te vallen.

Conclusie

Het lijdt geen twijfel dat je bugrapport een document van hoge kwaliteit moet zijn.

Focus je op het schrijven van goede bugrapporten en besteed wat tijd aan deze taak omdat dit het belangrijkste communicatiepunt is tussen de tester, ontwikkelaar en de manager. Managers zouden een bewustzijn van hun team moeten creëren dat het schrijven van een goed Bug report de primaire verantwoordelijkheid is van elke tester.