Het schrijven van een goed en bruikbaar foutrapport is een belangrijke vaardigheid binnen de testwereld. Het maken van een goed geschreven foutrapport is een kunst die een combinatie vereist van testervaring en goede communicatieve vaardigheden. Dit artikel geeft inzichten, advies en tips die je helpen om foutrapporten te maken die informatief en bruikbaar zijn, waardoor ze waardevoller worden voor degenen die de fouten uiteindelijk moeten oplossen.
Duidelijk gezegd, wat heeft een ontwikkelaar nodig om een duidelijk beeld te krijgen van het probleem dat je (als gebruiker) bent tegengekomen. Dit omvat alle ins en outs, de ondernomen stappen en de variabelen die van belang kunnen zijn voor de ontwikkelaar. Deze kunnen per project verschillen, soms zijn technische details van de gebruikte hardware nodig en in sommige gevallen van bijvoorbeeld een SaaS tool is de browser en de versie van de browser meer van belang voor de gewenste output.
Goede foutrapporten zijn in één woord: Informatief. Het rapport beschrijft in detail wat er gebeurde en hoe de fout tot stand kwam op een begrijpelijke en herleidbare manier.
Een "goed" of ‘’waardevol’’ foutrapport gaat echter een stapje verder om jou op een efficiënte manier nuttige informatie te verstrekken. Om je te helpen bij het schrijven van waardevolle foutrapporten, zijn er enkele belangrijke gebieden om jouw aandacht op te vestigen:
Een goede titel van de fout voorkomt het hebben van dubbele fouten in een systeem en zou de details van de fout snel moeten samenvatten. Het beste is om algemene problemen in de titel te vermijden. Vaak worden de fouten overgebracht naar een issue management tool van de ontwikkelaar (zoals Jira of Asana) dat al honderden, al niet duizenden, andere fouten kan bevatten. Maar dat hoeft niet. TestMonitor heeft zijn eigen geïntegreerde issue managementsysteem.
Kan je je dan voorstellen dat je deze database doorzoekt naar één specifieke fout? Wees beschrijvend, beknopt en gebruik de structuur waar het team bekend mee is. Jouw foutrapport moet na de huidige test cyclus overleven (en nuttig zijn); een sterke titel gaat daar aan bijdragen.
In plaats van te zeggen: Probleem met ABC component, of ABC genereert een fout. Zeg: ABC component genereert een fout wanneer de gebruiker toegevoegd is, of ABC geeft een fout bij het opslaan van bijlagen.
Om jouw fout te kunnen reproduceren, moet de ontwikkelaar precies weten wat er gebeurde terwijl je aan het testen was. Aangezien deze beschrijvingen meestal veel informatie bevatten, is het belangrijk om het beknopt en makkelijk leesbaar te houden. Houd jouw stappen altijd kort en bondig. Afhankelijk van de software die wordt gebruikt voor het loggen en het maken van foutrapporten, kan het probleem andere gegevens tot zijn beschikking hebben, dus schrijf ze zo op dat ze overeenkomen.
Tijdens het testen van een functie, kunnen gebruikers en/of testers verschillende ideeën hebben over het resultaat dat ze verwachten te zien. Om een volledig rapport op te leveren kan het handig zijn om jouw verwachting toe te voegen als resultaat van het doorlopen van de beschreven stappen. Dit is misschien een beetje cryptisch voor sommigen, maar het kan helpen om een betere gebruikerservaring te creëren. Niet alles is even logisch voor eindgebruikers als wat de ontwikkelaar bedoeld heeft.
Het kan ook zijn dat bepaalde delen van applicaties in een hoger tempo worden gebouwd, waarbij de rauwe kantjes nog zichtbaar zijn. Als je als tester in detail uitlegt wat je graag zou zien, of wat je verwachtte dat er zou gebeuren, kan dit de ontwikkelaars helpen om software vloeiender en gebruiksvriendelijker te maken. Hou het kort en bondig, probeer niet je persoonlijke agenda door te drukken maar bekijk de verwachting vanuit een breder perspectief, zou jouw verwachting bijdragen aan het algehele klantgevoel?
Afbeeldingen zijn een snelle en gemakkelijke manier om context aan jouw fout toe te voegen. Een goed idee is om de aandachtsgebieden in jouw afbeelding te benadrukken. Op deze manier hoeft een ontwikkelaar niet het hele scherm door te kijken om te begrijpen wat jij nodig hebt. Om de snelheid van de werkstroom te verhogen, voeg je de afbeeldingsbestanden rechtstreeks bij het foutrapport. Probeer te vermijden om ze in een Word doc of een ZIP bestand te zetten, dit veroorzaakt alleen maar onnodige extra stappen voor iedereen die ze wil bekijken.
Als je de hierboven beschreven stappen volgt, zullen jij en jouw ontwikkelaar al een betere relatie beginnen te krijgen. Nu ze eindelijk begrijpen tegen welke problemen je aanloopt tijdens het werken, kunnen ze beginnen met het aanpassen en verbeteren van de software.
Een veel voorkomend iets om te vermijden is het gebruik van een negatieve toon bij het melden van fouten. Het is duidelijk dat iedereen op zoek is naar een functionele en bruikbare applicatie. Mensen hebben de neiging te vergeten dat ontwikkelaars ook maar mensen zijn. Hun kennis van 'robotachtige' talen maakt hen niet minder in staat om emoties te tonen. Zeker niet als het hele team begint te vloeken of een negatieve houding aanneemt ten opzichte van hun creatie.
Enkele tips om te voorkomen dat het ontwikkelingsteam schreeuwt: "Eraf met hun hoofd!"
Neutraliseer je foutrapporten, breng slecht nieuws voorzichtig, wees eerlijk in bewoordingen en implicaties. Vermijd: Het aanvallen van ontwikkelaars, het bekritiseren van de onderliggende fout.