Het nut en de noodzaak van testen

Bij de invoering van nieuwe software voor informatiebeheer of documentbeheer komt heel wat werk kijken. Het hele traject voor de keuze, de selectie en de evaluatie voor de aanschaf van software, de aanschaf zelf en de implementatie daarop volgend is gecompliceerd en tijdrovend. Voor het volledige traject verwijzen we naar het artikel softwarekeuze.

Als adviseurs komen we regelmatig tegen dat klanten een catalogusprogramma of een document management systeem aanschaffen, zonder het in de praktijk te toetsen aan de bruikbaarheid en geschiktheid voor de specifieke situatie. Dikwijls wordt geredeneerd dat wat goed is voor de ene ook geschikt is voor de andere instelling. ook omdat de leverancier altijd zal zeggen dat al uw wensen vervuld kunnen worden. Dat doet hij niet om u willens en wetens te misleiden, maar omdat hij in zijn product gelooft. Echt slechte producten zijn er ook niet, maar niet ieder product past bij elke willekeurige bibliotheek of instelling. Het loont daarom de moeite om vóór over te gaan tot de aanschaf van een softwarepakket, een proof of concept te doen.

Proof of concept

De PoC omvat zowel een technische test als een functionele test. De technische test wordt uitgevoerd aan de hand van acceptatiecriteria die door ICT worden opgesteld. De technische test heeft onder meer tot doel te meten hoe de performance is, welke effecten de software heeft op de werking van andere software, welke problemen zich kunnen voordoen en hoe deze verholpen kunnen worden.

We richten ons in dit artikel op de functionele test. Samenvattend kan men zeggen dat het doel van de functionele test is:

  • Evalueren van de functionaliteit (‘zit alles er in wat ik nodig heb’)
  • Evalueren van de gebruiksvriendelijkheid (‘kan ik er gemakkelijk mee omgaan’)
  • Evalueren van de efficiency (‘levert het me tijd op’)

Daaraan kunt u uiteraard zelf opties toevoegen.

Het doen van een Proof of Concept of test is om drie redenen noodzakelijk:

  • Een Proof of concept (PoC) heeft als doel te achterhalen of het geselecteerde software pakket voldoet aan de eisen en verwachtingen die u heeft gesteld. Die eisen en verwachtingen heeft u in een eerder stadium vastgelegd in het functioneel model, een beschrijving van hetgeen het systeem moet doen en waarvoor het wordt gebruikt en in het Programma van Eisen. In het Programma van Eisen (PvE) zijn alle eisen en wensen opgenomen met een weging van het belang dat u er aan hecht.
  • Een PoC heeft daarnaast tot doel te bepalen hoe men het softwarepakket ingericht wil hebben en welke zaken extra aandacht nodig hebben bij een implementatie. Als onderdeel van de PoC kan men ook een proefconversie laten doen van de data uit uw huidige systeem naar het nieuwe systeem.
  • Een belangrijk doel van de test is te beproeven of de gebruikers met het systeem willen en kunnen omgaan. Een opleiding in het pakket dient deel uit te maken van de PoC, zodat de testers in ieder geval kennis hebben gemaakt met de werkwijze.

Voor de test wordt op basis van het bovenstaande een testplan opgesteld.

Het testplan bestaat uit drie delen:

  1. Een beschrijving van de wijze waarop de test zal worden uitgevoerd, met wie en wanneer en een beschrijving van het doel, de middelen, de voorwaarden en de acceptatiecriteria. De voorwaarden zijn bijvoorbeeld dat iedere tester een opleiding moet hebben gedaan, kan beschikken over de software met een handleiding en dat de gebruikersrechten moeten zijn geregeld.
  2. Het testscript waarin de opdrachten zijn beschreven die door de testgroep worden uitgevoerd. Het testscript bestaat uit twee onderdelen:
    – toelichting op alle handelingen per functie (waarom en hoe)
    – opdrachten die moeten worden uitgevoerd door de testers
  3. Een evaluatieformulier waarop de testers hun bevindingen kunnen noteren. Dat kan aan de hand van vragen of een score.

