Testcases schrijven die businesstesters begrijpen

Waarom businesstesters andere testcases nodig hebben

Een systeemtest wordt gedaan door mensen die het systeem hebben gebouwd of het goed kennen. Een acceptatietest wordt gedaan door mensen die het gebruiken: zij kennen het werk, niet de configuratie. Ze weten niet welk veld nieuw is, welke flow op de achtergrond draait, of wat de ontwikkelaar bedoelde.

Een UAT-testcase moet dus werken voor iemand die:

• het bedrijfsproces uit het hoofd kent, maar de nieuwe schermen niet;
• een paar uur heeft tussen ander werk door, geen week;
• nooit hoeft te raden of een stap geslaagd of mislukt is;
• stopt en wacht als een stap onduidelijk is, en tijd verliest.

Elk uur dat je in duidelijke testcases steekt, bespaart vele uren op de testdagen: minder vragen, minder issues die een misverstand blijken, en resultaten waarop je bij de go/no-go kunt vertrouwen.

Vanuit user stories en processen

Testcases komen uit twee bronnen, en je hebt ze allebei nodig.

User stories en hun acceptatiecriteria

Een user story zegt wat iemand wil doen en waarom: Als verkoper wil ik een gekwalificeerde lead converteren, zodat ik een account, een contactpersoon en een opportunity krijg. De acceptatiecriteria zeggen wanneer de story af is. Elk acceptatiecriterium is een kandidaat voor een stap of een testcase.

Controleer de dekking: elke user story in scope heeft minstens één testcase nodig. Een story zonder testcase is een gat, en gaten worden in productie gevonden.

Bedrijfsprocessen, end-to-end

User stories worden klein gesneden voor de ontwikkelaars. De business werkt in processen die over veel stories heen lopen: lead to cash, quote to order, case management van e-mail tot oplossing. Een story kan op zichzelf slagen terwijl het proces breekt bij de overdracht tussen twee teams.

Voeg daarom end-to-end-testcases toe die een proces van begin tot eind volgen, over rollen heen: de verkoper maakt de offerte, de manager keurt die goed, de order gaat naar finance. Dat zijn vaak de testcases die voor de business het meest tellen.

In UAT StudioLees de user stories uit Jira of Azure DevOps in op de kaart User stories, en vink Only stories without test cases aan om de gaten te zien. Met de module AI test design stelt AI testcases voor uit je stories of uit een procesbeschrijving, ook op het eigen model van je bedrijf. Niets wordt een testcase tot jij het goedkeurt. Zonder de module geeft Prepare with your own AI een prompt om in de AI van je eigen bedrijf te plakken; stappen met [CHECK] zijn aannames om te controleren.

Eén doel per testcase

Een testcase test één bedrijfsscenario, met één doel. De titel zegt wat de tester bereikt, in de woorden van de business:

• Een lead converteren met een bestaand account
• Een offerte goedkeuren met een korting boven 20%
• Een e-mail van een bekende klant naar de juiste wachtrij routeren

Niet Test het lead-object, en niet Leads, opportunities en offertes. Als een testcase meerdere doelen heeft, blokkeert één fout ze allemaal, en zegt het resultaat weinig: wat faalde er, en wat werkt nog wel?

Hoe groot is één testcase?

Als vuistregel heeft een testcase drie tot vijftien stappen, en kost die een tester vijf tot twintig minuten. Veel langer, dan heeft hij waarschijnlijk meer dan één doel: splits hem. Veel korter, dan hoort hij misschien bij een buurman.

End-to-end-testcases zijn de uitzondering. Ze volgen een heel proces en mogen langer zijn. Houd ze, maar zorg dat elk deel van het proces ook een eigen kortere testcase heeft, zodat een fout makkelijk te plaatsen is.

Stappen met een verwacht resultaat

Elke stap heeft twee delen: een actie (wat de tester doet) en een verwacht resultaat (wat er moet gebeuren). Het verwachte resultaat maakt een stap testbaar. Zonder dat bepaalt de tester wat goed genoeg is, en twee testers bepalen dat verschillend.

Schrijf de actie

• Eén actie per stap. Open de lead en klik op Convert is prima; vijf klikken in één stap niet.
• Begin met een werkwoord: open, klik, vul in, kies, sla op.
• Gebruik de labels zoals ze op het scherm staan, vet of tussen aanhalingstekens.
• Zeg wat, niet hoe het systeem vanbinnen werkt. Sla de offerte op, niet start de goedkeuringsflow.

Schrijf het verwachte resultaat

• Zeg wat de tester ziet: een melding, een waarde in een veld, een nieuw record, een status.
• Wees specifiek. De opportunity staat in de fase Qualification, niet het werkt.
• Noem wat niet mag gebeuren als dat ertoe doet: Er wordt geen tweede account aangemaakt.
• Voor dingen die het systeem zelf doet, zeg waar je moet kijken: De case staat binnen een minuut in de wachtrij Benelux Support.

Testdata en rollen

Testdata

Testers verliezen meer tijd aan het zoeken naar data dan aan enig ander deel van een UAT. Zet de data in de testcase waar die ertoe doet: welke klant, welk product, welke prijslijst of price book, welk bedrag. Bereid die data voor in de testomgeving vóór de eerste testdag.

