Wanneer de klant en leverancier over het contract onderhandelen, zullen ze de nodige aandacht besteden aan de specificatie en de planning voor de levering. Vaak beperken beide partijen zich tot het behandelen van het belangrijke onderdeel acceptatie in de vorm van een 'instemming tot instemming'. Vanuit juridisch oogpunt is dit echter onwenselijk, omdat een 'instemming tot instemming' niet bindend is. Als de partijen deze aanpak wensen te hanteren, moet de advocaat (van de klant) gebruikmaken van de contractuele formulering om ten minste de parameters en timing van het testproces vast te leggen. In de meeste gevallen zal het testproces in ten minste twee delen worden opgesplitst. Eerst zal de ontwikkelaar zelfstandig tests uitvoeren zonder de betrokkenheid van gebruikers. Het gaat dan vaak om Factory Acceptance Tests (fabrieksacceptatietests oftewel FAT). In feite is dit een tussenliggende fase van het ontwikkelingsproces. De enige werkbare manier om fouten in de broncode van de software bloot te leggen, is om de ruwe code te controleren door deze uit te voeren - en de fouten stukje bij beetje ongedaan te maken. Het voltooien van de FAT komt vaak louter neer op een garantie van de leverancier dat de software klaar is om naar de locatie te worden overgebracht waar deze verder door gebruikers wordt getest (User Acceptance Tests), AUT of Site Acceptance Tests (SAT).

Impliciete acceptatie

De leverancier zal proberen te bewerkstelligen dat het contract voorziet in de mogelijkheid van 'impliciete acceptatie' van de software of het systeem wanneer de klant een af te leveren onderdeel niet tijdig afkeurt. Hoewel het belangrijk is dat de klant verplicht wordt om binnen een redelijke (en bij voorkeur een overeengekomen) termijn met de benodigde feedback te komen, mag een tekortkoming van de klant niet leiden tot impliciete acceptatie (hetgeen meestal inhoudt dat de leverancier zijn werk mag stilleggen en een gepeperde rekening mag indienen). In plaats daarvan moet de klant andere sancties worden opgelegd voor het laat indienen van feedback (het verlies van zijn recht om te eisen dat de projectplanning wordt gehandhaafd, en mogelijke aansprakelijkheid voor schade bij de leverancier als gevolg van vertraagde informatieverstrekking).

Voorbereiding voor SAT

De leverancier zal normaliter niet in staat zijn om de SAT te voltooien zonder belangrijke feedback van de klant te ontvangen. Daarom moeten in het contract het volgende worden geregeld: - wie de testscripts gaat leveren (de precieze functies/input van het toetsenbord die tijdens het testen worden gebruikt) - een procedure voor de goedkeuring van de testscripts door beide partijen - de partij die de testgegevens gaat leveren (dit is in de regel de taak van de klant), en garanties met betrekking tot de evaluatie van deze gegevens en hoe 'schoon' de desbetreffende data is. - wie verantwoordelijk is voor het uitvoeren van de tests, en - de eventuele plicht of het recht van de wederpartij om de tests bij te wonen

Succescriteria

Of de software al dan niet geschikt is voor de bedrijfsactiviteiten van de klant, zal grotendeels afhankelijk zijn van het aantal en de ernst van de fouten in de software. Om deze reden moet in het contract worden vastgelegd in welke mate de geteste software fouten mag vertonen en tot welk foutniveau de software de test nog steeds met succes doorstaat. Dit omvat het categoriseren van verschillende foutniveaus (op de ernst van de fout) en het beschrijven van elk niveau van ernst, naast het vastleggen van het aantal toegestane fouten voor elke categorie.

Negatieve testresultaten

Het is belangrijk om vast te stellen of de software in bepaalde omstandigheden een aantal reeksen tests al dan niet heeft doorstaan. Zelfs als hier geen discussie over mogelijk is, kan er onenigheid ontstaan over het te volgen traject. De leverancier zal de software opnieuw willen laten testen. Het contract zou moeten voorzien in de criteria voor een nieuwe testronde, met inbegrip van (1) de vraag of testprogramma's die tot falen gedoemd zijn vroegtijdig mogen worden afgebroken, of in hun volledigheid moeten worden doorlopen? (2) de vraag wanneer de leverancier zijn software opnieuw moet of kan laten testen, en (3) de vraag hoe vaak de software van de leverancier mag falen in de tests en opnieuw mag worden getest, en de vraag of dit is gebaseerd op de hoeveelheid tijd die besteed is of het aantal pogingen. Een goed opgesteld contract zal de klant de nodige mogelijkheden bieden als de acceptatietests niet worden doorstaan, en deze mogelijkheden zullen verschillen naarmate het aantal pogingen dat de leverancier heeft ondernomen om acceptatie van de software te bewerkstellingen. Het is belangrijk (voor de klant) dat een duidelijk forse vergoeding voor het opzeggen van de overeenkomst een haalbare kaart is. Het opzeggen van een overeenkomst is voor de klant van weinig nut als hij geen recht heeft op schadevergoeding door de leverancier (of op zijn minst restitutie van reeds betaalde bedragen).

Prestatietesten

Eveneens is het belangrijk om te garanderen dat de software snel genoeg presteert in combinatie met de gespecificeerde hardware, zodat aan de eisen van de klant wordt voldaan. Een softwareontwikkelaar die naast de software geen hardware levert, zal niet graag garanderen dat de software goed presteert in combinatie met hardware van derden (zelfs als hij die hardware heeft gespecificeerd), niet in de laatste plaats omdat het uiterst moeilijk is om te specificeren welke (mate van) hardware precies nodig is om de vooralsnog ongebouwde software effectief uit te voeren. Desalniettemin zal software die op inefficiënte wijze is ontwikkeld veel langzamer blijken in combinatie met dezelfde hardware dan een product dat op vakkundiger wijze is samengesteld. De tijd die nodig is om een inefficiënt systeem fijn te stellen, als dat überhaupt al mogelijk is, zal vaak een grote hap uit de marge van de leverancier inhouden. Het kan er ook toe leiden dat de leverancier essentiële deadlines mist en als gevolg daarvan schade ondervindt. Hoewel het niet aantrekkelijk zal lijken om in het stadium van de contractonderhandelingen veel tijd te besteden aan het opstellen van een acceptatietestplan, zal de tijd die men daarvoor uittrekt naar verwachting de nodige onduidelijkheid en onenigheid voorkomen wanneer een test niet wordt doorstaan. Bron: Techworld