Software testen: Bij onduidelijke specificaties, zal het ontwikkelteam beslissingen gaan nemen

  • Martijn de Haan
  • 14 februari 2012

 

 

Wat niet in de specificaties staat, wordt aan het ontwikkelteam overgelaten en … wordt door het testteam (hopelijk op tijd) ontdekt. Een ontwikkelaar zal zelf interpretaties maken van de te bouwen functionaliteit als de systeemvereisten (requirements), Use Cases en designs onduidelijk en dubbelzinnig zijn. Of hij hierin de juiste interpretatie maakt is maar de vraag.

 

Wat te doen?

Valideer de requirements op testbaarheid. Als je geen testcase kunt schrijven voor een requirement dan kun je het requirement ook niet bouwen. Test consultants zijn bij uitstek de juiste personen om deze validatie uit te voeren en dienen daarom vroegtijdig in het project te starten. Eigenlijk al zodra de requirements worden opgesteld. De test consultants valideren of de requirements voldoende concreet, duidelijk, ondubbelzinnig en meetbaar zijn. Daarnaast zullen test consultants ook beoordelen of ze de functionaliteit kunnen testen voor elke modus waarin het systeem zich kan bevinden. De test consultants bepalen voor de requirements ook welke data input, grensgevallen en condities er gebruikt kunnen worden en wat het verwachte resultaat is. Dit gaat vaak verder dan wat in de requirements, Use Cases en designs staat. Maar pas als je een test case voor een requirement kan schrijven dan kan de ontwikkelaar het goed bouwen.


Test Driven Development. Een stap verder …

Een validatie van requirements door de test consultants helpt bij het duidelijker maken van specificaties voor de ontwikkelaars. Je kunt hierin nog een stap verder gaan. In de praktijk blijken test cases voor de ontwikkelaars een goed hulpmiddel om de specificaties beter te begrijpen omdat test-cases meer gedetailleerd en concreter zijn. Op één van mijn vorige projecten, stuurden we de test-cases op naar de ontwikkelaars, die vervolgens riepen: “o, moet het systeem dát doen!”

Het ontwikkelen van software waarbij eerst de test wordt geschreven, wordt ook wel Test Driven Development (TDD) genoemd. TDD is een standaard onderdeel van de Agile SCRUM software ontwikkeling methode. Maar ook in de meer traditionele waterval methode als Rational Unified Process (RUP) kan TDD worden geadopteerd.

 

PS

 

Heb je interesse in een baan als Test Consultant bij Deloitte, bekijk dan deze vacature (of stuur de vacature door aan iemand die mogelijk interesse zou kunnen hebben).

 

Martijn de Haan

Manager Technology

Martijn heeft ervaring in het management van diverse testprojecten (o.a. multi vendor joint integratie test, gebruikers acceptatie test en operational readiness test). Momenteel werkt Martijn binnen system integration als testmanager voor UPC.

Personal Experience Story

  • Melissa Raczak
  • 13 februari 2012
Naar boven