Testen van software binnen uw project

Er komt een moment waarop uw leverancier u vraagt om het voorlopige eindresultaat van uw IT-project te testen. Er wordt dan van u verwacht dat u een rapport aanlevert met daarin de eventuele punten waarop het geleverde niet voldoet.

Testen blijkt vaak een drempel. Enerzijds omdat u hier echt voor moet gaan zitten, anderzijds omdat het betekent dat uw project hiermee zijn einde nadert. Na de testfase en de uitwerking daarvan, accepteert u het product en kunt u ermee gaan werken. Dat is leuk en spannend tegelijk.

Testkader

U moet een helder overzicht hebben van wat uw project inhoudt: wat hebben we precies afgesproken? Dit is uw testkader. Bij eenvoudige aanpassingen heeft het weinig zin om een heel programma door te testen. Bedenk echter wel op welke onderdelen van uw programma de aanpassing invloed heeft. Denk bijvoorbeeld aan invloed op de werking van rapporten, exports, rollen en rechten en gerelateerde modules. Ook dat valt binnen uw testkader. Bij grotere aanpassingen, of aanpassingen met een bredere impact, moet u wel het hele systeem opnieuw testen om te controleren of alles nog werkt (regressietesten noemen we dat).

Ook kan het zijn dat een kleine wijziging onbedoeld grote impact heeft. Denk dus goed na over de mogelijke impact van een wijziging en pas daar uw teststrategie op aan.

Testscenario’s

Als uw testkader duidelijk is, kunt u testscenario’s opstellen. Elk testscenario representeert een situatie die zich voor kan doen. Bijvoorbeeld: het aanmaken van een contactpersoon, het wijzigen van een contactpersoon of het verwijderen van een contactpersoon. Een testscenario kan ook zijn: twee mensen die vanaf verschillende apparaten inloggen op dezelfde website. Denk bijvoorbeeld ook eens aan inloggen met verschillende rechtenprofielen of het benaderen via verschillende browsers. Voorzie elk testscenario van de gewenste uitkomst.

Als u een functioneel ontwerp heeft gemaakt, dan heeft u waarschijnlijk ook zogenaamde Use Cases vastgesteld. Het kan erg zinvol zijn om in elk geval voor elke Use Case een testcase te maken.

Testrapport

Nu heeft u een overzicht van de handelingen die u gaat doen tijdens het testen. U kunt nu elk scenario gaan uitvoeren. Alles wat niet gaat zoals de gewenste uitkomst voorschrijft, neemt u op in het testrapport. Scheid de bevindingen zo veel mogelijk van elkaar, dan is het duidelijk wat er precies moet worden opgelost.

Een goed testrapport bevat per bevinding:

• een uniek nummer;
• verwijzing naar betreffende specificatie/afspraken;
• onderdeel project ja/nee;
• betreffende module;
• het uitgevoerde testscenario;
• het verwachte resultaat (bijvoorbeeld: als ik y doe moet x goed gaan en z hoort fout te gaan);
• werkelijke resultaat;
• type bevinding: Fout in de software (bug), Wens*, fout in testscripts/scenario’s**, fout in ontwerp*, fout in documentatie, Vraag om uitleg.

* Een Wens of Fout in het ontwerp hoort niet thuis in een testrapport, maar wordt daar om praktische reden wel vaak aan toegevoegd.

** Overweeg een fout in de testscripts of scenario’s te herstellen alvorens verder te testen. Het heeft vaak geen toegevoegde waarde om deze ogenschijnlijke fouten in de software bij uw leverancier te melden.

Tips bij het testen

Breng nooit wijzigingen in de programmatuur aan terwijl u aan het testen bent. Vraag dit ook niet aan uw leverancier. Dit vertroebelt het testrapport en maakt dat issues niet meer te reproduceren zijn. Uitzondering kan zijn een bug waardoor het testen onmogelijk wordt gemaakt. Onderbreek dan het testen en laat deze bug eerst herstellen. Hervat daarna het testen.

Natuurlijk is dit ook een mooi moment om na te denken over mogelijke verbeteringen, maar verwar deze dan niet met fouten (in de inrichting) of bugs (programmatuur werkt niet goed in de basis). Denk ook goed na over de prioriteiten. Gaat het u ook om de details van de vormgeving? Of gaat het u met name om de functionaliteit? Wat is hier eigenlijk over afgesproken?

Als u met een team van mensen test, laat dan een persoon het centrale aanspreekpunt vormen. Deze persoon bundelt alle bevindingen en communiceert hierover met de IT-leverancier.

Testen – wat gebeurt er na het indienen van mijn testrapport?

Uw leverancier zal per punt reageren op wat u heeft ingediend. U moet samen overeen gaan komen welke punten onder de afspraken vallen en welke punten daarbuiten vallen. In het contract en de verdere documentatie staat welke functionaliteit u mag verwachten.

Nadat u overeen bent gekomen wat er nog moet gebeuren, zal uw it-leverancier hiermee aan de slag gaan. Daarna wordt het geheel weer ter test aangeboden. Dit gaat zo door, totdat u akkoord geeft om op te leveren. Ga bij het hertesten net zo zorgvuldig te werk als bij de eerste test. U kunt uw originele testscenario’s hergebruiken. Afhankelijk van de inhoud van het project, zal na uw akkoord het opgeleverde live worden gezet (soms is de eerste oplevering al in de live-omgeving).

Testen is een verantwoordelijke projectactiviteit

Testen en hertesten is een belangrijk onderdeel van uw project en neemt meer tijd in beslag dan vaak gedacht, al snel 25% van de projecttijd. Genoeg aandacht hiervoor en een goede communicatie rondom het testen bevordert het verloop en geeft een snellere acceptatie en een hogere tevredenheid achteraf.

Bereid uw test dus zorgvuldig voor en voer deze zorgvuldig uit. Denk niet te lichtvaardig over testen.

Als u bij een leverancier functioneel aangeeft wat u wilt hebben, moet u ook controleren of uw leverancier dat heeft opgeleverd. U bent de enige die dat kan controleren, dat mag u nooit aan uw leverancier overlaten. Ook al is uw vertrouwen in uw leverancier nog zo groot, een communicatieprobleem en andere interpretatie van functionele specificaties is zo geïntroduceerd. Dat is echt niet altijd onwil van uw leverancier!

Houdt u aan de deadlines

Zoals bij elke projectactiviteit is het zaak iedereen scherp te houden. Voer uw tests conform planning uit en lever binnen de afgesproken tijd uw testrapport op aan uw leverancier. Dat is ook in uw eigen belang. Immers ook uw leverancier heeft tijd gereserveerd om (eventuele) bugs op te lossen. Als u uw testrapport niet tijdig naar uw leverancier stuurt kan het zijn dat de gereserveerde capaciteit opnieuw moet worden ingepland, dat kan later zijn dan u verwacht. Het kan zijn dat daardoor ook uw eigen planning in de knel komt.

In gebruik nemen is accepteren

Het in gebruik nemen van de software staat veelal gelijk aan het accepteren van het eindresultaat.  Het is een juridische handeling waarmee u aangeeft het door de leverancier opgeleverde resultaat van voldoende kwaliteit te vinden om in productie te nemen. Een leverancier zal u meestal wel vragen of de software live mag. Als u ja zegt mag de leverancier er vanuit gaan dat u alle relevante tests heeft uitgevoerd. Ook als de leverancier van u geen testrapport heeft gehad.