11 nov 2026 Testrapport: zo maak je van testresultaten een releasebesluit

In het kort: Een testrapport is er om iemand te helpen beslissen of een release live kan, en met welk risico. Zet het advies dus bovenaan. Laat daarna per belangrijk bedrijfsproces de status zien, de bekende problemen met hun impact, en wat niet getest is. Houd tests die willekeurig falen apart van echte fouten. Een slagingspercentage alleen zegt een manager weinig.

Een testrapport met “94% geslaagd” beantwoordt een vraag die niemand stelde. De product owner wil weten of de release donderdag live kan. De manager wil weten wat er mis kan gaan als dat gebeurt. De meeste rapporten van geautomatiseerde tests zeggen het niet. Ze tonen geslaagd, gefaald en een dekkingscijfer, en laten de lezer raden. Zonde van goed testwerk. De tests hebben het werk gedaan, het rapport moet het afmaken.

Waar is een testrapport voor?

Een testrapport is er voor een besluit: nu live, later live, of live met een bekend risico. Alles in het rapport moet bij dat besluit helpen. De ISTQB-woordenlijst, het gedeelde woordenboek van testers, noemt de versie aan het eind van een testfase een test summary report. Dat is een samenvatting van wat er getest is en wat er gevonden is. Dat is de formele kant. De praktische kant is simpeler. Iemand die de tests niet heeft zien draaien, moet binnen een paar minuten snappen of de software klaar is. Moet die persoon eerst een tester bellen, dan deed het rapport zijn werk niet. Daarom is de nuttigste regel in elk testrapport het advies bovenaan. Bijvoorbeeld: “We adviseren live te gaan. Er is één bekend probleem in de export, met weinig impact. De oplossing staat voor de volgende sprint”. Dat is een duidelijk standpunt van de mensen die de testresultaten het best kennen. De details eronder onderbouwen het.

Wat hoort er in een testrapport?

Een goed testrapport begint met het advies en onderbouwt dat met een paar heldere onderdelen. Houd het bij wat de lezer nodig heeft om te beslissen. Details kunnen achter een link, voor wie ze wil zien. Dit zijn de onderdelen die het meest tellen.

• Het advies. Live, wachten, of live met een benoemd risico, in een of twee zinnen.
• Status per bedrijfsproces. Rapporteer over processen die mensen kennen, zoals “bestelling plaatsen” of “factuur goedkeuren”, niet over 800 testgevallen.
• Bekende problemen en hun impact. Wat is er stuk, wie merkt het, en is er een omweg?
• Wat niet getest is. Noem de gaten en waarom. Een gat dat je noemt, is een risico dat iemand kan accepteren. Een gat dat je verzwijgt, is een verrassing.
• Echte fouten of ruis. Tests die willekeurig falen, flaky tests, krijgen een eigen regel. Zo verstoppen ze geen echte bugs.
• De trend. Wordt de software release na release stabieler, of juist niet?

Een TaaS-klant zegt op onze site dat ze heldere rapportages over hun bugs krijgen, en dat we meedenken over waar het probleem vandaan kan komen. Een rapport dat mensen helpt iets te doen, is meer waard dan een lijst met wat er faalde.

Welke testcijfers misleiden?

De cijfers die het mooist staan op een slide, zijn vaak het minst bruikbaar voor een besluit. Een slagingspercentage van 95% klinkt goed. Maar het hangt af van welke 5% faalde. Is dat de checkout, dan kun je niet live. Is het een oude rapportpagina, dan waarschijnlijk wel. Het aantal tests zegt nog minder. Een testset kan snel groeien en toch de processen missen die ertoe doen. En dekking, het deel van de code waar je tests langskomen, laat alleen zien wat geraakt is. Niet of het goed gecontroleerd is. Martin Fowler zegt het helder: dekking helpt je ongeteste code te vinden, maar is een slecht doel op zich. We zien hetzelfde bij klanten. Een jaar na de start weet niemand meer of het dekkingscijfer nog te vertrouwen is.

