Is testen het controleren van software? Is testen het accepteren van software? Of is testen het onderzoeken van software? Testen is dit allemaal! Maar in de praktijk lijkt het acceptatieproces voor velen onbekend terrein. Wie moeten er precies accepteren en hoe pakken we dat aan?
Wat is controleren, onderzoeken en accepteren? Controleren is bepalen of het (gemaakte) softwareproduct voldoet aan de specificaties. Onderzoeken is het verkennen van het (gemaakte) softwareproduct op fouten. Accepteren is het aanvaarden dat de beschreven specificatie of het beschreven product de gewenste oplossing is van het probleem (eventueel onder bepaalde voorwaarden met de bekend zijnde gebreken).Testen bestaat zodoende uit controleren, onderzoeken en accepteren van een product.
Accepteren lijkt nog onbekend terrein binnen het testen. Natuurlijk weten testers dat acceptatie na het testen dient te gebeuren, maar helaas wordt het acceptatieproces in de praktijk niet altijd adequaat uitgevoerd. Wat is dan accepteren? Volgens het woordenboek is een van de verklaringen: 'aannemen, aanvaarden'. Bij accepteren aanvaarden we dus het geleverde softwareproduct.
Gebruikersacceptatie
Vaak denkt men dat testers de software ook accepteren, maar de tester geeft alleen advies over de vrijgave ervan. Het is alleen de gebruiker (of opdrachtgever) die kan accepteren. Sterker nog, dat moet hij ook expliciet doen. De klant is namelijk wettelijk verplicht een geleverd product binnen een bepaalde termijn te accepteren. Anders vervalt het recht op aanpassing of vervanging van het product.
Als de klant ‘accepteert', erkent hij expliciet dat hij om het geleverde product heeft gevraagd en dat het volgens zijn wensen functioneert. Een goed moment om de klant een geleverd product expliciet te laten ‘accepteren' is het uitvoeren van de zogenaamde gebruikersacceptatietest (GAT) en de productie-acceptatietest (PAT). Tijdens deze acceptatietesten wordt specifiek gecontroleerd of het product aan de verwachtingen van de klant (gebruiker en beheerder) voldoet.
Acceptatietesten
Veelal fungeren GAT en PAT als een laatste controle van het systeem voor implementatie. Wanneer de software (tijdens normaal gebruik) zonder problemen en volgens verwachting functioneert, mogen de gebruiker en beheerders dezelfde mate van stabiliteit in productie verwachten. De resultaten van deze testen geven vertrouwen aan de gebruiker en beheerder over de prestaties van het systeem.
De GAT wordt in de praktijk nog veelal uitgevoerd door vakdeskundigen: de testers. De testers doen de voorbereidingen voor de GAT en voeren de opgestelde testgevallen voor de GAT uit. Maar kan een tester ook vaststellen dat het product voldoet aan de gebruikerseisen? Een ‘stempel' van Test is nog helemaal geen acceptatie! De gebruikerseisen dienen weliswaar te zijn verwerkt in de systeemeisen, maar deze systeemeisen hoeven geen juiste of volledige weergave te zijn van de werkelijke behoefte van de gebruiker. Alleen de gebruiker kan bepalen wat zijn behoefte is en ook alleen die gebruiker kan dus vaststellen of in die behoefte is voorzien.
De PAT daarentegen wordt in de praktijk wel uitgevoerd door de juiste deskundigen: de beheerders. Tijdens de PAT zijn de beheerders ook de acceptanten van de software. Zij dienen te bepalen of de software voldoet aan de door hen gestelde eisen. Deze controle is een zwaar onderschatte controle. Testomgevingen werken anders dan productieomgevingen, koppelingen zijn anders en dit zijn er meer, (uit)leveringen lopen technisch juist en de architectuur speelt een grotere rol. Alle eisen vanuit de beheerders moeten juist werken om een beheerder apart te laten accepteren.
Acceptatie
Acceptatie kan worden verkregen als gebruikers bereid zijn om de software daadwerkelijk te gebruiken, bijvoorbeeld omdat deze een toegevoegde waarde heeft voor het werkproces en als beheerders de software kunnen beheren. Testers kunnen het proces rond de GAT weliswaar begeleiden en ondersteunen, maar zij kunnen de acceptatie niet uitvoeren. Dat doen de gebruikers zelf.
Acceptatie is belangrijk. Na acceptatie van de software blijft over wat de gebruikers krijgen om mee te werken. Zorg ervoor dat de acceptatie goed is gedaan en dat het product vertrouwen geeft aan de gebruiker!
“Testen bestaat zodoende uit controleren, onderzoeken en accepteren van een product”
Accepteren is GEEN onderdeel van testen! Accepteren is een besluit nemen op basis van resultaten. Dit KAN op basis van testen zijn, maar kan ook van andere input komen. De activiteiten die in deze fase ontplooid worden, zijn enkel bedoeld om informatie te leveren. De naam “acceptatietest” is dus, ook al is het volledig ingeburgerd, niet slim gekozen en misschien zelfs misleidend. Juist door deze term ontstaat de verwarring.
Het is dus belangrijk om een duidelijk onderscheid aan te brengen tussen de testfase en het acceptatiemoment.
Mijn ervaring is dat de acceptant veelal geen tijd heeft om inspanning in de testfase te steken. Hij/zij besteedt de werkzaamheden voor de voorbereiding en de uitvoering uit aan iemand die al ervaren is in testen: de tester. Opzich goed mogelijk, echter er zijn een aantal belangrijke aandachtspunten:
– Het betrekken van een tester die in eerder stadium van het testtraject meegedraaid heeft, is onverstandig. Een objectieve blik is belangrijk.
– Bij de testvoorbereiding dient de acceptant ALTIJD betrokken te zijn. Er dient immers bepaald te worden wat de tester moet gaan doen om de acceptant van voldoende informatie te voorzien. Bepaald dit samen met de acceptant. (bijv. door het opstellen van testdoelen).
– Laat de geplande activiteiten (zoals bijv. opgestelde testscenario’s o.b.v. testdoelen) akkoorderen door de acceptant. Je hebt dan achteraf geen misverstand over hetgeen de acceptant wil zien en jij hebt laten zien.
– Maak duidelijk dat deze activiteiten en de acceptatie los staan van elkaar.
– Maak duidelijk dat de acceptatie ALTIJD de taak van de acceptant blijft.
citaat “In de GAT wordt in de praktijk nog veelal uitgevoerd door vakdeskundigen: de testers”.
Ik zie dat genuanceerder: in de GAT dient de eindgebruiker (danwel senior-gebruiker/vertegenwoordiger(s) van de eindgebruiker) hun zegje te doen over het voorhanden zijnde produkt, met oogpunt voor de te verwachten gebruikerseisen: Hoe goed kan het systeem/applicatie mij als gebruiker ondersteunen in mijn rol?
Helaas worden testers veelal ingezet als ‘gedelegeerd’ eindgebruiker, wat pas mogelijk is indien op een gedegen wijze de criteria van de eindgebruiker vastgelegd zijn. Echter, het matchen van deze beschreven criteria (al dan niet SMART beschreven) wil nog niet betekenen dat de GAT daadwerkelijk met succes verloopt. De GAT valt/staat met de acceptatie van de eindgebruikers.
De tester(s) kunnen wel een actieve begeleidende rol spelen in het doorlopen van een GAT, door de eindgebruikers te ondersteunen in hun rol in deze fase.
Goed dat hier in ieder geval het onderscheid wordt gemaakt tussen testen en acceptatietesten (ook al is die term mogelijk niet helemaal juist, hij is wel ingeburgerd). Echter (citaat)”Tijdens deze acceptatietesten wordt specifiek gecontroleerd of het product aan de verwachtingen van de klant (gebruiker en beheerder) voldoet.” Daar wringt de schoen. Acceptatiecriteria die gerelateerd zijn aan de verwachting (en de legitimatie van het project) zijn maar zelden zo geformuleerd dat daarop kan worden geaccepteerd. De gebruiker die feedback geeft op verwachtingen wordt door de “deskundigen”in de hoek gezet, omdat hij/zij meestal al in een eerdere fase in arren moede akkoord is gegaan met specificaties waar een niet deskundige niet van kan vaststellen of ze de verwachtingen zullen waarmaken. Geen recht van spreken meer en er “moet” dus geaccepteerd worden.
Acceptatie begint VOOR de ontwikkeling, door op basis van de behoefte en de verwachting acceptatiecriteria te definiëren, en die tijdens het project als leidraad te blijven gebruiken voor alle ontwerpbeslissingen die genomen worden. Dan is het mogelijk om systemen te ontwikkelen en implementeren die niet bij live gaan al gelijk een fase 2 opstarten met 50% van de projectkosten als “meer”werk. Toetsing aan deze criteria is een business-activiteit.