Hoe voert u een acceptatietest van maatwerk-software uit?

Wat is een acceptatietest?
Waarom is een acceptatietest voor u als opdrachtgever belangrijk?
Wat moet u testen?
Wanneer kunt u met de acceptatietest beginnen?
Hoe voert u een acceptatietest uit?
Wat doet u met de resultaten van de test?
Wanneer eindigt de acceptatietest?
Wat gebeurt er na afloop van de acceptatietest?
Wanneer kunt u de geleverde software in productie nemen?
Wat moet u doen als de software van zeer slechte kwaliteit blijkt te zijn?
Acceptatietest uitbesteden
Kosten

Wat is een acceptatietest?

Wanneer u de ontwikkeling van maatwerk-software uitbesteedt, dan vindt doorgaans direct na oplevering een acceptatietest plaats. Hiermee worden de activiteiten van de opdrachtgever bedoeld die erop zijn gericht om in een overeengekomen testperiode het geleverde product systematisch te testen en beoordelen.

Het doel van de acceptatietest is vast te stellen dat de software voldoet aan uw eisen en wensen en dat de software geschikt is voor bedrijfsmatige ingebruikname.

Waarom is een acceptatietest voor u als opdrachtgever belangrijk?

In de algemene voorwaarden van software-leveranciers staat in de paragraaf over garantie vaak een bepaling met de volgende strekking:

De leverancier kan de kosten van herstel in rekening brengen indien de fouten bij het uitvoeren van de overeengekomen acceptatietest hadden kunnen worden vastgesteld.

Een overeenkomst met deze bepaling legt een deel van de verantwoordelijkheid voor het testen van de software bij de opdrachtgever. Indien de acceptatietest achterwege wordt gelaten of onvoldoende grondig wordt uitgevoerd, dan wordt de opdrachtgever gestraft met extra kosten voor het herstel van fouten die later worden ontdekt. Door een grondige acceptatietest uit te voeren bespaart u zich deze onzekere kosten.

Het komt ook voor dat de betreffende bepaling als volgt is geformuleerd:

Na acceptatie is leverancier op grond van deze overeenkomst niet gehouden tot het herstel van gebreken in de software.

Wanneer bovendien een garantieregeling of onderhoudscontract ontbreekt dan is de acceptatietest uw enige instrument om de goede kwaliteit van de software te garanderen.

De bepalingen over het herstel van fouten in de testperiode zijn voor de leverancier veelal dwingender dan de overeenkomstige bepalingen voor de garantieperiode of de periode daarna. Het komt ook voor dat de betaling van een deel van de ontwikkelkosten afhankelijk wordt gesteld van een succesvolle afronding van de acceptatietest. De testperiode biedt u daarom een goede gelegenheid om de kwaliteit en betrouwbaarheid van de software te verbeteren.

Wat moet u testen?

In de algemene voorwaarden van software-leveranciers is vaak een bepaling opgenomen met de volgende strekking:

Onder onvolkomenheden worden verstaan fouten en gebreken of het op andere wijze niet functioneren overeenkomstig de overeengekomen specificaties.

Enerzijds is een dergelijke definitie zeer ruim, wegens het ontbreken van een omschrijving of afbakening van de begrippen "fout" en "gebrek". Anderzijds zijn uw enige concrete aanknopingspunten de overeengekomen specificaties. In de praktijk betreft dit veelal de door de leverancier opgestelde specificaties. Die leverancier heeft er - althans bij een overeenkomst met een vaste prijs - alle belang bij om in de specificaties de functionaliteit zoveel mogelijk in te perken, maar niet om de functionaliteit zodanig concreet en specifiek te omschrijven dat u eenvoudig kunt aantonen dat de software gebreken vertoont.

U kunt bij uw acceptatietest de volgende zaken testen:

De functionaliteit, dat wil zeggen alle aspecten van gedrag en resultaten die volgens de overeengekomen specificaties aan bepaalde voorwaarden moeten voldoen.
Robuustheid. Dat wil zeggen, de mate waarin de software zinvol reageert op foute invoer, technische foutsituaties en gebruikersfouten.
De conversieprocedure waarmee u uw bestaande systemen uiteindelijk zult overzetten op de nieuwe software.
Koppelingen met uw andere informatiesystemen.
De performance. Hierbij kunt u denken aan het criterium van "productieve ingebruikname" op een technische infrastructuur die voldoet aan de minimum voorwaarden volgens de overeengekomen systeemeisen.
De gebruiksvriendelijkheid.
De mate waarin de software voldoet aan kwaliteitsgaranties in de overeenkomst met de leverancier.
In de informatica algemeen aanvaarde uitgangspunten van kwaliteit en deugdelijkheid. Dit zijn geen eenduidige begrippen. Zo is bijvoorbeeld discussie mogelijk over de vraag wanneer millenniumbestendigheid een algemeen aanvaard uitgangspunt van deugdelijkheid is geworden.
De documentatie voor beheerders en gebruikers.
De procedures voor handmatige werkzaamheden.

Bij de acceptatietest vergelijkt u het eindresultaat van het ontwikkelproces met de huidige behoeften van de eindgebruikers [Kit]. Het is dus zeer wel mogelijk dat u tot nieuwe inzichten komt met betrekking tot de oorspronkelijk geformuleerde functionele eisen. In dat geval moet u duidelijk onderscheid maken tussen onvolkomenheden en nieuwe of gewijzigde functionele eisen. U kunt van de leverancier verlangen dat de onvolkomenheden worden hersteld, maar wat betreft de nieuwe of gewijzigde functionele eisen zult u de leverancier om een voorstel moeten vragen. Doorgaans zal de leverancier bereid zijn deze als meerwerk te realiseren.

Wanneer kunt u met de acceptatietest beginnen?

U kunt met de acceptatietest beginnen nadat:

De ontwikkeling van de software volledig is afgerond.
De leverancier een systeemtest heeft uitgevoerd en u over de resultaten heeft geïnformeerd.
De software volledig is opgeleverd en geïnstalleerd.
Alle benodigde systeemkoppelingen tot stand zijn gebracht en conversies zijn uitgevoerd.
Alle documentatie beschikbaar is, zoals de handleiding voor eindgebruikers, de handleiding voor de applicatiebeheerder en de handleiding voor de systeembeheerder.
De software van voldoende kwaliteit is voor normaal operationeel gebruik onder productie-omstandigheden. Volgens SDM moet een acceptatietest uitgevoerd kunnen worden zonder dat tussentijds fouten hersteld behoeven te worden [SDM]. Er mogen geen componenten meer zijn die niet functioneren.

Het komt voor dat de leverancier de software oplevert voor de acceptatietest, terwijl de leverancier nog bezig is de ontwikkeling af te ronden. U krijgt de software dan geleverd met een lijst bekende fouten, of u ontdekt zelf snel fouten die normaal operationeel gebruik van de software belemmeren. In dat geval is er in feite sprake van een bèta-test, niet van een acceptatietest. Het kan dan van belang zijn om de leverancier direct te laten weten dat u de betreffende levering niet aanvaardt als basis voor de acceptatietest.

Hoe voert u een acceptatietest uit?

Stel een globaal testplan op. Hierbij dient u onder andere rekening te houden met oplevering van de software in onderdelen of fasen. In de algemene voorwaarden van software-leveranciers staat vaak een bepaling met de volgende strekking:

Indien de software in onderdelen of fasen wordt opgeleverd en getest, laat de niet-acceptatie van een bepaalde fase of onderdeel een eventuele acceptatie van een eerdere fase of onderdeel onverlet.

U kunt in dat geval het testen van een onderdeel of fase niet uitstellen tot het testen van het geheel of van het eindresultaat. Daarmee zou u het risico lopen dat fasen of onderdelen stilzwijgend worden geaccepteerd, zodat het herstel van fouten die u later aantreft voor uw rekening is. Dit geeft ook aan dat het voor u van belang is om te zorgen dat de fasen en onderdelen van de leverancier voor u testbaar zijn. Een auto kunt u testen, maar kunt u een stuur testen?

Aangezien u de acceptatietest doorgaans in een betrekkelijk korte periode moet uitvoeren is het van belang om de test grondig voor te bereiden:

Richt tijdig de testomgeving in (hardware, software, documentatie, licenties, werkruimte).
Wijs ruim van tevoren de medewerkers aan die de acceptatietest gaan uitvoeren. Zorg dat deze zich vóór aanvang van de test voldoende basisvaardigheden eigen maken met betrekking tot het platform (operating system en user interface). Zorg dat uw medewerkers tijdig de beschikking krijgen over de gebruikershandleiding en de functionele specificaties van de te testen software.
Schrijf vooraf concrete test-scenario's (gebruikershandelingen) en test sets (data). Hiermee kunt u al beginnen zodra de functionele specificaties beschikbaar zijn.
Richt de tijdelijke administratieve organisatie in voor het verzamelen en administreren van testresultaten.

Bij het uitvoeren van de acceptatietest zult u waarschijnlijk fouten en onvolkomenheden aantreffen. Het is daarbij van belang dat u nagaat of de fouten de voortgang van de acceptatietest belemmeren. In de algemene voorwaarden van software-leveranciers is vaak een bepaling opgenomen die u verplicht om een dergelijke situatie bij de leverancier te melden. De testperiode kan worden onderbroken todat de software zodanig is aangepast dat de acceptatietest ongehinderd voortgang kan vinden of opnieuw kan worden gestart. Wanneer u nalaat om voortgang-belemmerende fouten bij de leverancier aan te melden dan loopt u het risico dat bij het einde van de testperiode niet alle functionaliteit voldoende is getest en dat het herstel van fouten die u daarna ontdekt voor uw rekening is.

Fouten en onvolkomenheden dient u zorgvuldig en gedetailleerd te administreren. Relevante gegevens zijn:

Welk test-scenario is uitgevoerd?
Wat was de begintoestand van de database en/of de applicatie?
Welke testgegevens zijn ingevoerd?
Wat is het waargenomen gedrag van de software?
Wat is het verwachte gedrag?
Waarin wijkt het waargenomen gedrag precies af van het verwachte gedrag?
Hoe kan de fout gereproduceerd worden?
In welke versie van de software is de fout aangetroffen?
Wat heeft u gedaan om mogelijke oorzaken van de fout te achterhalen?

Met name het aspect van de reproduceerbaarheid is van groot belang. In de algemene voorwaarden van software-leveranciers is vaak een bepaling opgenomen met de volgende strekking:

Een onvolkomenheid wordt onderzocht op voorwaarde dat deze reproduceerbaar is.

Vanuit het perspectief van de leverancier is deze voorwaarde goed te begrijpen. Het onderzoeken van een niet-reproduceerbare fout kan zeer tijdrovend en kostbaar zijn. Het is zeker niet onredelijk dat de leverancier reproduceerbare testresultaten verlangt. Vanuit het perspectief van de opdrachtgever is het echter moeilijk te aanvaarden dat niet-reproduceerbare fouten niet onderzocht en hersteld worden. Dit type fouten is dan ook een bron van conflicten tussen leverancier en opdrachtgever.

U doet er goed aan om uw acceptatietest zodanig uit te voeren dat tenminste de testresultaten reproduceerbaar zijn. In de praktijk zullen dan de meeste fouten eveneens reproduceerbaar blijken te zijn. Indien uw reproduceerbare tests niet-reproduceerbare fouten aan het licht brengen dan kunt u overwegen om acceptatie te weigeren op grond van het argument dat het onbetrouwbare gedrag van de software aan operationele ingebruikname redelijkerwijs in de weg staat.

Naast concrete fouten kunnen ook kleine schoonheidsfouten en andere ongemakken geregistreerd worden. Wellicht is de leverancier bereid om deze te verbeteren, al kan hij uiteraard de kosten voor meerwerk in rekening brengen.

Wat doet u met de resultaten van de test?

Uiterlijk op de laatste dag van de overeengekomen testperiode stuurt u een schriftelijk en gedetailleerd testrapport naar de leverancier. Daarin beschrijft u:

Welke fouten en onvolkomenheden u in de software heeft aangetroffen.
Welke fouten en onvolkomenheden naar uw inzicht aan acceptatie in de weg staan.
Welke functionaliteit u nog niet heeft kunnen testen als gevolg van de aangetroffen fouten.

Tenslotte dient u de aangetroffen fouten en onvolkomenheden ten opzichte van de overeengekomen specificaties te wikken en wegen. Bepalend voor acceptatie is of de aangetroffen fouten aan productieve en operationele ingebruikname redelijkerwijs in de weg staan. Kleine fouten en onvolkomenheden kunnen ook na acceptatie in het kader van een garantieregeling worden hersteld.

Samenvattend onderscheidt u in uw testrapport de volgende categorieën van onvolkomenheden:

Ernstige fouten die de voortgang van de acceptatietest hebben belemmerd.
Fouten die aan acceptatie in de weg staan.
Fouten en onvolkomenheden die in het kader van een garantieregeling hersteld of verbeterd moeten worden nadat de software is geaccepteerd.
Schoonheidsfouten en ongemakken die voor verbetering in aanmerking komen.

In uw testrapport of in de begeleidende brief vermeldt u uiteraard uw conclusie: accepteert u de geleverde software of verlangt u herstel van fouten en onvolkomenheden?

Wanneer eindigt de acceptatietest?

In de algemene voorwaarden van software-leveranciers is vaak een bepaling opgenomen die de testperiode beperkt tot bijvoorbeeld 2 weken na aflevering. Dat is erg kort, vooral wanneer u de test nog moet voorbereiden. Wanneer u over een contract onderhandelt doet u er goed aan om een langere testperiode te bedingen, bijvoorbeeld 25% van de daadwerkelijke doorlooptijd van analyse, ontwerp en ontwikkeling met een minimum van 1 maand.

In de algemene voorwaarden van software leveranciers is vaak een bepaling opgenomen met de volgende strekking:

Indien de leverancier geen testrapport ontvangt zal de software gelden als geaccepteerd op de eerste dag na de testperiode.

Wanneer u de overeengekomen testperiode overschrijdt zonder een testrapport met de ontdekte tekortkomingen naar de leverancier te sturen, dan loopt u het risico dat herstel van alle tekortkomingen voor uw rekening is.

U doet er goed aan om de acceptatietest projectmatig aan te pakken en de voortgang van het project scherp te bewaken.

Wat gebeurt er na afloop van de acceptatietest?

Als u de software heeft geaccepteerd dan kunt u deze in productie nemen.

Als u de software niet heeft geaccepteerd dan zal de leverancier zich moeten inspannen om de gerapporteerde fouten en onvolkomenheden naar beste vermogen te herstellen. In de algemene voorwaarden van software-leveranciers is vaak een bepaling opgenomen met de volgende strekking:

De software zal gelden als geaccepteerd op het moment dat de in het testrapport genoemde fouten zijn hersteld.

Er volgt in dat geval geen tweede algemene acceptatietest van de verbeterde software. U krijgt geen herkansing, uw eerste en enige acceptatietest dient zoveel mogelijk fouten en onvolkomenheden aan het licht te brengen.

Het komt ook voor dat de overeenkomst voorziet in een tweede acceptatietest. Daarbij kan de bepaling opgenomen zijn dat de opdrachtgever het recht heeft de overeenkomst te ontbinden indien de software opnieuw niet geaccepteerd wordt.

U moet er rekening mee houden dat niet alle aangetoonde fouten de verantwoordelijkheid van de leverancier zijn. Het is denkbaar dat bepaalde geconstateerde fouten veroorzaakt worden door fouten in hardware of software van derden, bijvoorbeeld meegeleverde componenten, of runtime-voorzieningen van het Operating System, de middleware of de database. De leverancier heeft de verantwoordelijkheid voor het onderzoek en herstel van dergelijke fouten wellicht uitgesloten in zijn algemene voorwaarden. In dat geval moet u op basis van uw licentie voor de betreffende component of voorziening de desbetreffende derde aanspreken. U kunt daarbij te maken krijgen met verschillende complicaties:

