Acceptatietest

Een acceptatietest is een test om iets wel of niet te accepteren. In de ICT maakt deze vaak deel uit van het zogenaamde OTAP-proces.

Doelen

• Is het systeem acceptabel?
• Is het beter dan het huidige systeem/product?
• Kan de gebruiker er zo mee aan de "slag"?
• Doel is om vooraf te weten of de gebruiker ermee wil gaan werken en om te weten te komen welke problemen de gebruiker verwacht. Bijkomend voordeel is dat een gedeelte van de gebruikers al geschoold wordt in het gebruik en dat een eventuele trainingsbehoefte ingeschat kan worden.
• Doel van de acceptatietest is om tijdig te weten te komen of het systeem voor de gebruiker inclusief management en beheer, acceptabel is.

In voorafgaande testen zoals de unittest, programmatest, functietest, integratietest, systeemtest, regressietest, schaduwtest, is (na eventuele aanpassing) vastgesteld dat het product of de dienst in een voldoende mate voldoet aan de requirements. Centrale vraag bij deze eerste testen was "doet het systeem het zoals gevraagd"?

Bij de acceptatietest wordt nagegaan of er daarnaast problemen zijn te verwachten in het gebruik die eerder nog niet gevonden zijn.

Bij het formuleren van de requirements kunnen er bijvoorbeeld ook fouten gemaakt zijn. Ze kunnen bijvoorbeeld onvolledig zijn, of onduidelijk geformuleerd. Een systeem kan volledig aan de requirements voldoen, maar toch niet acceptabel zijn.

Vormen

Er zijn meerdere vormen van acceptatietests:

• gebruikersacceptatietest
  test uit te voeren door de gebruiker zelf, of door een afvaardiging van de gebruikers. Doel van de test is te bepalen of het product de gebruiker voldoende ondersteunt. De engelse benaming wordt in Nederland ook veel gebruikt en dat is de user acceptance test afgekort tot UAT.
• productieacceptatietest
  een test, gericht op het bepalen of het product te zijner tijd in zijn productieomgeving voldoet, of het niet andere onderdelen daar verstoort (bij een test in de ICT: hindert het andere systemen, bijvoorbeeld door een (te) groot deel van de beschikbare bronnen te gebruiken)
• functionele acceptatietest
  test uit te voeren door de functionele acceptant, in de IT-wereld meestal de functioneel beheerder van een systeem. Doel van de test is te bepalen of het systeem voldoende ondersteund kan worden. Hierbij wordt bijvoorbeeld ook gekeken naar de documentatie. Is het systeem te wijzigen? Deze test wordt ook wel de beheeracceptatietest genoemd.

Bij een product of dienst die met ICT wordt ondersteund, zal dus niet meer worden gelet op de effectieve werking van het product maar op de totale ervaring. Een appel kan nog zo mooi en gezond zijn; een blauwe van 1 kilo koopt niemand.

Testsoorten

De acceptatietest kan onder meer de volgende testsoorten omvatten:

• een straattest ook wel Real life test of Shadowtest genoemd
  Alle normale handelingen worden hierbij doorlopen, van eerste tot en met de laatste stap. De nadruk ligt op de koppelvlakken: leidt de eerste handeling tot een gewenst eindresultaat?
  Voorbeeld: een via Internet aangevraagde polis. De gebruiker verwacht redelijkerwijs een polis op de mat, per e-mail of op een site. Hij heeft geen belang bij de werking van de vele koppelvlakken die dit proces doorloopt, van toetsenbord tot postbode. Elke verstoring hierin, zoals verloren informatie en beschadiging, wordt gemeld aan de proceseigenaar.

• een usability test
  De nadruk ligt op look-and-feel van het product: past dit binnen zijn ervaring en mogelijkheden?
  Is de site makkelijk te vinden? Is deze logisch opgebouwd? Wat is de fouttolerantie? Is er taalondersteuning in de eigen taal? Is gedacht aan kleurenblinden en doven? Is de polis prettig leesbaar? Heeft deze een A4-formaat? Hoelang is het product houdbaar (wetswijzigingen)? Is er telefonische ondersteuning? Is dat een helpdesk of een servicedesk? Wat doe ik met de oude polis? Zijn er opleidingen en seniorenondersteuning? Is een duplicaat te krijgen? Wordt er reclame gemaakt? Zijn er leverancierscontracten? Hoe is de beveiliging?
  Wanneer de resultaten van een usability (gebruiksvriendelijkheids)test goed gebruikt worden voor aanpassingen aan de ervaringskant van het systeem zal dat veel bijdragen aan het succes van een product of dienst.

• een performance test
  De nadruk ligt op tijdgedrag van het product: is de verwerkingstijd aanvaardbaar? Hoe is dat voor 1 aangevraagde polis? En voor 10.000 tegelijkertijd aangevraagde? Welke invloed heeft dat op bestaande processen? Er wordt gekeken naar het gebruik van resources van het systeem van onder andere de CPU en het RAM geheugen. Ook andere resources, zoals papier, opslagruimte, energiegebruik, manuren, afhankelijk van het te testen product, systeem of proces.
• een volumetest
  De nadruk ligt op middelenbeslag van het product: hoeveel ruimte neemt het product in? Wat is de verwachte toe- of afname? Is het archief voorbereid? Wat wordt gedaan aan opschoning van gedateerde informatie? Past het product op 1 pallet?

• een stresstest
  De nadruk ligt op extreem gebruik van het product: hoe gedraagt het zich bij piekbelasting? Wat is het breekpunt van het systeem, m.a.w. hoeveel gebruikers zijn er nodig, om het systeem onbehandelbaar langzaam te maken.
  Door een enkele gebruiker en door alle gebruikers tegelijkertijd? Hoe is de correcte afhandeling van al deze aanvragen gewaarborgd? Welke invloed heeft toenemende druk uit de omgeving op het product? Werkt het systeem ook op topdagen goed?

• een monkeytest
  De nadruk ligt op misbruik van het product, het creëren van onvoorziene en niet vooraf gespecificeerde omstandigheden. Een monkeytest wordt soms toegepast om te kunnen bepalen of een systeem voldoende stabiel is om met het eigenlijke testen te beginnen. De vraag is of het systeem foolproof is. Veel gebruikers voeren deze test graag uit, ook omdat er vaak weerstand is tegen iets nieuws en men graag wil aantonen dat iets niet werkt. Maar dit is ook belangrijk bij veel onervaren gebruikers, vakantiekrachten en als er weinig tijd is voor opleidingen.