• Gebruik namen die duidelijk testdata zijn, zoals Jansen Logistics (test).
• Geef elke tester eigen records als ze data wijzigen, zodat niet twee mensen dezelfde opportunity bewerken.
• Voeg waarden aan de randen toe: een korting net onder en net boven de limiet, een leeg verplicht veld.
• Gebruik geen echte persoonsgegevens van klanten waar je dat kunt vermijden.

Rollen

In een CRM hangt wat een gebruiker kan zien en doen af van zijn rol: een profiel en permission sets in Salesforce, beveiligingsrollen en een bedrijfseenheid in Dynamics 365. Een UAT bewijst dat elke rol zijn werk kan doen, en alleen zijn werk. Elke testcase zegt dus welke rol hem test, en de tester logt in met een testgebruiker die precies die rol heeft.

Test nooit met een beheerder. Een beheerder ziet alles en mag alles, dus de problemen die een UAT zou moeten vinden blijven verborgen.

In UAT StudioElke stap heeft een actie, een verwacht resultaat en eventueel testdata. Elke tester krijgt een Test role en een Test account, die bovenaan zijn tests staan als Log in as …, en de rol staat naast zijn naam bij elk issue dat hij meldt.

Prioriteit en risico

Er is nooit genoeg tijd om alles even goed te testen. Markeer elke testcase zodat de belangrijke eerst worden getest, en afgerond worden ook als de tijd opraakt.

Zet het risico ernaast: wat het kost als dit na de go-live misgaat. Een verkeerde prijs op een factuur is een hoog risico; een verkeerd label op een rapport een laag. Binnen dezelfde prioriteit beginnen testers met hoog risico.

Wees streng met Must. Als de helft van de testcases Must is, betekent het label niets: houd het voor wat de business niet kan missen. Spreek de prioriteiten af met de proceseigenaren: zij besluiten ook bij de go/no-go, waar Must-testcases die niet geslaagd zijn het zwaarst wegen.

In UAT StudioStel Priority (Must, Should, Could) en Risk (High, Medium, Low) in via de editor of in een kolom bij het importeren. Waarden uit andere tools worden ook gelezen: Critical en High worden Must, Medium en Normal Should, Low Could. Testers zien hun Must-testcases eerst, met binnen elke prioriteit hoog risico eerst.

Een voorbeeld

Testcase 12: Een offerte goedkeuren met een korting boven 20%

Prioriteit Must, risico High. User story CRM-118. Rol: verkoper (stap 1 tot en met 3) en salesmanager (stap 4 en 5).

Let op wat dit laat werken: één doel in de titel, één actie per stap, een verwacht resultaat dat een tester kan controleren, de data en de rol benoemd, en een unhappy path in stap 3. Voeg een tweede testcase toe voor een korting onder de limiet, die geen goedkeuring nodig zou moeten hebben.

Veelgemaakte fouten

• Geen verwacht resultaat, of werkt zoals verwacht. De tester moet raden wat er werd verwacht.
• Technische taal. Veldnamen uit de database, objectnamen, of controleer of de trigger afgaat. Gebruik de woorden op het scherm.
• Te veel doelen in één testcase. Eén fout blokkeert de rest, en het resultaat zegt je weinig.
• Alleen het happy path. Voeg een verplicht veld toe dat leeg blijft, een waarde boven een limiet, een gebruiker die een record niet mag zien.
• Ontbrekende testdata. Open een opportunity: welke? In welke fase, met welke producten?
• Geen rol. De tester gebruikt het account dat hij toevallig heeft, vaak een met te veel rechten.
• Gekopieerd uit de systeemtest. Geschreven voor ontwikkelaars, met stappen die businesstesters niet kunnen volgen.
• Alles is Must. Dan is niets het, en worden de belangrijke tests niet eerst gedaan.
• Eén keer geschreven, nooit gelezen. Scripts die niemand vóór de testdagen heeft gecontroleerd, staan vol oude labels en verkeerde menu's.

Laat een key user ze reviewen

Vraag vóór de testdagen een key user uit de business om de testcases te lezen en er twee of drie uit te proberen in de testomgeving. Die vindt wat de schrijver niet ziet: een stap die kennis veronderstelt, een label dat veranderd is, een proces dat in een ander land anders loopt.

Controleer tegelijk dat elke user story in scope een testcase heeft, dat elke rol in scope iets test, en dat de testdata bestaat. Bewaar de testcases daarna na de go-live: ze zijn je regressietest voor de volgende CRM-release.

In UAT StudioImporteer testcases uit Excel, Azure DevOps, Jira met Xray of Zephyr Scale, of TestRail, of schrijf ze in de editor. De sjabloonbibliotheek, een add-on bij elk betaald pakket, heeft kant-en-klare scripts voor Salesforce en Dynamics 365 om aan je eigen inrichting aan te passen.

Gratis te gebruiken

Voor al het andere dat je vóór, tijdens en na de UAT regelt, zie de UAT-checklist voor een CRM-go-live, ook als gratis Excel-bestand.