In het kort: Een testplan beschrijft hoe je één project of release test: wat je test, wie het doet, wanneer, en wanneer je klaar bent. Een teststrategie is de aanpak daarboven, voor een heel product: de risico’s, de testsoorten, wat je automatiseert en wie beslist. Houd het testplan kort en laat het volgen uit de strategie.

Een testplan maken lijkt eenvoudig, tot je ziet hoeveel testplannen na de kick-off in een map verdwijnen. Daarnaast lopen testplan en teststrategie in veel teams door elkaar. Dat is jammer, want als je het verschil kent, worden beide documenten korter en bruikbaarder.

Wat is een testplan?

Een testplan is een kort document over hoe je één project of release test. Het zegt wat je test, wie het doet, wanneer, en wanneer je klaar bent. De woordenlijst van het ISTQB, de internationale organisatie voor softwaretesten, omschrijft een testplan als de doelen, middelen en planning voor een stuk testwerk. Een goed testplan is één of twee pagina’s lang. Voor hoe je in het algemeen test, verwijst het naar de teststrategie, zodat het plan gericht blijft op deze ene release.

Wat is het verschil tussen een testplan en een teststrategie?

Een teststrategie is de aanpak voor de lange termijn: hoe je team een product test, welke release het ook is. Een testplan is de korte-termijnversie: hoe je dit project of deze release test, met namen en datums. De strategie beantwoordt vragen als “welke risico’s zijn het grootst?” en “wat automatiseren we?”. Het plan beantwoordt “wat testen we in release 4.2, wie doet het en wanneer zijn we klaar?”. Het ISTQB omschrijft een teststrategie als de manier waarop je test om je testdoelen te halen in een bepaalde situatie. Een klein team kan beide in één document zetten. Een grotere organisatie heeft meestal één strategie per product en een nieuw plan voor elke release of elk project. Het plan volgt in beide gevallen uit de strategie.

Wat staat er in een teststrategie?

Een goede teststrategie past op één pagina en beantwoordt zes vragen. Elk testplan dat erna komt, bouwt op die antwoorden. Laat de theorie weg, net als lange lijsten met testsoorten en alles wat elke sprint verandert. Schrijf de strategie samen met de mensen die testen, zodat ze hun eigen werk erin herkennen.

1. Risico’s: welke vijf dingen doen het meeste pijn als ze stukgaan?
2. Testsoorten: welke gebruik je (unit, integratie, systeem, acceptatie), en wie is waarvoor verantwoordelijk?
3. Automatisering: wat draait automatisch, hoe vaak, en wat blijft handwerk?
4. Omgevingen en data: waar test je, en met welke testdata?
5. Releasecriteria: wanneer is een release goed genoeg om live te gaan?
6. Besluiten: wie beslist, en hoe krijgt die de risico’s te horen?

Hoe maak je een testplan?

Je maakt een testplan door je teststrategie toe te passen op één release of project. Houd het kort: voor de meeste releases is één of twee pagina’s genoeg. Bij klanten zien we vaak testplannen van twintig pagina’s die niemand na de kick-off nog opent. Het meeste daarvan hoort in de strategie. Dit zet je erin:

• Doel: wat verandert er in deze release, en waarom doet testen ertoe?
• Scope: wat test je wel, en wat bewust niet?
• Mensen: wie test, wie lost bevindingen op en wie keurt goed, inclusief de gebruikers die de acceptatietest doen.
• Planning: de testmomenten, gekoppeld aan de releasedatum.
• Aanpak: een korte verwijzing naar de strategie, plus wat er voor deze release anders is.
• Exitcriteria: wanneer ben je klaar? Bijvoorbeeld als alle kritieke tests geslaagd zijn en er geen blokkerende bevindingen meer openstaan.
• Risico’s: wat kan er in deze release misgaan, en wat doe je eraan?

Hoe voorkom je dat ze in een la verdwijnen?

Houd ze kort, bewaar ze op één vaste plek en kijk er op een vast moment naar. Een check van een kwartier aan het begin van elke release is genoeg. Kloppen de risico’s nog? Past het plan bij wat het team echt doet? Geef elk document één eigenaar die het bijwerkt. Koppel de strategie aan je geautomatiseerde regressietest, zodat “wat automatiseren we” verwijst naar echte tests. Leg besluiten vast in het testplan op het moment dat je ze neemt, zoals een bekende bug die je voor deze release accepteert. Dan heb je ook na de release nog iets aan het plan.

Bij de Deltawerken werkten we met een risicogestuurde teststrategie die meegroeide met de bevindingen. De operators die het systeem gingen gebruiken, voerden zelf tests uit onder begeleiding van onze testers.

Wat betekent dit voor je team?

Heb je nog geen teststrategie, schrijf dan deze week de versie van één pagina, samen met de mensen die testen. Gebruik de zes vragen hierboven. Maak in dezelfde sessie het testplan voor je volgende release, en bekijk beide opnieuw bij de release daarna.

Nekst helpt teams daarbij. Met QA & Testing Solutions werken ervaren testers in je team mee aan de teststrategie, de testplannen en het testen zelf. Je team houdt de regie. Zegt de strategie “automatiseren”, dan bouwt Test Automation as a Service de regressietest en houden wij hem elke nacht draaiend.

Veelgestelde vragen

Wat staat er in een testplan?

Het doel, de scope, de mensen, de planning, de aanpak, de exitcriteria en de risico’s van één release. Voor de meeste releases past dat op één of twee pagina’s.

Wat voor soorten testen zijn er?

Je kunt testen indelen naar niveau: unittests, integratietests, systeemtests en acceptatietests. Je kunt ook indelen naar doel, zoals functionele tests, regressietests, performancetests en securitytests. De teststrategie bepaalt welke je gebruikt en wie ze doet.

Heb je in een agile team nog een testplan nodig?

Ja, maar een licht plan. Een kort plan per release of per kwartaal houdt scope, risico’s en exitcriteria duidelijk. Het mag in de wiki of backlog van het team staan in plaats van in een los document.

Wie maakt het testplan?

Meestal de testcoördinator of testmanager van het project, samen met het team. Belangrijker dan wie het schrijft, is dat er één eigenaar is die het bijwerkt als de release verandert.