Teststrategie

Tijd voor een teststrategie in de lijn van TMap, maar dan veel eenvoudiger. We willen tenslotte snel aan de slag.

De vorige stap was het zoeken naar alle belangrijke risico’s. Eigenlijk was dat geen testactiviteit, maar het is wél een onmisbare stap vóórdat je begint aan een teststrategie. En die teststrategie rolt er nu heel makkelijk uit. Je verdeelt de beschikbare tijd over drie testactiviteiten. En je verzwaart die activiteiten als het risico hoger is.

  • Activiteit 1 is reviewen; bekijk de informatie die vooraf beschikbaar is. Is deze informatie compleet, duidelijk en correct? En hebben de juiste personen hun inbreng gehad?
  • Activiteit 2 is systeemtesten; als het om de goede vertaling van specificaties naar gebouwde software gaat, dan wil je een zwaardere systeemtest.
  • Activiteit 3 is acceptatietesten; als het gaat om acceptatie en ‘een goed gevoel’, verzwaar dan de acceptatietest met een groter aantal acceptanten, die er uitgebreider en gestructureerder naar kijken.

Ik zal meteen maar laten zien hoe zo’n teststrategie matrix er dan uit ziet. Waarbij de donkerblauwe cellen niets anders zijn dan de hoge risico’s uit de risicomatrix van de vorige pagina.

teststrategie matrixDe teststrategie (als matrix)

Hoge risico scores krijgen dus meer aandacht, het liefst al in de vorm van een review.

Een logische vuistregel; als je functionaliteit, beveiliging of continuïteit belangrijk vindt, richt je je al snel op systeemtesten. Zijn gebruiksvriendelijkheid, inpasbaarheid of beheerbaarheid belangrijk, dan denk je eerder aan een zware acceptatietest. Performance hangt er een beetje tussenin; op individueel niveau is het meer acceptatietest, load en stress testen zijn vooral systeemtest.

Uitschrijven van test activiteiten

Zo’n matrix moet nog worden vertaald voor de mensen die uiteindelijk gaan testen. Het is belangrijk om meteen uit te schrijven wat er moet gaan gebeuren. Een voorbeeld.

Reviewen van gebruiksvriendelijkheid (+++)

Voor de modules ‘Artikelen’, ‘Winkelwagen’ en ‘Bestelling’ geldt; de specificaties over gebruiksvriendelijkheid worden uitgeschreven – ook op veldniveau – en vooraf gereviewd tegen de eisen van zowel de afdelingen Communicatie en Marketing als tegen gangbare marktstandaarden (door een extern bureau). Ook wordt de volledigheid en duidelijkheid gecontroleerd en wordt al een inschatting van de technische haalbaarheid gemaakt.

Systeemtesten van gebruiksvriendelijkheid (++)

Tijdens de systeemtest wordt een expliciete test gedaan op alles wat is gespecificeerd over gebruiksvriendelijkheid. Denk aan veldformaten, veldlengtes, tabvolgorden en regels om automatisch bekende gegevens aan te vullen.

Acceptatietesten van gebruiksvriendelijkheid (+++)

De  modules ‘Artikelen’, ‘Winkelwagen’ en ‘Bestelling’ worden volledig getest op gebruiksvriendelijkheid door de afdelingen Communicatie en Marketing. Alle testen worden vooraf gespecificeerd (via afvinklijstjes) en onderling gereviewd in een review sessie, en alle testresultaten worden vastgelegd en ondertekend door de twee afdelingshoofden.

Later zal ik meer voorbeelden toevoegen, maar ik denk dat dit het speelveld aardig aangeeft. En bovenstaand voorbeeld is misschien wat extreem, maar het punt is; als je iets héél belangrijk vindt, kun je ook héél veel uit de kast halen om genoeg inzicht te krijgen.

> > Door naar reviewen

Plaats als eerste een reactie!

Naam*: E-mail*: