Acceptatietesten van software van een leverancier

Je hebt een bureau, een freelancer of een team in het buitenland betaald om iets te bouwen. Het is opgeleverd. De demo ging goed.

En nu: hoe weet je dat het werkt?

Dit is een ongemakkelijke positie waarin heel veel organisaties zich bevinden en waar weinige over praten. Je hebt geen broncode, of rechten erop die je niet kunt gebruiken. Intern kan niemand hem lezen als je hem wel had. De leverancier zegt dat het klaar is en wacht op akkoord, en het enige bewijs dat je hebt is een demonstratie die hij zelf regisseerde.

Waarom het gebruikelijke advies hier niet opgaat

Standaard testadvies gaat ervan uit dat je eigenaar bent van de codebase en mensen in dienst hebt die hem begrijpen. Schrijf unittests, verhoog de dekking, hang het in CI. Niets daarvan is hier beschikbaar, en het voorstellen aan een opdrachtgever in deze positie helpt niet.

Wat je wél hebt is waardevoller dan het lijkt: je weet wat de software hoort te doen. Jij hebt het gespecificeerd. Dat is precies de kennis die acceptatietesten vereist, en het is kennis die de leverancier niet namens jou kan leveren.

Schrijf de criteria vóór de oplevering

Het meest rendabele dat je kunt doen kost niets en gebeurt voordat er ook maar één regel code bestaat: schrijf je acceptatiecriteria als concrete flows.

Een bruikbaar criterium noemt drie dingen — een begintoestand, een handeling en een waarneembare uitkomst:

Als klant met één artikel in het mandje levert het afronden van de bestelling met een geldige kaart een bevestigingsmail op en een bestelling die zichtbaar is in de accounthistorie.

Vergelijk dat met wat de meeste contracten werkelijk bevatten: ‘het bestelproces moet correct functioneren’. Het eerste kan iemand controleren door naar een scherm te kijken. Het tweede is een ruzie die staat te wachten.

De toets voor een goed criterium is eenvoudig. Als je het niet kunt nagaan door naar de applicatie te kijken, is het geen acceptatiecriterium. Het kan een legitieme eis zijn — prestatiedoelen, beveiligingshouding, codekwaliteit — maar het vraagt om een ander soort verificatie en hoort apart te worden behandeld.

Vijftien tot dertig hiervan dekken de meeste uitbestede projecten. Hang ze aan het contract.

Controleer ze zelf

Accepteer een demonstratie niet als bewijs. Een demo is een ingestudeerde route door de software, uitgevoerd door de mensen die hem bouwden, op data die zij kozen. Het vertelt je dat het gelukkige pad op een dinsdag werkt.

Voer de criteria zelf uit, tegen de opgeleverde applicatie, op een systeem dat jij beheert, met data die jij koos. Omdat end-to-end-testen via de interface werkt, vereist dit geen toegang tot de code en geen medewerking behalve een URL en inloggegevens.

Drie dingen die het controleren waard zijn en die leveranciers zelden voordoen:

• De ongelukkige paden. Een verlopen kaart. Een dubbel e-mailadres. Een verplicht veld leeg gelaten. Hier is uitbestede software het zwakst, omdat de specificatie hier het dunst was.
• Rechten. Log in als de ene klant en probeer bij de gegevens van een andere te komen. Dit is de storing die verandert in een meldplicht.
• De tweede keer. Draai dezelfde flow twee keer. Software die uitgaat van een schone begintoestand breekt vaak bij de herhaling.

Bewaar de tests na het akkoord

Acceptatietesten wordt meestal behandeld als een gebeurtenis: controleren, tekenen, verder. Dat verspilt het grootste deel van de waarde.

De criteria die je schreef zijn een regressiesuite. Blijft de leverancier op een onderhoudscontract, dan beschrijven ze nu wat er in toekomstig werk niet mag breken. Blijft hij niet, en staat de software twee jaar onaangeroerd, dan is de suite hoe je erachter komt dat een browserupdate, een verlopen certificaat of een gewisselde betaalprovider iets heeft gesloopt waar niemand naar keek.

De kosten om ze te laten draaien zijn klein. De kosten van een twee maanden oude storing die je van een klant hoort, zijn dat niet.

Wanneer er iets faalt

Meld storingen als reproducties, niet als meningen. ‘Het afrekenen is stuk’ valt te betwisten; een specifieke flow met specifieke data, twee keer gedraaid, met een vastgelegd resultaat niet. Het verschuift het gesprek van of er een probleem is naar wanneer het wordt opgelost.

Dat is in een zakelijke relatie meer waard dan het klinkt. Leveranciers handelen meestal niet te kwader trouw — ze werken vanuit een specificatie die vager was dan beide partijen doorhadden. Concrete, reproduceerbare criteria halen de dubbelzinnigheid weg die een oplevering in een geschil verandert.

Tools die bij deze situatie passen

De eis is ongebruikelijk en versmalt het veld sterk: de tool moet draaien tegen een applicatie die je niet kunt aanpassen, zonder toegang tot de code, zonder buildpijplijn en waarschijnlijk zonder ontwikkelaars.

Dat schrapt codegebaseerde frameworks, alles wat CI vereist en de meeste QA-platformen. Wat overblijft zijn tools die alleen een URL en een beschrijving van de flow nodig hebben: Testmode, testRigor, Rainforest QA, Functionize en Autify.

Schrijven in gewone taal telt hier zwaarder dan gewoonlijk, om een specifieke reden: de persoon die weet wat er is besteld, is degene die de specificatie schreef, niet een ontwikkelaar. Als het schrijven van de test code vereist, zitten de kennis en het kunnen in verschillende hoofden, en gaat er iets verloren in de overdracht.

Zie het overzicht van AI-testtools voor het hele veld, geordend naar wat elke tool van je nodig heeft, en regressietesten zonder QA-team voor wat je na het akkoord met de suite doet.