Voldoet de IT-applicatie aan de verwachting?
In mijn praktijk als deskundige word ik geconfronteerd met het feit dat een IT-toepassing die is gemaakt, als configuratie van een standaard softwarepakket of als maatwerk, niet voldoet aan de verwachtingen van de opdrachtgever. Er was een prettige start van het project, maar gaandeweg zijn verwachtingen en resultaat uit elkaar gedreven. En dan is vaak de mening van de opdrachtgever dat het nieuwe systeem niet werkt, fouten bevat, niet voldoet, terwijl de leverancier bij hoog en laag volhoudt dat het systeem “af” is conform de afspraak die eerder is gemaakt. Tja, dan is de basis voor een conflict gelegd.
Er zijn diverse methodes doe de kans op een mislukking verkleinen en ieder van die methodes heeft een element van testen in zich.
In deze blog kenmerken van een goede opzet voor testen.
Wat is testen?
Daarvoor terug naar een definitie voor het testen van software. Testen kan worden gedefinieerd als:
- Een verzameling activiteiten die uitgevoerd wordt om een of meer kenmerken van een product, proces of dienst vast te stellen volgens een gespecificeerde procedure. [ISO/ IEC, 1991]
- Een proces dat inzicht geeft in, en adviseert over, de kwaliteit van de software en de daaraan gerelateerde risico’s.
- Het proces waarmee de correcte werking van een systeem of product wordt aangetoond.
- De activiteit waarbij de kwaliteit van het gehele systeem of product wordt gecontroleerd.
- Het methodische proces van het aantonen van afwijkingen tussen de werkelijke werking versus de verwachte werking van een systeem of product.
- Activiteiten zoals meten, onderzoeken, beproeven, keuren met kalibers van één of meer kenmerken van een product of dienst en het vergelijken van de uitkomsten met de gestelde eisen, om te bepalen of aan deze voorwaarde is voldaan. (Definitie volgens de standaard ISO 8402.)
Wanneer ik het heb over testen in de verhouding opdrachtgever – IT-leverancier in het kader van verwachtingen (het systeem doet wel of niet wat is verwacht), dan doel ik op de met name op definities 3 en 5:
- Werkt het systeem correct?
- Werkt het nieuwe systeem zoals de opdrachtgever verwacht?
Voor beide aspecten zijn goede methodes voorhanden om dit vast te stellen. In deze blog het eerste aspect:
Werkt het systeem correct?
Testen om een correcte werking vast te stellen vereist dat er een criterium is op basis waarvan geconcludeerd kan worden wat wel correct is en wat niet correct is. Dit levert een Ja/Nee conclusie, die natuurlijk niet een enkelvoudig Ja of Nee is, maar uit vele keren Ja/Nee bestaat.
Een verkeerde aanpak is
om de testcriteria pas op te stellen
als het systeem in een testfase is gekomen
Oftewel: achteraf worden gevallen gedefinieerd die moeten vaststellen of het nieuwe systeem correct werkt. En dat is verkeerd, want dan wordt achteraf, als het feit al is geschied, bepaald wat de regels zijn waarop het spel gespeeld moet worden.
Vergelijk het met het maken van een doelpunt: de bal komt op de doellijn, maar op wordt op dat moment er weer net weer door de keeper uitgetikt. Als men op dat moment pas vaststelt dat er een doelpunt is als de bal in zijn geheel de doellijn is gepasseerd, dan ontstaat er discussie met de partij die er van mening is dat de bal op de lijn voldoende is voor een doelpunt.
Kortom: de criteria voor goed of fout moeten vooraf overeengekomen worden.
Wanneer moeten de testcriteria worden vastgesteld?
Er is maar één correct moment in de tijd om testcriteria vast te stellen: tijdens het opstellen van de functionele eisen (het functionele ontwerp). Iedere functie waarvan de opdrachtgever wil vaststellen of deze correct werkt dient voorzien te worden van een testgeval (een testcase), waarmee een Ja of Nee kan worden vastgesteld. Een bestaande werkwijze (waarvoor het nieuwe systeem wordt gemaakt), kan goed dienen als basis voor de testgevallen. Het totale samenstel van alle testgevallen die in het functioneel ontwerp worden vastgelegd vormen de basis voor de acceptatietest.
Een acceptatie is geslaagd gezien alle afgesproken testgevallen zonder productiebelemmerend resultaat kunnen worden doorlopen. Leveren een of meer testgevallen een productiebelemmering op, dan faalt de acceptatietest.
Gestructureerd vastleggen van de testresultaten is belangrijk,
een Excel sheet of Word document volstaat niet
Gebruik een issue tracking systeem, waarmee taken, voortgang, besluiten, afhandeling, prioriteit, verantwoordelijkheden, schermafdrukken, resultaten, enz. kunnen worden vastgelegd. Er zijn diverse goede gereedschappen, zoals Trello, Jira of Basecamp die qua toepasbaarheid de mogelijkheden van Excel of Word ver overstijgen. Gebruik van zo’n oplossing voor het vastleggen van testresultaten betaalt zich binnen de kortste keren terug.
In een volgende blog aanwijzingen voor de tweede vraag: werkt het nieuwe IT systeem zoals de opdrachtgever verwacht?
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.