Menu

Hoe schrijf je een goed bugrapport? Tips en trucs

how write good bug report

Probeer Ons Instrument Voor Het Oplossen Van Problemen

c ++ willekeurig getal tussen

Waarom een ​​goed bugrapport?

Als uw bugrapport effectief is, is de kans om gerepareerd te worden groter. Het oplossen van een bug hangt dus af van hoe effectief u het rapporteert. Het melden van een bug is niets anders dan vaardigheid en ik zal uitleggen hoe je deze vaardigheid kunt bereiken.

'Het punt van het schrijven van een probleemrapport (bugrapport) is om bugs te verhelpen' - Door Cem Kaner. Als een tester een bug niet correct rapporteert, zal de programmeur deze bug waarschijnlijk afwijzen en aangeven dat deze niet reproduceerbaar is.

Hoe u een goed bugrapport schrijft

Dit kan de testers moreel schaden en soms ook het ego. (Ik raad aan om geen enkel soort ego te behouden. Het ego is als 'Ik heb de bug correct gerapporteerd', 'Ik kan het reproduceren', 'Waarom heeft hij / zij de bug afgewezen?', 'Het is niet mijn fout' enz. ,).

Wat je leert:

Wat zijn de eigenschappen van een goed softwarefoutrapport?

Iedereen kan een bugrapport schrijven. Maar niet iedereen kan een effectief bugrapport schrijven.

U moet onderscheid kunnen maken tussen een gemiddeld bugrapport en een goed bugrapport. Hoe maak je onderscheid tussen een goed en een slecht bugrapport? Het is heel eenvoudig, pas de volgende kenmerken en technieken toe om een ​​bug te rapporteren.

Kenmerken en technieken zijn onder meer

# 1) Een duidelijk gespecificeerd bugnummer hebben: Wijs altijd een uniek nummer toe aan elk bugrapport. Dit zal u op zijn beurt helpen om het bugrecord te identificeren. Als u een geautomatiseerde bugrapportagetool gebruikt, wordt dit unieke nummer automatisch gegenereerd elke keer dat u de bug rapporteert.

Noteer het aantal en een korte beschrijving van elke bug die u heeft gerapporteerd.

# 2) Reproduceerbaar: Als uw bug niet reproduceerbaar is, wordt deze nooit opgelost.

U moet duidelijk de stappen vermelden om de bug te reproduceren. Ga er niet vanuit of sla geen reproductiestap over. Een bug die stap voor stap wordt beschreven, is eenvoudig te reproduceren en op te lossen.

# 3) Wees specifiek: Schrijf geen essay over het probleem.

Wees specifiek en ter zake. Probeer het probleem in minimale woorden maar toch op een effectieve manier samen te vatten. Combineer niet meerdere problemen, ook al lijken ze op elkaar. Schrijf verschillende rapporten voor elk probleem.

Effectieve bugrapportage

Bugrapportage is een belangrijk aspect van softwaretests. Een effectief bugrapport communiceert goed met het ontwikkelteam en voorkomt verwarring of miscommunicatie.

Een goed bugrapport zou moeten zijn duidelijk en beknopt zonder enige ontbrekende kernpunten. Elke onduidelijkheid leidt tot misverstanden en vertraagt ​​ook het ontwikkelingsproces. Het schrijven en rapporteren van gebreken is een van de belangrijkste maar verwaarloosde gebieden in de testlevenscyclus.

Goed schrijven is erg belangrijk voor het indienen van een bug. Het belangrijkste punt waar een tester rekening mee moet houden is geen bevelende toon te gebruiken in het rapport. Dit doorbreekt het moreel en creëert een ongezonde werkrelatie. Gebruik een suggestieve toon.

Ga er niet vanuit dat de ontwikkelaar een fout heeft gemaakt en daarom kun je harde woorden gebruiken. Voordat u rapporteert, is het net zo belangrijk om te controleren of dezelfde bug al dan niet is gerapporteerd.

