Applinet B.V.
Home
 
Anababa
Nieuwe website voor ouders
Lees hier verder
 
Mindfulness Ga naar de cursus
Mindfulness Training (nieuwe cursus)
Lees hier verder
 
Luisteren Ga naar Hoedoe
Nieuwe online cursus: Actief luisteren
Lees hier verder

Hoe voert u een acceptatietest van maatwerk-software uit?

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:

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:

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:

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:

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:

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:

  1. Ernstige fouten die de voortgang van de acceptatietest hebben belemmerd.
  2. Fouten die aan acceptatie in de weg staan.
  3. Fouten en onvolkomenheden die in het kader van een garantieregeling hersteld of verbeterd moeten worden nadat de software is geaccepteerd.
  4. 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:

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:

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:

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.

De auteur van dit artikel is ICT-consultant, geen jurist. In concrete situaties zult u naast ICT-advies wellicht ook juridisch advies moeten inwinnen.