Het testen zelf kan individueel of groepsgewijs plaatsvinden, maar het moet wel gestructureerd gebeuren. Het beste is de testers voor een bepaalde dag in te roosteren. De test is niet vrijblijvend. Er moet nauwkeurig bijgehouden worden hoe men getest heeft, onder welke omstandigheden, hoe lang men er over gedaan heeft, tegen welke problemen men is aangelopen enz.

De testperiode mag ook niet te lang duren en er moeten afspraken worden gemaakt over de tijd die iedere tester tenminste aan de nieuwe software besteedt.

Kosten

Een Proof of Concept vergt niet alleen veel tijd van de instelling die het softwarepakket overweegt aan te schaffen, maar ook van de leverancier. De software moet worden geïnstalleerd en ingericht, en er moet eventueel een proefconversie worden gedaan. Er moeten opleidingen georganiseerd worden en de helpdesk moet beschikbaar zijn. In veel gevallen zal de leverancier ook een of meer consultants de PoC laten begeleiden.

Kortom, het is veel werk en een PoC moet dan ook goed voorbereid worden. Het opstellen van een projectplan waarin de rollen van beide partijen zijn beschreven is aan te bevelen.

Onontbeerlijk is een projectcontract of overeenkomst waarin beide partijen overeenkomen een Proof of Concept te doen en wat de consequenties zijn bij de go/no go beslissing aan het einde van het traject. Zo voorkomt men onduidelijkheid en valse verwachtingen.

Het spreekt vanzelf dat een degelijke Proof of Concept niet kosteloos kan worden uitgevoerd. De kosten kunnen, afhankelijk van de afspraken die u maakt, de proefconversie(s), de opleidingen enzovoorts oplopen van 3.000 tot 15.000 euro. Dat lijkt veel geld, maar de kosten worden dikwijls verrekend bij de aanschaf. Mocht er niet tot aanschaf worden over gegaan dan heeft men in ieder geval ervaring opgedaan en een miskoop vermeden. En daarmee het risico ontlopen om tienduizenden tot honderdduizenden euro’s uit te geven voor een product dat eigenlijk niet bij u past.

Acceptatietest

Wanneer de software is aangeschaft, worden in samenwerking met de leverancier de functionele en technische specificaties opgesteld. Op grond van die rapporten wordt vervolgens de software ingericht en wordt eventueel maatwerk gemaakt. Alvorens tot de operationele fase over te gaan, moet het product getest worden. Ook hier vinden een technische en een functionele test plaats. De laatstgenoemde wordt uitgevoerd door een groepje goed geïnstrueerde gebruikers. De acceptatietest dient om te controleren of alle afgesproken zaken door de leverancier zijn uitgevoerd.

Net als bij de Proof of Concept worden er een testplan en een testscript opgesteld en ook ditmaal wordt er getest aan de hand van acceptatiecriteria die nu zijn gebaseerd op de vastgelegde afspraken. De acceptatiecriteria worden ook wel opleveringscriteria genoemd. De software is nooit direct in één keer goed. Uit de test komt een gebreken – of foutenlijst voort, vervolgens worden de gebreken verholpen, opnieuw getest tot uiteindelijk het programma zo goed als foutloos is. Daarna vindt de officiële oplevering plaats en kan de software ‘uitgerold’ worden in de organisatie.

Tijdens de acceptatietest kunnen uiteraard weer nieuwe wensen boven komen drijven. Afhankelijk van de afspraken in uw contract met de leverancier kunnen die direct worden gerealiseerd of zal er eerst een aanvullende offerte worden opgesteld.
Het tijdstip van de oplevering kan daardoor keer op keer worden opgeschoven. De ervaring leert dat de aanvankelijk geplande opleveringsdatum nooit wordt gehaald. Dat is niet erg, want u kunt er beter iets langer over doen dan met een onaf product te blijven zitten.

10 juni 2009