Eigenlijk weten we wel dat het merendeel van de fouten, die in applicaties gevonden worden tijdens het testen of in productie, hun oorsprong hebben in de requirements of specificaties.

Een onderzoek van IT consultant James Martin, Pulitzer prijswinnaar, toont bijvoorbeeld aan dat:

• 56% van de fouten ontstaan bij het opstellen van de requirements en de specificaties.
• 50% van deze fouten het resultaat zijn van slecht geschreven, onduidelijke, voor meerdere uitleg vatbare en onjuiste requirements
• 50% van deze fouten ontstaan door onvolledig specificaties als gevolg van het niet volledig verwerken van de requirements of het weglaten van requirements
• 82% van het herstellen van fouten te maken heeft met fouten in de requirements

Deze resultaten worden onder meer bevestigd door STBC in The Economics of Testing en door S.A. Kelkar van het Indian Institute of Technology in het boek Structured Systems Analysis and Design.

Een verdere bestudering van deze onderzoeksresultaten laat zien dat 56% van de fouten ontstaat bij het opstellen van de requirements, 27% in de ontwerpfase, 10% overige oorzaken en maar 7% van de fouten ontstaat bij het programmeren.

Waar ontstaan fouten in de software

Wat zijn de kosten voor het oplossen van fouten?

In de vorige paragraaf heb je kunnen lezen waar fouten ontstaan. In deze paragraaf zullen we ingaan op de kosten die er zijn voor het oplossen van deze fouten.

Verschillende onderzoeken, van onder andere Boehm in 1979 of IBM Systems Sciences Institute, tonen aan dat hoe later in de levenscyclus van een applicatie een fout wordt gevonden des te duurder het wordt om deze fout op te lossen. Alhoewel de onderzoeksresultaten verschillen over de exacte ratio’s, wordt vaak de volgende regel gehanteerd: 1:10:100.

Dit houdt in dat wanneer het oplossen van een fout 1 unit (euro, uur) kost tijdens het opstellen van de requirements of specificaties, het oplossen van dezelfde fout tijdens systeemtest/acceptatietest 10 x zoveel kost en het oplossen van dezelfde fout in productie 100 x zoveel.

Over de hier genoemde ratio’s wordt tegenwoordig regelmatig gezegd dat ze niet echt wetenschappelijk zijn onderbouwd. Dit doet echter niets af aan het feit dat het oplossen van fouten die gevonden worden in productie meer oplossingstijd kosten. Er moeten namelijk requirements/specificaties worden aangepast, vervolgens moet de code worden aangepast en moet er worden getest. Wanneer je dus fouten in de requirements al kunt vinden voordat er ook maar een letter is gecodeerd zal dat altijd goedkoper zijn. Hoeveel goedkoper kan per organisatie of gehanteerde werkwijze verschillen. En dit gaat ook op voor het werken in een Agile/Scrum omgeving. Want ook daar moeten backlog items, stories, etc worden aangepast.

Voorbeeld

Stel je hebt het volgende requirement:
Verzekering mag alleen worden afgesloten als de persoon ouder is dan 21 jaar

Dit requirement blijkt echter niet juist te zijn. Het moet zijn: 21 jaar of ouder

Moment waarop fout is gevonden versus uit te voeren herstelwerkzaamheden:

Welke fouten worden gevonden met testen en wanneer?

Het antwoord op deze vraag is afhankelijk van het moment van ontstaan van de fout en de testbasis die gebruikt wordt voor het opstellen van de testgevallen.

Kun je fouten in de requirements vinden met testen?

Het antwoord daarop is, nee. De testen die gebaseerd worden op de requirements hebben als doel om vast te stellen dat de applicatie voldoet aan de requirements. Is het requirement fout en is deze correct (volgens requirement) gebouwd dan zullen we deze fout dus niet vinden met testen.

Kun je fouten in de specificaties vinden met testen?

Het antwoord daarop is, ja. Wanneer een requirement niet goed wordt verwerkt in de specificaties dan kan dit met testen worden geconstateerd. Tenminste als de testgevallen worden gebaseerd op de requirements.

Voorbeeld

Requirement
Een verzekering mag alleen worden afgesloten door iemand die 21 jaar of ouder is

Specificatie
Als leeftijd > 21
Dan verzekering afsluiten toegestaan
Anders melding “je moet ouder zijn dan 21 jaar om deze verzekering af te kunnen sluiten”

De fout in deze specificatie is dat wanneer iemand 21 jaar is er geen verzekering kan worden afgesloten. En dat is niet conform het requirement.

Wanneer je op basis van de requirements testgevallen opstelt met bijvoorbeeld grenswaardenanalyse krijg je 3 testgevallen:

• Jonger 21 jaar (verzekering niet toegestaan)
• 21 jaar (verzekering toegestaan)
• Ouder 21 jaar (verzekering toegestaan)

Wanneer de software is gebouwd conform de specificatie zal met deze testgevallen de fout in de specificaties worden ontdekt. Testgeval 2 zal namelijk een onjuist resultaat geven. De software voldoet in dit geval wel aan de specificaties, maar niet aan het requirement.

Kun je fouten in de code vinden met testen?

Het antwoord op deze vraag is, ja. Wanneer de specificaties niet correct worden omgezet naar code dan kun je dit constateren als je de testgevallen baseert op de requirements of specificatie.

Samenvatting

In de eerste paragraaf hebben we beschreven dat 56% van de fouten ontstaan in de requirements en 27% in de specificaties. In de paragraaf over welke fouten we kunnen vinden met testen hebben we beschreven dat fouten in de requirements niet kunnen worden gevonden met testen en die in de specificaties wel.

En daarnaast hebben we aangegeven dat hoe later in het traject fouten worden ontdekt, des te meer inspanning er nodig is om deze te herstellen.

Fouten in de requirements kunnen we uiteindelijk pas ervaren in productie. Dat zijn uiteindelijk dure fouten om te herstellen.

Dan blijven we natuurlijk met de vraag zitten hoe gaan we die fouten in de requirements ontdekken of voorkomen.

Vanuit het test vak wordt er al tijden aangegeven dat testers zo vroeg mogelijk in het traject betrokken moeten worden. Wat dat volgens ons inhoud en of dat kan helpen met het voorkomen van fouten in de requirements kun je lezen in: “hoe testers fouten in de requirements kunnen helpen voorkomen”. Daarin gaan we ook in op de “Shift left” gedachte.