Een dubbele bug is een last in de testcyclus. Bekijk de hele lijst met bekende bugs. Soms kenden de ontwikkelaars het probleem misschien en negeerden ze het voor een toekomstige release. Tools zoals Bugzilla die automatisch naar dubbele bugs zoekt, kunnen ook worden gebruikt. Het is echter het beste om handmatig naar dubbele bugs te zoeken.

De importinformatie die een bugrapport moet communiceren is 'Hoe?' en waar?' Het rapport moet duidelijk aangeven hoe de test is uitgevoerd en waar het defect precies is opgetreden. De lezer moet de bug gemakkelijk reproduceren en vinden waar de bug zich bevindt.

Houd er rekening mee dat de doel van het schrijven van het bugrapport is om de ontwikkelaar in staat te stellen het probleem te visualiseren. Hij / zij moet het defect duidelijk begrijpen uit het bugrapport. Vergeet niet om alle relevante informatie te geven waarnaar de ontwikkelaar op zoek is.

Houd er ook rekening mee dat een bugrapport wordt bewaard voor toekomstig gebruik en goed moet worden geschreven met de vereiste informatie. Gebruik zinvolle zinnen en eenvoudige woorden om uw bugs te beschrijven. Gebruik geen verwarrende uitspraken die de tijd van de recensent verspillen.

Rapporteer elke bug als een afzonderlijk probleem. In het geval van meerdere problemen in één bugrapport, kunt u het pas sluiten als alle problemen zijn opgelost.

Daarom is het het beste om splits de problemen op in afzonderlijke bugs ​Dit zorgt ervoor dat elke bug afzonderlijk kan worden afgehandeld. Een goed geschreven bugrapport helpt een ontwikkelaar om de bug op hun terminal te reproduceren. Dit helpt hen ook om het probleem te diagnosticeren.

Hoe meld ik een bug?

Gebruik de volgende eenvoudige sjabloon voor bugrapporten:

Dit is een eenvoudig formaat voor bugrapporten. Het kan variëren afhankelijk van de bugrapporttool die u gebruikt. Als u handmatig een bugrapport schrijft, moeten sommige velden specifiek worden vermeld, zoals het bugnummer, dat handmatig moet worden toegewezen.

Verslaggever: Uw naam en e-mailadres.

Product: In welk product je deze bug hebt gevonden.

Versie: De productversie, indien aanwezig.

Component: Dit zijn de belangrijkste submodules van het product.

Platform: Noem het hardwareplatform waar u deze bug hebt gevonden. De verschillende platforms zoals ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ enz.

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

Prioriteit: Wanneer moet een bug worden opgelost? De prioriteit wordt doorgaans ingesteld van P1 tot P5. P1 als 'repareer de bug met de hoogste prioriteit' en P5 als 'Repareer wanneer de tijd het toelaat'.

Ernst: Dit beschrijft de impact van de bug.
Soorten ernst:

  • Blokkering: Er kan geen verder testwerk worden gedaan.
  • Kritiek: Applicatiecrash, verlies van gegevens.
  • Majoor: Groot functieverlies.
  • Minor: Licht functieverlies.
  • Triviaal: Enkele verbeteringen in de gebruikersinterface.
  • Verbetering: Verzoek om een ​​nieuwe functie of een verbetering van de bestaande.

Toestand: Wanneer u de bug in een bugvolgsysteem aanmeldt, is de bugstatus standaard ‘Nieuw’.
Later doorloopt de bug verschillende stadia zoals Fixed, Verified, Reopen, Won't Fix, etc.

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

Toewijzen: Als u weet welke ontwikkelaar verantwoordelijk is voor die specifieke module waarin de bug is opgetreden, kunt u het e-mailadres van die ontwikkelaar opgeven. Laat het anders blanco, aangezien dit de bug aan de module-eigenaar zal toewijzen, zo niet zal de Manager de bug aan de ontwikkelaar toewijzen. Voeg eventueel het e-mailadres van de manager toe aan de CC-lijst.