U heeft een bewijslast met betrekking tot een fout die misschien diep zit verstopt in ontoegankelijke software.
Voor wiens rekening is het onderzoek naar de fout?
De door u aangesproken derde ontkent wellicht de fout - al dan niet met een voor u onhanteerbare technische explicatie - en verwijst u terug naar de leverancier.
De door u aangesproken derde verlangt dat u de laatste versie van zijn software gebruikt, maar die is niet compatibel met de software van de leverancier.
De door u aangesproken derde is slechts gehouden aan zijn overeenkomsten met u, niet aan de bepalingen in uw overeenkomst met de leverancier. Zo is de derde partij bijvoorbeeld niet gebonden aan de geplande datum van ingebruikname.
De gebruiksrechtovereenkomst met de door u aangesproken derde voorziet wellicht niet in het onderzoek of herstel van fouten.

Wanneer kunt u de geleverde software in productie nemen?

U kunt de software in gebruik nemen nadat u de geleverde software heeft geaccepteerd.

In de algemene voorwaarden van software-leveranciers zijn vaak bepalingen opgenomen met de volgende strekking:

Gedurende de testperiode is het niet toegestaan om de software voor productieve of operationele doeleinden te gebruiken.

De software zal reeds gelden als volledig geaccepteerd indien daarvan vóór het moment van acceptatie enig gebruik voor productieve of operationele doeleinden wordt gemaakt.

Wanneer u de software vóór acceptatie in productie neemt, loopt u het risico dat het herstel van alle resterende fouten voor uw rekening is.

Wat moet u doen als de software van zeer slechte kwaliteit blijkt te zijn?

De ICT is een onvolwassen bedrijfstak. Zelfs bij gerenommeerde leveranciers van maatwerk-software komt het regelmatig voor dat de geleverde software in ernstige mate tekortschiet. Enkele voorbeelden:

De geleverde software laat zich niet goed installeren, laat staan testen.
De geleverde software blijkt andere systeemeisen te kennen dan met de leverancier overeengekomen, waardoor uw testomgeving niet bruikbaar is.
De geleverde software vertoont allerlei gebreken en tekortkomingen, maar de functionele specificaties zijn onvoldoende specifiek om van ondubbelzinnige fouten te kunnen spreken.
De gebruikershandleiding ontbreekt, of is onduidelijk.
Er doen zich regelmatig niet-reproduceerbare fouten voor.
Problemen die in uw testomgeving reproduceerbaar zijn doen zich volgens de leverancier in zijn testomgeving niet voor.
De performance is zeer slecht, maar de leverancier beweert dat de performance normaal is en dat u krachtiger computers moet aanschaffen.
De leverancier schrijft fouten toe aan gebreken en tekortkomingen in software van derden.
De leverancier heeft een bepaalde eis of wens die in de ontwerpfase is besproken niet uitdrukkelijk vastgelegd in de functionele specificaties, en bij oplevering blijkt de software op dit punt niet te voldoen.
De leverancier beweert dat bepaalde beperkingen of tekortkomingen niet kunnen worden verbeterd in verband met de beperkingen van een bepaalde technologie.
De leverancier stuurt u gedurende de testperiode in hoog tempo verbeteringen ("patches"), waardoor het testproces moeilijk te beheersen is.

Soms blijkt al snel dat de kwaliteit van de software zo slecht is dat u zich moet afvragen of u wel met de acceptatietest kunt beginnen. In dat geval dient u toch enige testwerkzaamheden uit te voeren, zodat u de leverancier met redenen omkleed kunt aangeven dat de software van onvoldoende kwaliteit is.

