In mijn vorige blog heb ik het gesproken over de twee vormen van testen van een IT systeem: op correctheid en op het voldoen aan verwachtingen. In een vorige blog heb ik mijn ervaringen beschreven met testen op correctheid, in deze blog een antwoord op het testen van een lastiger vraag:
Voldoet het systeem aan de verwachtingen?
Dit is een lastiger criterium om te testen: want wat zijn de verwachtingen van de opdrachtgever? En zijn die verwachtingen aan het einde van het project nog hetzelfde als aan het begin? Of is er sprake van (sluipend) voortschrijdend inzicht?
Een methode om verschil van verwachtingen en resultaat te verkleinen is om vooraf een aantal niet functionele criteria vast te stellen waaraan het nieuwe systeem moet voldoen, bijvoorbeeld responstijd per scherm, beveiligingsniveaus, aantallen transacties per tijdseenheid die verwerkt moeten kunnen worden, benodigde infrastructuur, enz. En hierop moet niet worden bezuinigd. Vanuit de leverancier bijvoorbeeld moet een infrastructuur worden aangegeven die ruim voldoet, vanuit de opdrachtgever een uitdagend target voor aantallen en bijvoorbeeld responstijd.
Leg de lat aan het begin van het project hoog
Een maatregel om het risico op een conflict te vermijden is om aan het begin van het project overeen te komen hoe met verschil tussen verwachting en resultaat wordt omgegaan. Een mogelijkheid hierbij is om een “grijze” lijst bij te houden die de issues bevat waarvan leverancier en opdrachtgever van mening verschillen gecombineerd met een afspraak hoe met deze issues wordt omgegaan, bijvoorbeeld een besluit op een hoger niveau, het delen van de kosten, het inwinnen van extern bindend advies.
Een werkbare methode om verwachtingen en resultaat met elkaar in de pas te laten lopen is door frequent opleveringen te doen en tussenresultaten te toetsen. Gecombineerd met de afspraak om de bevindingen van opdrachtgever en leverancier vast te leggen. Is het verschil tussen verwachting en resultaat te groot, dan is er tijdens het project nog gelegenheid maatregelen te treffen om het verschil te verkleinen. Wanneer pas aan het einde van het project vastgesteld wordt dat het verschil tussen verwachting en eindresultaat onoverbrugbaar groot is, dan is de basis voor de escalatie van het geschil gelegd.
Meer weten over praktisch software testen?
Ik kom graag een keer praten wat de mogelijkheden zijn voor de praktische inrichting voor testen: zowel voor de correctheid of in relatie tot verwachtingen. Start vroeg en wacht niet tot dat het een conflict is geworden.
Beter vroegtijdig recht gezet, dan achteraf voor het gerecht gezet.