Een acceptatietest is de laatste test die uitgevoerd wordt voordat het informatiesysteem opgeleverd wordt aan de opdrachtgever en dient om vast te stellen of het aannemelijk is dat de opdrachtgever het informatiesysteem in de huidige vorm zal gaan accepteren. Meestal wordt de acceptatietest uitgevoerd door ontwikkelende organisatie maar het is ook mogelijk dat de opdrachtgever nog een eigen acceptatietest uitvoert. In alle gevallen is het gebruikelijk dat de acceptatietest niet uitgevoerd wordt door de persoon of personen die het product ook ontwikkeld hebben om zo te voorkomen dat zij bewust (of misschien onbewust) randgevallen ontwijken en daarmee dus de test minder zinvol maken.
Het uitvoeren van een acceptatietest gaat er vanuit dat je tijdens de analyse een acceptatietestplan gemaakt hebt.
Rapport
Het rapport van de acceptatietest is een ander document dan het plan. In het rapport wordt de tabel uit het plan overgenomen en na het uitvoeren van de tests vult de tester de laatste twee kolommen in. Wanneer het werkelijke resultaat identiek is aan het verwachte resultaat dan is de test geslaagd. Wanneer het werkelijke resultaat anders is, beslist de tester of de test geslaagd is. Soms kan het zo zijn dat het werkelijke resultaat anders is, maar de werking van het product toch conform de wens van de opdrachtgever is en de tester besluit dat de test toch geslaagd is. De ingevulde tabellen worden vervolgens opgenomen in het acceptatietestrapport. Dit rapport is altijd een professioneel document, dat wil zeggen dat het een inleiding heeft die omschrijft waar het document toe dient en aan het einde een conclusie en eventueel aanbevelingen bevat. Tevens is het belangrijk dat het rapport aangeeft wie de tester is, zodat de opdrachtgever altijd navraag kan doen bij deze persoon, en zodat het duidelijk is dat de tester niet de softwareontwikkelaar is.
Geaccepteerd of niet?
In de conclusie van het acceptatietestrapport wordt eenduidig aangegeven of het informatiesysteem in de huidige vorm geaccepteerd is (en dus opgeleverd kan worden) of niet. Dit mag niet op een dubbelzinnige manier bepaald worden, het is of geaccepteerd, of niet. In beide gevallen kan er een toelichting gegeven worden waarom deze keuze gemaakt is. Het is bijvoorbeeld prima denkbaar dat een informatiesysteem tests bevat die niet geslaagd zijn, maar dat het systeem als geheel toch geaccepteerd is. De reden hiervoor kan zijn dat de opdrachtgever op dit moment het informatiesysteem nodig heeft en al vooruit kan met de werkende onderdelen, en voor de nog niet werkende onderdelen nu een work-around accepteert of deze voor nu negeert. In iteratieve softwareontwikkelmethoden is het heel gebruikelijk dat in een eerdere oplevering nog niet alle wensen van de klant verwerkt zijn en dus vele tests niet slagen. Als dit van tevoren goed afgesproken is, dan levert dit geen probleem op voor de opdrachtgever en zal het informatiesysteem in de huidige (imperfecte) vorm toch accepteren.
Met 1 plan, meerdere rapporten
Het plan omschrijft veelal het totale systeem en alle wensen, maar zoals hierboven omschreven kan het voorkomen dat het informatiesysteem meerdere keren opgeleverd wordt. Het idee is dan dat je hetzelfde acceptatietestplan meerdere keren kunt gebruiken om meerdere acceptatietests uit te voeren en dus meerdere acceptatietestrapporten te maken. Het grote voordeel hiervan is dat deze rapporten naast elkaar gelegd kunnen worden om te zien hoe het informatiesysteem over de tijd steeds beter voldoet aan de wensen van de opdrachtgever.
Conclusie
Een acceptatietest is een vorm van testen die het gebruik door een mens simuleert. Meestal wordt de acceptatietest uitgevoerd door een andere persoon dan de ontwikkelaar. De acceptatietest bestaat uit een plan dat al in de analysefase gemaakt kan worden omdat dan de gebruikerseisen bekend zijn. Tevens bevat het een rapport dat uiteraard pas net voor de oplevering gemaakt kan worden. Dit zijn twee verschillende documenten omdat in theorie hetzelfde plan meerdere keren uitgevoerd kan worden en dus meerdere rapportages heeft.