Duidelijkheid over de Functionele Acceptatie Test

Misschien ken je mijn mening al over de term ‘Functionele Acceptatie Test’; ik vind het héél verwarrend. Waarom? Een leverancier van software zou zelf al de functionele test uitgevoerd moeten hebben. En pas als die leverancier denkt dat het goed genoeg is, komt de acceptatietest door de eindgebruikers. Die acceptatietest richt zich op zaken als gebruiksvriendelijkheid en op het krijgen van een gevoel bij de software.

Door de term ‘Functionele Acceptatie Test’ krijg je opnieuw de discussie wie de functionaliteit gaat testen. En dat is dus NIET de verantwoordelijkheid van de eindgebruiker. Als je dat door omstandigheden toch bij de eindgebruikers neerlegt, moet je die eindgebruikers extra trainen. Een onderdeel van die training is de bewustmaking dat ze zó vroeg betrokken worden, dat ze nog ‘dikke foutmeldingen’ kunnen tegenkomen. Wees je ervan bewust dat lang niet alle eindgebruikers die mentale omslag kunnen maken. Kies je testgroep dus zorgvuldig. Maar veel liever nog; voorkom deze situatie.

Functionele Acceptatie Test = test de tester

Kegel van functionaliteitEr is één manier om een goede Functionele Acceptatie Test toe te passen. Dat is als de leverancier al getest heeft op functionaliteit, waarna de eindgebruikers de kwaliteit van die leverancierstest beoordeelt. Test de tester dus. En dat doe je door een gevarieerde groep gebruikers te vragen om in de software te ‘prikken’. Dat kan volledig onvoorbereid via de ‘doe maar wat’ methode. Een klein stukje beter is om de eindgebruikers te vragen om bewust naar fouten op zoek te gaan (wat de experts ‘Error Guessing noemen). Maar je kunt ook vooraf een workshop houden om een gevarieerd setje testgevallen te krijgen.

En dat laatste heb ik de afgelopen twee dagen gedaan. Zowel voor mij als voor de eindgebruikers was dat een erg leerzame ervaring. De lessen die ik zelf leerde, komen in het volgende blog. Dit blog sluit ik af met de omvang van deze test. Om dat duidelijk te maken, laat ik de software zien als een kegel (geen kerstboom). Bovenin de kegel zit het inloggen. Die ‘functionaliteit’ gebruikt iedereen. Dan gaat men de software gebruiken, eerst de simpele functionaliteit bovenin de kegel, zoals het inzien van een klant.

Daarna daalt men af in de kegel en sommigen komen helemaal onderin, waar de meest complexe en uitzonderlijke functionaliteit zit. Als voorbeeld; wanneer loopt een verzekering af met een looptijd van een jaar, als die op de schrikkeldag 29 februari is ingegaan? Ook handig om te testen; de foutafhandeling. Als ik een hypotheek wil afsluiten voor een 15-jarige, wordt dit dan afgevangen? Dit zijn de rode streepjes in de kegel.

Dit plaatje bleek goed te werken bij onze eindgebruikers. De andere lessen lees je dus de volgende keer!

door Sander Mol op vrijdag 5 juli 2013 in Acceptatie testen

Plaats als eerste een reactie!

Naam*: E-mail*: