Een goedkeuringsstroom met duidelijke acceptatiecriteria testen

Beschrijf uitkomst en beginsituatie

Bepaal per belangrijke workflow wie onder welke voorwaarden mag handelen en welke toestand daarna aantoonbaar moet zijn. GOV.UK beschrijft acceptatiecriteria als uitkomsten om de vervulde gebruikersbehoefte te controleren. Een brede toezegging als “goedkeuring werkt” wordt met die voorwaarden toetsbaar.

Voorbeeld: een intern wijzigingsverzoek goedkeuren

Dit plan is volledig fictief. Verzoek CH-27 begint als draft, gaat met volledige reden naar pending en mag door de toegewezen beoordelaar op approved worden gezet. Gebruik synthetische gegevens en geschikte testaccounts in een beheerste testomgeving. De tabel bevat verwachte resultaten, geen uitgevoerde tests.

De laatste rij veronderstelt duidelijke weigering vóór de wijziging. Ontbreekt alleen een antwoord, dan is de opgeslagen toestand eerst onzeker; plan een aparte controle van de werkelijk opgeslagen toestand.

Controleer toestand, rechten en terugmelding

Een verborgen knop bewijst geen toegangscontrole. OWASP vraagt passende rechtencontrole bij ieder verzoek. Controleer ook directe aanroepen en de werkelijk opgeslagen toestand. Een succesmelding is onvoldoende.

Zet iedere casus met een bepaalde beginsituatie op. Playwright adviseert onafhankelijke tests met beheerste gegevens en sessies. Een eerdere rol of toestand mag niet ongemerkt de volgende uitkomst bepalen. Bespreek met het team welke componentcontroles en volledige stromen worden geautomatiseerd.

Leg versie, omgeving, rol en testgegevens vast. Scheid werkelijke resultaten en bevindingen van verwachtingen; een niet-uitgevoerde casus blijft open. Laat de inhoudelijk verantwoordelijke afwijkingen beoordelen en getroffen gevallen na correctie opnieuw testen.

Bronnen

• GOV.UK: Writing user stories

• OWASP: Authorization checks

• Playwright: Best practices