Wat helpt dan wel? Kijk naar de status van je belangrijkste processen en de open problemen per impact. Voeg toe hoe lang het duurt van een rode test tot een oplossing, en hoe vaak tests falen zonder echte bug. Scoor je je processen eerst op risico, zoals bij risicogebaseerd testen, dan schrijft het rapport zich bijna vanzelf. Je rapporteert dan over de risico’s die je samen hebt afgesproken.

Wie heeft wat nodig uit een testrapport?

Verschillende lezers hebben verschillende diepgang nodig, dus stuur niet iedereen hetzelfde. Ontwikkelaars en testers willen de details: welke test faalde, de log, de stappen om het te herhalen. Een product owner wil de status per bedrijfsproces en de bekende problemen. Management wil één pagina, of zelfs één alinea: het advies, het grootste risico, en wat wachten zou kosten. Schrijf de samenvatting voor wie beslist, en link de details voor wie het oplost.

Een rapport gaat ook niet alleen over geautomatiseerde tests. Bevindingen uit exploratief testen, waarbij iemand de software gebruikt zoals een echte gebruiker dat zou doen, horen erin. De uitkomsten van acceptatietesten door je gebruikers ook. Sommige van de grootste risico’s zijn juist die waarvoor nooit een script is geschreven.

Een eerlijke kanttekening: een dashboard vervangt geen gesprek. Bij een grote release zijn tien minuten met de testlead meer waard dan elk rapport. En een klein team heeft geen formeel document nodig. Een kort geschreven advies in het teamkanaal, met de drie punten hierboven, kan genoeg zijn. Onze Government Operations Centre-case laat de gewoonte zien die telt: na elke testcyclus een releaseadvies, zodat een releasebesluit niet op onderbuikgevoel rust.

Wat betekent dit voor je team?

Geautomatiseerde tests leveren elke nacht resultaten op. Van die resultaten een advies maken, is het werk dat blijft liggen. Iemand moet elke rode test bekijken en echte bugs scheiden van ruis. Diegene schrijft op wat de fouten betekenen voor de business, en voorkomt dat de flaky tests zich opstapelen. Is niemand daar eigenaar van, dan leest straks niemand de rapporten meer. En dan gaat er een release live met een bekend probleem dat niemand zag.

Dat doorlopende werk pakken we op met Test Automation as a Service, samen met je team. Je tests draaien elke nacht, en wij houden ze betrouwbaar. Je krijgt een stabiele testset waar je team op kan vertrouwen, die niet van één persoon afhangt en je team geen extra werk geeft. We rapporteren over de processen die ertoe doen, en je team houdt de regie over wat er live gaat.

Een eerste stap voor deze week: neem je laatste testrapport en laat het zien aan degene die releases goedkeurt. Vraag wat die persoon ermee zou besluiten, en wat er ontbrak.

Veelgestelde vragen

Wat is het verschil tussen een testrapport en een releaseadvies?

Een testrapport beschrijft wat er getest is en wat er gevonden is. Een releaseadvies is de conclusie daaruit: live of niet, en met welk risico. In een goed testrapport staat het advies bovenaan.

Hoe vaak stuur je een testrapport?

Deel de geautomatiseerde resultaten dagelijks met het team, in je pipeline of dashboard. Stuur voor elke release een samenvatting met advies. Vaker geeft ruis; minder vaak betekent dat er zonder rapport wordt besloten.

Wie beslist over go of no-go?

Meestal de product owner of releasemanager, niet de tester. De tester geeft een advies en noemt de risico’s. Wie eigenaar is van het product, beslist of dat risico acceptabel is.

Kan een dashboard een testrapport vervangen?

Niet helemaal. Een dashboard toont de status, maar geen oordeel. Het advies, de impact van bekende problemen en wat niet getest is, moet iemand nog steeds opschrijven.