Voorkomen van fouten

In het artikel over “waar ontstaan de meeste fouten in software” kun je lezen dat 56% van de fouten ontstaan in de requirements en dat het daarnaast met testen niet mogelijk is om deze fouten te vinden.

50% van deze fouten zijn het resultaat van slecht geschreven, onduidelijke, voor meerdere uitleg vatbare en onjuiste requirements. De andere 50% van deze fouten ontstaan door onvolledig specificaties als gevolg van het niet volledig verwerken van de requirements of het weglaten van requirements.

In dit artikel gaan we in op welke rol een tester kan spelen om fouten in de requirements te voorkomen of te vinden.

In het algemeen worden requirements beschreven in een natuurlijke taal, zoals Nederlands of Engels. Het beoordelen van de requirements vind dan ook vaak plaats door mensen met behulp van een checklist of peer reviews.

Wanneer je als tester zo vroeg mogelijk in het traject betrokken wordt bij de beoordeling van de requirements zul je een toegevoegde waarde hebben in het voorkomen dat fouten in de requirements doorwerken in de specificaties en uiteindelijk in de code.

Binnen Agile/Scrum kan dat al tijdens de refinement en bij waterval direct na de requirementsfase.

Hoe requirements beoordelen

Alhoewel er tegenwoordig tools beschikbaar zijn die requirements op een aantal aspecten kunnen beoordelen, wordt het beoordelen van de requirements meestal handmatig uitgevoerd op basis van een checklist of door reviews.

Het gebruiken van checklists is niet alleen handig voor het beoordelen van de requirements, maar kunnen uiteraard ook gebruikt worden door de opstellers van requirements om het maken van fouten te voorkomen.

Waarop requirements beoordelen

De punten waarop je requirements op kunt beoordelen zijn onder te verdelen in een aantal categorieën. Hieronder een voorbeeld van een checklist.

• Uniek identificeerbaar
  • Zijn de requirements uniek te identificeren?
• Prioriteit
  • Is van alle requirements de prioriteit bepaald?
• Volledigheid
  • Is bij elke requirement de rationale (de reden voor) vastgelegd?
  • Is bij elke requirement de bron vastgelegd?
  • Zijn bij de requirements acceptatiecriteria beschreven?
• Consistentie
  • Zijn de requirements onderling consistent met elkaar?
  • Zijn de requirements intern consistent met requirements van hetzelfde niveau
  • Zijn de requirements extern consistent met requirements van een hoger niveau?
• Duidelijkheid
  • Zijn de requirements maar voor een (1) uitleg vatbaar?
  • Kunnen requirements maar op een (1) manier geïnterpreteerd worden?
  • Worden er termen gebruikt die meer dan een (1) betekenis kunnen hebben? Zo ja, zijn deze termen uitgelegd?
  • Wordt er gebruik gemaakt van verboden woorden? Is er bijvoorbeeld een lijst met zogenoemde ‘fuzzy’ termen?
  • Bevatten de requirements geen oplossingsrichtingen?
• Atomair
  • Is er sprake van samengestelde requirements? Een requirement mag maar betrekking hebben op een (1) eis.
• Meetbaar / testbaar
  • Zijn de requirements testbaar en meetbaar?
  • Kunnen er testgevallen opgesteld worden op basis van de requirements?
• Traceerbaarheid
  • Zijn de requirements te traceren naar een hoger requirement?
  • Zijn de requirements te traceren naar een lager requirement?
• Taalgebruik
  • Wordt gebruikgemaakt van enkelvoudige en eenvoudige zinnen?
  • Wordt er gebruikt gemaakt van direct taalgebruik om requirements te specificeren?
• Voldoen aan standaards
  • Voldoen de requirements aan de vastgelegde documentatie standaards?
  • Voldoen de requirements aan de Interne en externe regels
  • Worden annotaties (toelichtende tekst) duidelijk afwijkend gedocumenteerd van de requirements

Is het gebruiken van een checklist voldoende?

Nee, een checklist alleen is niet voldoende. Een checklist is een leidraad, maar hoe je requirements kunt interpreteren, aannames kunt herkennen en de juiste vragen weet te stellen zul je moeten leren. Het heeft namelijk te maken met kritisch denken. En je wordt niet geboren als kritische denker, maar je kunt er wel een worden.