Wanneer na meer dan 30 jaar werkzaam te zijn als testprofessional iemand aan mij vraagt: “wat maakt iemand een goede software tester?” Dan zal mijn antwoord zijn: naast vakinhoudelijke kennis en analytisch vermogen, moet een tester in staat zijn de juiste vragen te stellen, op het juiste moment en aan de juiste persoon.

Het testen van software is een uitdagende job. De uitdaging om te werken met nieuwe technologieën, nieuwe programmeertalen of nieuwe infrastructuren, zorgen er voor dat we steeds weer moeten leren hoe hiermee om te gaan. Gelukkig kunnen we veel van deze technische vragen stellen aan onze grootste vriend voor dit soort vragen: google.

De kans is erg groot dat het antwoord op technische vragen te vinden zijn op het internet. De echte uitdaging ligt dus bij het omgaan met zaken die je niet kunt vinden op internet. Het gaat dan om de functionele en bedrijfsmatige kant van de te testen applicatie en de manier waarop toekomstige gebruikers zullen gaan werken met de applicatie.

Waarom is het stellen van vragen belangrijk?

Vanaf de start van een traject zal een tester vragen moeten stellen om de risico’s inzichtelijk te krijgen en een goed overzicht van de applicatie te verkrijgen. Daarnaast zullen tijdens het bestuderen van de requirements vragen en antwoorden helpen om aannames, onjuistheden, onvolledigheden en tegenstrijdigheden in de documentatie vast te stellen. Het is goed dat je als tester geïnteresseerd bent in het grotere geheel, zoals wat zijn de doelen die met het product gerealiseerd moeten worden en het constant proactief op de hoogte blijven over planningen en tijdlijnen.

Een tester mag nooit aarzelen om gedetailleerde vragen te stellen over requirements die niet gedetailleerd genoeg zijn of inconsistenties bevatten.

In de beschrijving van een requirement kan andere terminologie worden gebruikt ten behoeve van de business, functionaliteit, techniek en het gebruik door een leek. Een tester kan een belangrijke bijdrage leveren om er voor te zorgen dat de requirements begrepen kunnen worden door een ieder die betrokken is.

In de praktijk blijkt ook vaak dat niet alles is beschreven in de requirements en het doen van aannames is het slechtste dat een tester kan doen.

Welke vragen kunnen er gesteld worden?

En hier raken we de kern. Een tester zal vragen moeten stellen die er voor zorgen dat hij kan bepalen wat er wel/niet getest moet worden, met welke diepgang en hoe.

Aan de hand van onderstaand voorbeeld wordt dit toegelicht.

Wat is niet goed aan de geschetste situatie? In de basis is er gewoon de verkeerde vraag gesteld. De productmanager verwacht namelijk terecht dat een tester aangeeft wat er getest moet gaan worden. Eigenlijk werd er aan de productmanager gevraagd om het werk van de tester te doen, in plaats van vragen te stellen die ervoor zorgen dat we zelf als tester kunnen inschatten wat er getest moet worden en met welke diepgang.

Maar hoe dan wel? Er moeten vragen gesteld worden over de applicatie zonder dat het gaat over testen. Probeer inzicht te krijgen in wat belangrijk is voor de gebruiker, of wat de concurrentie voordelen zijn, of wat de applicatie uniek maakt. Het gaat dus om vragen die belangrijk zijn voor degene aan wie je de vragen stelt.

Zo zouden de volgende vragen gesteld kunnen worden aan een productmanager:

• Welke functionaliteiten van de applicatie maken het bedrijf uniek? Wat maakt het anders dan bij andere bedrijven?
• Welke onderdelen zullen of worden er het meest gebruikt door de gebruikers?
• Wat kan ervoor zorgen dat een gebruiker niet met de applicatie wil werken en voor de applicatie van de concurrent zal kiezen?
• Waarmee zullen we het beter doen dan onze concurrenten? Wat zijn de grootste problemen van onze concurrenten? En zijn dat de dingen waarin wij het beter willen doen?
• Zijn er risico’s waar we bewust van moeten zijn? Risico’s op het gebied van de applicatie of de techniek?

Of de volgende vragen aan iemand van de beheerorganisatie:

• In welke delen van de applicatie komen de meeste bugs voor?
• Over welke functionaliteiten krijgen jullie de meeste vragen van gebruikers?

Of de volgende vragen aan het ontwikkelteam:

• Welke risico’s zijn er met de gebruikte technologie?
• In welke delen van de applicatie worden de meeste wijzigingen doorgevoerd?
  Welke onderdelen van de applicatie zijn kwetsbaar?
  Welke onderdelen van de applicatie zijn complex?

Aan wie kun je vragen stellen?

Een belangrijke vraag is: “met wie kun je als tester praten om erachter te komen wat er getest moet gaan worden?” Uiteraard speelt de situatie waarin je werkzaam bent daarin een belangrijke rol. Ben je de eerste of enige tester dan zul je zelf alles moeten ontdekken. Er kan echter ook al veel bekend zijn omdat er een testplan is met daarin een teststrategie. Terwijl bij scrum de product owner weer een belangrijke rol speelt bij het verkrijgen van informatie.

Hieronder vind je een indeling van welke soort vragen aan wie gesteld kunnen worden:

• Stakeholder / projectmanager
  • Vragen die te maken hebben met de visie achter de applicatie of de planning, het budget en de tijdlijnen.
    • Wat is het doel van de nieuwe applicatie of de wijziging?
    • Welke voordelen moet de nieuwe applicatie of wijziging opleveren voor de gebruikers?
    • Hoe is de planning tot stand gekomen en met welke reden?
• Gebruikersgroepen / Helpdesk / Servicecenter
  Het zal niet altijd mogelijk zijn om direct met eindgebruikers te praten. Een belangrijk deel van de vragen kunnen wel gesteld worden aan mensen die werkzaam zijn bij afdelingen die direct contact hebben met de eindgebruikers.

• Welke functionaliteiten zijn het belangrijkst voor de gebruiker?
• Welke niet functionele aspecten zijn belangrijk voor een gebruiker? Denk aan gebruikersvriendelijkheid of performance.
• Wat zorgt er voor dat een gebruiker de applicatie niet zal gaan gebruiken?
• Welke vragen worden gesteld over het gebruik van de applicatie?

• Testmanager / Teamleider
  In grotere teams zul je als tester niet altijd directe toegang hebben tot alle informatie. In dat geval kun je veel vragen stellen aan de testmanager of teamleider.
  • De afgesproken teststrategie en te gebruiken testontwerptechnieken
  • Testomgevingen en tooling.
  • Procedure voor bevindingen en rapportages
  • Aantallen testruns die zijn gepland

• Ontwikkelteam
  Alle technische of softwarecode gerelateerde vragen kun je stellen aan de ontwikkelaars.
  • Welk deel van de code wordt aangepast?
  • Wat is de impact van een nieuw veld op een scherm of formulier?
  • Heeft een wijziging van de gebruikersinterface op een pagina impact op een vervolgpagina?
  • Wat is de impact van het toevoegen van een veld op een formulier op andere interfaces. Deze kunnen verschillende manieren gebruiken om gegevens uit te wisselen tussen componenten.
• Architect
  De architect van de applicatie is een belangrijke informatiebron. De architect bepaalt namelijk de volledige technische oplossing. Hij vertaalt de functionele requirements naar technische componenten, die vervolgens door het ontwikkelteam worden gebouwd. Vragen die betrekking hebben op interactie tussen componenten, webservices, middleware of de database kun je stellen aan de architect.

AAA