Een van de producten die een softwaretestproces oplevert, is het testplan. Volgens de International Software Testing Qualifications Board is dit een document dat de scope en activiteiten omschrijft van de tests binnen een softwareontwikkelproject. Deze definitie is niet onwaar, maar het verbaast me dat zij niets zegt over de teststrategie. Voor mij is dat namelijk een van de belangrijkste onderdelen van het testplan. De teststrategie definieert hoe we de kwaliteitsdoelstellingen van het project vertalen naar activiteiten die we moeten ondernemen om aan te tonen dat we die doelen hebben behaald. Anders gezegd: de business wil complete en goed werkende software die aansluit bij hun processen en wij testers informeren hen graag gedurende het project over de mate waarin dit het geval is.
Natuurlijk moeten we in grote projecten veel regelen, is er afstemming nodig tussen verschillende ketenpartners en moeten we nadenken over een heleboel technische aspecten. Het is echter de strategie die het verschil maakt. Een slimme strategie maakt het werk doelgerichter en de waarde die we toevoegen inzichtelijk. Door de strategie op te nemen in het testplan wordt dit een belangrijk document, dat de business uitlegt hoe we hun punten van zorg aanpakken.
Menig testplan komt echter niet verder dan een saai projectplan, dat de gebruikte template niet ontstijgt. In mijn dagelijkse werk krijg ik regelmatig testplannen onder ogen en regelmatig wind ik me daarbij redelijk op. Soms lijken ze alleen maar gemaakt om het team in te dekken en staan ze vol algemeenheden. Als ik ze als vakidioot al saai vind, hoe krijgen we dan ooit waardering voor ons werk. Om over commitment maar te zwijgen.
This article is exclusively available to premium members of Bits&Chips. Already a premium member? Please log in. Not yet a premium member? Become one for just €20 for the first year and enjoy all the benefits.
