Een acceptatiechecklist maken van een demo-opname
Maak van de productdemo een checklist met voorwaarden, acties, verwachte resultaten en bewijs. Met een voorbeeld op basis van afgesproken eisen.
Een geslaagde demo dekt de getoonde scenario’s
Tijdens het gesprek leek het formulier de aanvraag correct te verzenden. Een andere rol, een tweede verzending of een leeg verplicht veld is misschien niet bekeken. De opname toont wat aan bod kwam. De overige scenario’s vergen aparte tests.
De checklist begint bij de vooraf afgesproken eisen. Leg nieuwe ideeën van kijkers apart vast. Als de scope tijdens acceptatie verschuift, praten deelnemers over verschillende versies van de opdracht.
Bereid de controles voor met de opname
Leg versie en voorwaarden vast
Noteer versie of build, wie demonstreerde en in welke rol. Beschrijf testgegevens en omgeving zo dat iemand het scenario kan herhalen. Markeer onbekende voorwaarden.
Koppel de controle aan een eis
Zoek het afgesproken gedrag in de opname. Eén demo kan meerdere controles dekken, maar elke controle heeft een eigen verwachte uitkomst nodig. Markeer een verplichte maar niet getoonde eis als ‘niet getest’.
Beschrijf de handeling en verwachting
Vervang ‘controleer het formulier’ door de in te voeren gegevens, de knop en wat moet gebeuren. Beschrijf de reactie op ongeldige invoer. Voeg een nieuw randgeval alleen toe als het binnen de afgesproken scope valt.
Voer de controles opnieuw uit
Voer de scenario’s uit op de afgesproken versie, leg het werkelijke resultaat vast en voeg bewijs toe. Onderscheid fouten, geblokkeerde tests en ontbrekende gegevens. Herhaal na een oplossing het getroffen scenario en noteer de nieuwe datum.
Acceptatie van een formulier voor een adviesaanvraag
Dit voorbeeld is fictief. Namen, voorwaarden en uitkomsten dienen ter uitleg.
Telefoon is verplicht. Na geslaagde verzending verschijnt de aanvraag in de lijst en ziet de bezoeker een bevestiging. Zonder telefoonnummer mag het formulier niet verzenden.
Er zijn drie waarneembare uitkomsten: het verplichte veld wordt gecontroleerd, een aanvraag wordt aangemaakt en de bezoeker krijgt bevestiging. Een fraai scherm na de klik bewijst één onderdeel.
Zonder toegang tot de lijst markeert de tester het aanmaken als ‘geblokkeerd’. De woorden van de presentator zijn onvoldoende om de controle te laten slagen.
| Controle | Verwachte uitkomst | Wat bewaren? |
|---|---|---|
| Telefoonveld leeg | Melding over het verplichte veld en geen aanvraag | Schermafbeelding en controle van de lijst |
| Geldige gegevens | Eén aanvraag met de ingevoerde waarden | Vermelding in de testlijst |
| Geslaagde verzending | Duidelijke bevestiging voor de bezoeker | Schermafbeelding na verzending |
Sjabloon voor één acceptatiecontrole
Elke rij vermeldt welke observatie de eindstatus bepaalt.
Controle-ID: Afgesproken eis: Versie / rol / omgeving: Invoergegevens: Handelingen: Verwacht resultaat: Werkelijk resultaat: Status: geslaagd / mislukt / niet getest / geblokkeerd Bewijs en tijdcode: Bijbehorende oplossing: Datum van hertest:
Controleer de lijst vóór de test
- De punten verwijzen naar de afgesproken scope.
- De verwachte uitkomst is zichtbaar of meetbaar.
- Getoond gedrag staat los van eigen controles.
- De omstandigheden van fouten zijn reproduceerbaar.
Een nadere blik
Moeten alle opmerkingen uit het overleg erbij?
Scheid afwijkingen van afgesproken eisen van nieuwe wensen. Beoordeel nieuwe wensen apart, zodat acceptatie de scope niet eindeloos uitbreidt.
Kunnen we alleen op video accepteren?
Dat hangt af van de afspraken. Video kan het getoonde scenario staven. Vermeld hoe de controle is uitgevoerd en welke grenzen ze had.