Testaanwijzingen voor de tester

In mijn boek “Agile Testen in de Praktijk” heb ik een hoofdstuk geschreven over testaanwijzingen. In dit hoofdstuk heb ik er expliciet in beschreven dat het geen testscenario’s of teststappen zijn en dat het niet de taak is van de developer om de testen te schrijven voor de tester. In dit blog vertel ik jullie hier graag over omdat het handig en praktisch is om te gebruiken.

Wat zijn de testaanwijzingen precies?

In het Engels zeg je ook wel de “test directions”. De developer geeft de tester aanwijzingen waar deze moet gaan testen. Dat is het. Makkelijker kan ik het niet beschrijven.

Waarom deze testaanwijzingen?

De testaanwijzingen worden door de developers laten invullen bij een bepaalde story. Zo kan je sneller aan de slag met het testen en hoef je de developer niet te storen in zijn flow. Je kunt direct aan de slag en kan dan meters maken. Je hoeft ook niet te wachten.

Ook kan de developer zijn werk op die manier toetsen en controleren of de feature juist is opgeleverd m.b.t. configuratie e.d.

Wat houden de testaanwijzingen in?

Dit lijstje heb ik samen met een collega tester opgesteld en voorgelegd aan het team bij mijn project bij de Gemeente Den Haag. We hebben dit daar ingevoerd en het gaf meer rust in het team.

• De locatie waar de tester moet testen
  • bijvoorbeeld een pad naar het (nieuwe) scherm of een url naar de pagina(s).
    • home > pagina X > pagina Y
    • Klik op KNOP A
• Moeten er nog dingen worden ingesteld?
  • bijvoorbeeld in een bestand, een administratiescherm, configuratie, instellingen o.i.d.
• Moeten er scripts worden gedraaid?
  • Ja?
    • Naam van het script? 
    • Welke developer moet/ kan deze runnen?
    • Kunnen we het zelf? Ja/Nee?
      • Waar en hoe uitleggen
• Tot aan waar is het testbaar
• Eventueel bestanden toevoegen die van belang zijn
  • bijvoorbeeld excel bestanden, sql bestanden etc. bij een import of export functie

Eventueel ook

• Benoemen van bepaalde risico’s / risicogebieden (dependencies aan externe data via API, imports etc waar wij geen controle over hebben etc).
• Bekende issues/beperkingen, de Work in Progress (WIP) functionaliteiten benoemen die pas later wordt gebouwd.

Een aanname doen als tester…

Goed, ik doe de aanname dat jullie als testers dit denk ik wel kunnen waarderen als dit ingevuld en gebruikt zal worden door de developers. Ik ben benieuwd of mijn aanname klopt. Zou je dat willen laten weten in de comments?

Heb je nog vragen of opmerkingen? Zet deze dan onder in de comments. Ik ben benieuwd naar jullie ervaringen en kennis hierin.

Bestel hier mijn boek “Agile Testen in de Praktijk“