Een bugrapport schrijven (+ gratis sjabloon downloaden)
Weten hoe je een effectief bugrapport opstelt, is een belangrijk onderdeel van het werk van een softwaretester om kwaliteitsborging te handhaven. Daarom besteden we veel tijd aan het registreren van bugs in onze bugtrackingtools. Een bug vinden kan spannend voelen, vooral als het om een interessant scenario gaat. Maar de manier waarop we deze rapporteren, kan net zo belangrijk zijn als de impact ervan op het systeem.
Een slecht geschreven bugrapport kan veel wrijving tussen teamleden veroorzaken, met name tussen testers en ontwikkelaars. Dit kan blokkades veroorzaken bij het oplossen van bugs en uiteindelijk de gebruikerservaring verpesten.
In dit artikel deel ik essentiële details, zoals hoe je:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- Bugrapporten beheerst: Leer welke belangrijke elementen elk effectief bugrapport moet bevatten om de communicatie te stroomlijnen en oplossingen sneller door te voeren.
- De harmonie binnen het team bevordert: Ontdek hoe goed geschreven bugrapporten wrijving tussen testers en ontwikkelaars voorkomen, wat leidt tot soepelere werkprocessen.
- Gratis downloadbaar sjabloon: Download een gratis bugtrackingsjabloon om je efficiënte proces voor het rapporteren van bugs op gang te brengen.
Belangrijke elementen van een bugrapport
Ongeacht het type applicatie dat je test, of het nu gaat om een desktopapplicatie, webapplicatie, mobiele app of API-project, zijn er enkele belangrijke elementen die elk goed bugrapport moet bevatten. De meeste bugtrackingsoftware biedt velden voor deze elementen, waaronder:
- ID: Als je een projectmanagementtool gebruikt, zoals Jira, wordt automatisch een ID toegewezen aan nieuwe problemen die worden geopend. Er zijn ook testmanagementtools voor Jira voor bugtracking
- Titel/Beschrijving: Dit is een korte beschrijving van het probleem. Deze moet beknopt genoeg zijn om gemakkelijk te kunnen lezen, maar beschrijvend genoeg zodat anderen kunnen begrijpen waar het probleem zich bevindt. Bijvoorbeeld: “sorteren van items op prijs werkt niet wanneer een filter is toegepast.”
- Stappen om te reproduceren: Neem hier zoveel mogelijk relevante details op. Zorg ervoor dat iedereen die het probleem probeert te reproduceren of de oplossing wil verifiëren, dit kan doen door de stappen te volgen. Sla geen stappen over omdat je ervan uitgaat dat iedereen impliciet weet dat bepaalde handelingen moeten worden uitgevoerd, zelfs als ze niet worden vermeld; neem ze op in het bugrapport.
- Verwachte resultaten: Ga ook hier niet ervan uit dat mensen al weten hoe de applicatie hoort te werken. Als er in de gebruikersinterface een uitzondering optreedt wanneer je op een knop drukt, weet je natuurlijk dat dit niet wordt verwacht. Ik zou echter niet zeggen dat het verwachte resultaat “er wordt geen uitzondering gegenereerd” is, maar eerder welke actie de knop zou moeten uitvoeren, bijvoorbeeld: “het instellingendialoogvenster wordt geopend.”
- Werkelijke resultaten: Dit spreekt voor zich: je moet beschrijven wat er in de applicatie gebeurt nadat alle stappen om het probleem te reproduceren zijn uitgevoerd.
- Ernst: Dit vertegenwoordigt de impact die de bug heeft op de AUT.
- Prioriteit: Hoe snel de bug moet worden opgelost. Een hogere prioriteit betekent dat de bug hoger in de achterstand moet worden geplaatst en eerder moet worden opgelost.
Andere belangrijke informatie om op te nemen
Naast de hierboven genoemde elementen kan ook andere informatie relevant zijn, vooral wanneer je gegevens invoert in een bugrapportagetool. Deze informatie kan afhankelijk zijn van het projecttype, de projectvereisten of zelfs de bug zelf:
- Softwareversie: Het buildnummer waarin de bug is vastgesteld. Dit kan helpen bij het isoleren van de builds waarin het probleem mogelijk is geïntroduceerd en bij het identificeren van de code die de oorzaak ervan vormt.
- Bijlagen: Deze zijn niet altijd nodig of beschikbaar, maar leveren doorgaans veel waarde op. Overweeg schermafbeeldingen of opnamen van het gevonden probleem, logbestanden, stacktraces, netwerkverzoeken en -reacties enzovoort toe te voegen.
- Testgegevens: Soms kunnen de bugs die we vinden alleen met specifieke gegevenssets worden gereproduceerd. Als dat het geval is, zorg er dan voor dat je deze vermeldt, hetzij in de stappen om het probleem te reproduceren (bijvoorbeeld “log in met gebruiker andreea@theqalead.com”), hetzij in een specifiek veld in de bugtrackingtool.
- Omgevingsdetails: Als de bug alleen kan worden gereproduceerd op een specifiek besturingssysteem, in een specifieke browser of in een specifieke ontwikkelomgeving, vermeld dit dan.
Tips voor het maken van een goed bugrapport
- Beperk jezelf tot één bug per rapport. Als je meer bugs in dezelfde gebieden ontdekt, kun je ze aan je issue-tracker koppelen. Het opnemen van meer dan één defect kan verwarring en vertragingen bij mogelijke bugfixes veroorzaken.
- Controleer je trackingsysteem om er zeker van te zijn dat de bug niet al is gemeld. Als de bug al is geopend, voeg dan relevante details toe die je hebt gevonden en die niet in het oorspronkelijke bugrapport stonden.
- Probeer de bug meerdere keren te reproduceren. Je kunt proberen de kortste manier te vinden om de bug te reproduceren (met zo min mogelijk stappen).
- Verdwaal niet in irrelevante details. Het bugrapport en de stappen moeten gemakkelijk te lezen en te volgen zijn.
- Ga niet uit van de reden waarom de bug optreedt (tenzij je er 100% zeker van bent dat je weet waardoor deze is veroorzaakt).
Sjabloon voor bugrapporten
Nu wil ik enkele sjablonen voor bugrapporten met je delen. Je kunt ze kopiëren of aanpassen aan de behoeften van je project.
Jira-sjabloon voor bugtracking
Jira is een veelgebruikte tool voor issue-tracking van Atlassian. Als je team deze gebruikt, is het issuetype voor bugs waarschijnlijk al geconfigureerd. Als tester of manager van een softwareontwikkelingsteam kun je een workflow voor bugtracking instellen voor de levenscyclus van bugs (deze mogelijkheid is een van de vele voordelen van software voor issue-tracking).
Je kunt ook aangepaste velden in Jira toevoegen, bijvoorbeeld voor de omgeving of een uniek veld waarin de geteste functionaliteit wordt toegevoegd. Je kunt ook een standaardbeschrijving toevoegen met alle informatie die je in elk bugrapport wilt opnemen. Hier is er een die ik heb gemaakt:
Wanneer ik nu een nieuwe bug wil maken, is deze informatie vooraf ingevuld. Hier is mijn bugsjabloon in Jira, met aangepaste velden en een standaardbeschrijving:
Het bevat de essentiële informatie die volgens ons in de bug moet staan:
- Een titel (“Voorbeeldbug”)
- In de beschrijving: de voorwaarden, de stappen om de bug te reproduceren en de verwachte versus daadwerkelijke resultaten
- Een aangepast veld voor de omgeving
- Een ernstniveau en een prioriteit, geselecteerd uit vervolgkeuzemenu's met vooraf gedefinieerde waarden
- Ik heb de toegewezene leeg gelaten. Afhankelijk van de conventies binnen je project kunnen nieuwe bugs automatisch aan een specifiek teamlid worden toegewezen, of kan degene die eraan begint de bug aan zichzelf toewijzen
- Een label — dit kan bijvoorbeeld handig zijn als je wilt bijhouden welke functionaliteit wordt beïnvloed
- Een vervaldatum — de bug wordt mogelijk pas voltooid nadat de achterstand is geprioriteerd
- De melder (in dit geval automatisch ingevuld met de Jira-gebruiker die de bug heeft gemaakt)
Jira heeft optioneel verschillende integraties en de bug kan worden gekoppeld aan testgevallen, Git-branches of zelfs pullrequests.
Je kunt hun sjabloon voor bugtracking ook gebruiken als projectsjabloon als je Jira alleen nodig hebt voor defecttracking en niet in een agile omgeving werkt.
Excel-sjabloon voor bugtracking
Sommige teams gebruiken mogelijk spreadsheets voor hun bugtrackingsysteem. Ik vind ze nuttig voor zeer kleine projecten waarbij het instellen van een tool voor issue-tracking simpelweg niet de moeite waard is, of voor het rapporteren van bugs in nieuwe functies die nog in ontwikkeling zijn.
Je kunt Google Sheets/Docs of Microsoft Excel/Word gebruiken — hoe dan ook, een bugsjabloon kan er als volgt uitzien:
De kolommen geven de informatie weer die het rapport moet bevatten:
- De ID (Excel weet hoe de waarde automatisch moet worden verhoogd telkens wanneer een nieuwe rij wordt toegevoegd)
- Een titel
- De stappen om het probleem te reproduceren
- Verwachte en werkelijke resultaten
- De naam van de melder
- De ernst en prioriteit van de bug—hier heb ik vervolgkeuzelijsten gebruikt, omdat de waarden vooraf moeten zijn ingesteld
- Omgeving
- Aanvullende informatie: dit is bedoeld voor al het overige dat het vermelden waard is en niet in de andere kolommen past
Laatste gedachten
Het schrijven van een goed bugrapport voor software is een essentiële vaardigheid voor softwaretesters. Besteed daarom extra aandacht aan de hierboven uitgelegde best practices. Je kunt ook gebruikmaken van de voorbeelden van sjablonen voor bugtrackers die ik heb gegeven. Deze kunnen worden aangepast aan de verschillende tools die je gebruikt, zoals Trello of Asana.
Vond je deze inhoud interessant? Abonneer je dan op de nieuwsbrief van The QA Lead om op de hoogte te blijven van meer nieuws en trends in het softwaretestproces!