Het is van belang dat u alle fouten, gebreken en onvolkomenheden die de voortgang van de acceptatietest belemmeren onmiddellijk aanmeldt bij de leverancier. Leg daarbij zoveel mogelijk van de genoemde problemen terug bij de leverancier. Omschrijf de fout in detail en geef aan op welke wijze en in welke mate de voortgang van de acceptatietest wordt belemmerd.

Controleer zonodig uw eigen installatie- en systeembeheer-procedures. Het is denkbaar dat een kleine omissie bij de installatie - zoals het niet controleren van systeemeisen of compatibiliteitseisen - een grote hoeveelheid fouten in het gedrag van de software tot gevolg heeft.

Leg alle beweringen van de leverancier voor aan een onafhankelijk deskundige. Laat zonodig een onafhankelijk rapport opstellen.

Wanneer de leverancier er niet in slaagt om op redelijke termijn de geconstateerde tekortkomingen te herstellen dan wordt het tijd voor juridisch advies. U kunt dan nagaan of u de leverancier in gebreke kunt stellen, de overeenkomst ontbinden of zelfs schadevergoeding eisen. Zelfs wanneer dergelijke scenario's niet in uw belang zijn, versterkt u met deze juridische instrumenten uw positie.

Acceptatietest uitbesteden

Door het uitvoeren van een deugdelijke acceptatietest kunt u onzekere kosten besparen en de kwaliteit en betrouwbaarheid van de software verbeteren. Het uitvoeren van een acceptatietest is echter verre van eenvoudig. U krijgt te maken met de volgende complicaties:

De functionele specificaties moeten tot in detail worden vertaald naar concrete en reproduceerbare test-scenario's.
De software moet worden getoetst op in de informatica algemeen aanvaarde uitgangspunten van kwaliteit en deugdelijkheid.
Er moeten reproduceerbare performance-metingen worden uitgevoerd.
Bij complexe en grootschalige acceptatietests kan het wenselijk zijn om het testproces geheel of gedeeltelijk te automatiseren.

Een acceptatietest is primair een zaak van de gebruikers en materiedeskundigen. Deskundigheid op het terrein van de Software Engineering is echter vereist. Uiteraard wilt u die deskundigheid niet betrekken bij de leverancier van de te testen software.

Applinet kan u bij het uitvoeren van de acceptatietest van dienst zijn met testleiding en advies. Bovendien kan Applinet uw testplan schrijven, in samenwerking met gebruikers en materiedeskundigen test-scenario's en test-sets ontwikkelen, testresultaten analyseren en het testrapport opstellen.

Kosten

Als vuistregel kunt u hanteren dat de kosten van een deugdelijke acceptatietest 20 tot 40 % van de ontwikkelkosten van de software bedragen. Het is van belang dat u een redelijke inspanning levert, aangezien de leverancier zich anders in de garantieperiode kan beroepen op zijn bepaling dat het herstel van fouten die tijdens de acceptatietest gevonden hadden kunnen worden voor uw rekening is.

Verder kunt u de onzekere kosten van herstel van fouten na de testperiode laten meewegen. Een extra investering in de acceptatietest kan lonend zijn, met name wanneer u voor het herstel van fouten afhankelijk bent van één leverancier.

Referenties

[Kit] Software testing in the real world - improving the process, Edward Kit, Addison-Wesley, 1995.

[SDM] System Development Methodology, W.S. Turner e.a., Cap Gemini Publishing, 1990.

Disclaimer

Dit artikel is gebaseerd op de eigen ervaring van de auteur en op een analyse van algemene voorwaarden en contractsbepalingen die in de praktijk vaak worden gehanteerd. In uw specifieke situatie kunnen andere afwegingen gelden en in uw overeenkomst voor de ontwikkeling van software kunnen andere bepalingen staan of kunnen andere voorwaarden van toepassing zijn, waardoor de inhoud van dit artikel in uw situatie wellicht niet toepasbaar is.

Auteur: René Pijlman, ICT-consultant. In concrete situaties zult u naast ICT-advies wellicht ook juridisch advies moeten inwinnen.