URL: De pagina-URL waarop de bug is opgetreden.

Overzicht: Een korte samenvatting van de bug, meestal in 60 woorden of minder. Zorg ervoor dat uw samenvatting een afspiegeling is van wat het probleem is en waar het is.

Omschrijving: Een gedetailleerde beschrijving van de bug.

Gebruik de volgende velden voor het beschrijvingsveld:

  • Reproduceer stappen: Noem duidelijk de stappen om de bug te reproduceren.
  • Verwacht resultaat: Hoe de applicatie zich moet gedragen bij de bovengenoemde stappen.
  • Werkelijke resultaat: Wat is het daadwerkelijke resultaat van het uitvoeren van de bovenstaande stappen, d.w.z. het buggedrag.

Dit zijn de belangrijkste stappen in het bugrapport. U kunt ook het 'Rapporttype' toevoegen als nog een veld dat het type bug beschrijft.

Rapporttypen zijn onder meer:

1) Coderingsfout
2) Ontwerpfout
3) Nieuwe suggestie
4) Documentatieprobleem
5) Hardwareprobleem

Belangrijke functies in uw bugrapport

Hieronder staan ​​de belangrijkste kenmerken van het bugrapport:

# 1) Bugnummer / id

Een bugnummer of een identificatienummer (zoals swb001) maakt het rapporteren van bugs en het verwijzen naar een bug veel gemakkelijker. De ontwikkelaar kan eenvoudig controleren of een bepaalde bug is verholpen of niet. Het maakt het hele test- en hertestproces soepeler en gemakkelijker.

# 2) Bugtitel

Een bugtitel wordt vaker gelezen dan enig ander deel van het bugrapport. Het zou alles moeten zeggen over wat er in de bug zit.

De titel van de bug moet suggestief genoeg zijn zodat de lezer deze kan begrijpen. Een duidelijke bugtitel maakt het gemakkelijk te begrijpen en de lezer kan weten of de bug eerder is gerapporteerd of is verholpen.

# 3) Prioriteit

Op basis van de ernst van de bug kan er een prioriteit voor worden ingesteld. Een bug kan een Blocker, Critical, Major, Minor, Trivial of een suggestie zijn. Een bugprioriteit van P1 tot P5 kan worden gegeven, zodat de belangrijkste eerst worden bekeken.

# 4) Platform / omgeving

De configuratie van het besturingssysteem en de browser is nodig voor een duidelijk bugrapport. Het is de beste manier om te communiceren hoe de bug kan worden gereproduceerd.

Zonder het exacte platform of de exacte omgeving kan de applicatie zich anders gedragen en wordt de bug aan de kant van de tester mogelijk niet gerepliceerd aan de kant van de ontwikkelaar. Het is dus het beste om duidelijk de omgeving te vermelden waarin de bug is gedetecteerd.

# 5) Beschrijving

Bugbeschrijving helpt de ontwikkelaar de bug te begrijpen. Het beschrijft het opgetreden probleem. De slechte beschrijving zorgt voor verwarring en verspilt ook de tijd van de ontwikkelaars en de testers.

Het is noodzakelijk om duidelijk te communiceren over het effect van de beschrijving. Het is altijd handig om volledige zinnen te gebruiken. Het is een goede gewoonte om elk probleem afzonderlijk te beschrijven in plaats van ze helemaal af te brokkelen. Gebruik geen termen als 'ik denk' of 'ik geloof'.

# 6) Stappen om te reproduceren

Een goed bugrapport moet duidelijk de stappen vermelden om te reproduceren. De stappen moeten acties bevatten die de bug veroorzaken. Maak geen algemene uitspraken. Wees specifiek in de te volgen stappen.

Hieronder volgt een goed voorbeeld van een goedgeschreven procedure

