Antwoord.

Het testen van vereisten is een belangrijke fase van handmatig testen, omdat tekortkomingen op dit gebied leiden tot kostbare fouten in de toekomst.

Geschiedenis van de vraag:

In de vroege fasen van de ontwikkeling worden de vereisten voor het product vastgelegd in documenten (requirements specifications, technische specificaties). Onjuiste of onvolledige formulering ervan leidt tot veel problemen in de implementatie- en testfases.

Probleem:

Vereisten blijken vaak onvolledig, dubbelzinnig of tegenstrijdig te zijn. Dit leidt tot misverstanden en een gebrekkige uitvoering van het product. De tester moet dergelijke punten tijdig identificeren.

Oplossing:

Handmatig testen van vereisten omvat:

Nauwkeurige audit van vereisten op volledigheid, duidelijkheid en consistentie
Het stellen van verduidelijkende vragen aan analisten en business stakeholders
Documenteren van alle verwachte gebruiksvarianten (positieve/n negatieve gevallen)
Toepassing van technieken voor vereistenanalyse: consistentietabellen, traceerbaarheid matrices, checklists voor vereisten

Belangrijke kenmerken:

Opsporen van tegenstrijdigheden en "hiaten" — identificatie van incongruenties en situaties die niet in de vereisten zijn opgenomen
Actieve communicatie met analisten en het team — verduidelijking van details, uitleg van formuleringen
Vorming van heldere, testbare vereisten — vereisten moeten ondubbelzinnig, uitvoerbaar en meetbaar zijn

Misleidende vragen.

Wat betekent "een vereiste is testbaar"?

Een testbare vereiste is een vereiste waarop je precies kunt zeggen of deze in het product is vervuld of niet. Abstracties, algemene zinnen en onduidelijke parameters zijn niet toegestaan.

Kunnen vereisten als kwalitatief worden beschouwd als ze alleen door de auteurs begrepen worden?

Nee. Kwalitatieve vereisten moeten ondubbelzinnig begrepen worden door alle teamleden (ontwikkelaars, testers, analisten, business).

Behoort het tot de verantwoordelijkheid van de tester om vereisten aan te vullen of te corrigeren?

Nee, de tester identificeert problemen en rapporteert deze aan de verantwoordelijken, maar moet de vereisten niet zelf herschrijven.

Typische fouten en anti-patronen

Vereisten voor waar aannemen zonder verduidelijkende vragen te stellen
Kleine incongruenties en aannames negeren
Gevonden "hiaten" en tegenstrijdigheden niet documenteren, in de hoop dat "ontwikkelaars het wel begrijpen"

Voorbeeld uit het leven

Negatieve geval

De tester ontving de vereisten, controleerde ze niet op volledigheid en consistentie, en lette niet op dubbelzinnige formuleringen. Uiteindelijk interpreteerden ontwikkelaars deze vereisten op verschillende manieren, er ontstonden niet-beschouwde scenario's die pas tijdens de release opdoken.

Voordelen:

Tijd bespaard in de fase van het opstellen van vereisten

Nadelen:

Veel correcties in latere fasen
Hoge kosten voor bugfixing
Onvrede bij de klant

Positieve geval

In de fase van het bekijken van de vereisten stelde de tester vragen voor de businessanalist, verduidelijkte controversiële punten en hielp negatieve scenario's toe te voegen. Dit hielp om veel misverstanden te vermijden en het aantal bugs bij de release aanzienlijk te verlagen.