Hoe je als tester fouten in requirements kunt helpen voorkomen, zodat er minder fouten in software zullen ontstaan

Voorkomen van fouten

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.

“Unless requirement & design defects are prevented or removed before coding starts, they will eventually find their way into the code where it may be difficult to remove them.”

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.

Doelstelling
Requirements moeten duidelijk en specifiek zijn zonder open eindjes, requirements moeten meetbaar en testbaar zijn en requirements moeten volledig en zonder tegenstrijdigheden zijn.

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
  • 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.

Ook interessant?

wet van Boehm

Wet van Boehm uitgelegd – TestTalk Whiteboard

Deze TestTalk whiteboard gaat over de wet van Boehm. De volgende onderwerpen worden besproken: - Wat is de wet van ...
Meer Lezen
Omgaan met requirements - Test Talk whiteboard

Omgaan met requirements – Test Talk whiteboard

Deze Test Talk whiteboard gaat over het omgaan met "Requirements". En dan toegespitst op ontbrekende of slechte requirements. De volgende ...
Meer Lezen
Waar ontstaan fouten in de software

De #1 oorzaak van fouten in software en hoe die te voorkomen.

Eigenlijk weten we wel dat het merendeel van de fouten, die in applicaties gevonden worden tijdens het testen of in ...
Meer Lezen
herstelkosten

Verschil tussen testen en toetsen

Testen en toetsen zijn detectieve kwaliteitsmaatregelen die er op gericht zijn vast te stellen of bepaalde problemen of tekortkomingen zich ...
Meer Lezen
Blijf op de hoogte van onze nieuwste ontwikkelingen, schrijf je hier in voor de nieuwsbrief!