Stappen:

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

# 7) Verwacht en feitelijk resultaat

Een bugbeschrijving is onvolledig zonder de verwachte en werkelijke resultaten. Het is noodzakelijk om te schetsen wat de uitkomst van de test is en wat de gebruiker mag verwachten. De lezer moet weten wat de juiste uitkomst van de test is. Geef duidelijk aan wat er tijdens de test is gebeurd en wat de uitkomst was.

# 8) Schermafbeelding

Een foto zegt meer dan duizend woorden. Maak een screenshot van de fout met de juiste ondertiteling om het defect te markeren. Markeer onverwachte foutmeldingen met een lichtrode kleur. Dit vestigt de aandacht op het gewenste gebied.

Enkele bonustips om een ​​goed bugrapport te schrijven

Hieronder vindt u nog enkele aanvullende tips om een ​​goed bugrapport te schrijven:

# 1) Meld het probleem onmiddellijk

Als u een bug vindt tijdens het testen, hoeft u niet te wachten om later een gedetailleerd bugrapport te schrijven. Schrijf in plaats daarvan onmiddellijk het bugrapport. Dit zorgt voor een goed en reproduceerbaar bugrapport. Als u besluit om het Bugrapport later te schrijven, is de kans groot dat u de belangrijke stappen in uw rapport mist.

# 2) Reproduceer de bug drie keer voordat je een bugrapport schrijft

Uw bug moet reproduceerbaar zijn. Zorg ervoor dat uw stappen robuust genoeg zijn om de bug zonder enige dubbelzinnigheid te reproduceren. Als uw bug niet elke keer kan worden gereproduceerd, kunt u nog steeds een bug indienen waarin u de periodieke aard van de bug vermeldt.

# 3) Test dezelfde fout op andere vergelijkbare modules

Soms gebruikt de ontwikkelaar dezelfde code voor verschillende vergelijkbare modules. Er zijn dus grotere kansen dat de bug in de ene module ook in andere vergelijkbare modules voorkomt. U kunt zelfs proberen de ernstigere versie van de gevonden bug te vinden.

# 4) Schrijf een goede bugsamenvatting

Bugsamenvatting helpt de ontwikkelaars om snel de bug-aard te analyseren. Een rapport van slechte kwaliteit zal de ontwikkel- en testtijd onnodig verlengen. Communiceer goed met de samenvatting van uw bugrapport. Houd er rekening mee dat de bug-samenvatting wordt gebruikt als referentie om de bug in bug-inventaris te doorzoeken.

# 5) Lees het bugrapport voordat u op de knop Verzenden drukt

Lees alle zinnen, bewoordingen en stappen die in het bugrapport worden gebruikt. Kijk of een zin dubbelzinnigheid creëert die tot verkeerde interpretatie kan leiden. Misleidende woorden of zinnen moeten worden vermeden om een ​​duidelijk bugrapport te krijgen.

# 6) Gebruik geen beledigende taal

Het is prettig dat je goed werk hebt verricht en een bug hebt gevonden, maar gebruik dit krediet niet om de ontwikkelaar te bekritiseren of om iemand aan te vallen.

Gevolgtrekking

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

Concentreer u op het schrijven van goede bugrapporten en besteed wat tijd aan deze taak, want dit is het belangrijkste communicatiepunt tussen de tester, ontwikkelaar en de manager. Managers moeten hun team ervan bewust maken dat het schrijven van een goed bugrapport de primaire verantwoordelijkheid is van elke tester.

Uw inspanningen om een ​​goed bugrapport te schrijven, bespaart niet alleen de middelen van het bedrijf, maar creëert ook een goede relatie tussen u en de ontwikkelaars.

Schrijf voor een betere productiviteit een beter bugrapport.

Ben jij een expert in het schrijven van een bugrapport? Deel gerust uw mening in de opmerkingen hieronder.

Aanbevolen literatuur

^