Zowel bij programmeurs en testers is heel veel vraag naar duidelijke specificaties. Logisch, de informatie uit het functionele ontwerp heb je ook nu nog nodig om tot een goede applicatie te komen. Ook om duidelijk te kunnen afspreken wat wel en wat niet geaccepteerd gaat worden. Daarom gaan we het volledige FO als scrumteam vaak proberen op te vangen in de beschrijving van de story. En met enige grote regelmaat gebeurt dit via de acceptatiecriteria in de story. Ook als tester heel handig, want je weet zeker dat je alle informatie waarop je moet testen in de story staat.
Maar is de acceptatietest nu eigenlijk wel een acceptatietest? Een acceptatietest heeft in mijn ogen voornamelijk als doel om te bepalen of het opgeleverde werk, vanuit de business en de klant gezien, naar productie kan. Dus de acceptatiecriteria moeten hier een afspiegeling van zijn. En zolang het project op tijd loopt, lijkt dit ook het geval. Totdat er tijdnood komt. Dan blijken veel lijsten met acceptatiecriteria opeens niet zo belangrijk te zijn.
Acceptatiecriteria zijn bijvoorbeeld doorgeslagen in detail. Stel je hebt een invoerveld waarbij het acceptatiecriterium is: "Bij een geldige waarde in het veld moet naast het veld een groen vinkje getoond worden". Stel nu dat er een zwart vinkje is gebouwd. Er is geen tijd meer, dus het invoerveld gaat naar productie of het invoerveld gaat niet naar productie. Het is het enige veld in een scherm, de validatie is verder goed. Er is geen enkele reden om het af te keuren, behalve de kleur van het vinkje. Neem maar van mij aan, het invoerveld wordt naar productie opgeleverd. Zelfs als het hele vinkje niet aanwezig zou zijn, het invoerveld gaat zeer waarschijnlijk naar productie. Want wat wil de gebruiker? De gebruiker wil geen groen vinkje. De gebruiker wil een invoerveld waaraan duidelijk te zien is of de ingevoerde waarde fout of goed is. Of dit wordt aangegeven met een vinkje, met een foutmelding met een rode rand om het invoerveld, de gebruiker maakt het niet uit. Waarom maakt het in de acceptatiecriteria dan wel uit?
Wat ook wordt toegepast in de acceptatiecriteria is de verwijzingen naar andere documenten. Het gebouwde scherm moet voldoen aan het design. Het moet voldoen aan het interactie-ontwerp. Of misschien zelfs voldoen aan het functioneel ontwerp. Tja, vroeger leek datgene wat in productie ging al niet volledig op het ontwerp. Zou dat nu zoveel anders zijn? Ik heb in ieder geval nog geen acceptatietest meegemaakt waarin de acceptatietester het ontwerp tot op de letter of tot op de pixel ging controleren. En bij het eerste kleine verschil zei: "Nee, dit gaat dus niet naar productie"
Het probleem is naar mijn mening dat we graag blijven bij het oude, vertrouwde, veilige watervalprincipe van een contract met handtekening. We bouwen wat voor ons is vastgelegd. Niets meer en niets minder. Als we het niet gebouwd hebben en het was ook niet vastgelegd dat we het moesten bouwen, dan is het extra. Vroeger extra tijd en geld, nu een extra story. Want het blijft dan toch een vooruitgang? Als iemand wilde afwijken was dat bij waterval eigenlijk niet toegestaan. Nu kan je de story gewoon direct prioriteren, je mag dus afwijken. Dus vooruitgang.....
Als gevolg hiervan zie ik ontwikkelaars die al vijfentwintig keer een datum invoerveld hebben gebouwd tot in detail vragen hoe het veld moet werken. Het antwoord "Kan mij wat schelen, als ik maar alleen geldige datums kan invoeren" is vanuit de business vaak het enige juiste antwoord. Maar dat antwoord mag niet. Want zo kunnen we niet bouwen of testen. Hoe moeten we anders antwoorden krijgen? Tja..... bedenk zelf het antwoord? Als je al vijfentwintig keer een datum invoerveld hebt gebouwd of getest, kan je dan niet zelf bedenken welke invoercontroles nodig zijn om aan het acceptatiecriterium te voldoen?
Maar hoe kan je dan weten of het gebouwde in een keer naar wens is? Tja, dat weet je niet. Misschien heb je een zwart vinkje gebouwd en wordt de vraag gesteld "Kan dat vinkje niet groen zijn?" Waar het om gaat is het vertrouwen dat je in je scrumteam en met de business dit soort zaken via overleg kan oplossen. Overleg veel, tijdens de bouw, tijdens de test, tijdens de acceptatietest. Als je eerst te horen krijgt "Maak me niet uit" en later "Ik wil het toch anders", zie dat niet als een nadeel van de methode. Dit is juist een van de belangrijkste redenen waarom we geen functioneel ontwerpen meer schrijven, waarom we meer Agile willen werken. Vaak weet je pas echt wat je wil, als je het voor je ziet en je er werkelijk doorheen kan klikken.
Hoe ga je je hiermee om tijdens een acceptatietest? Overleg vooral goed of het verstandig is de nieuwe wensen direct op te pakken of door te schuiven. De sprint mag niet in gevaar komen. En het blijft: als het gebouwde aan de acceptatiecriteria voldoet, mag een wijziging in het gebouwde niet de oplevering in gevaar brengen. Wanneer dit wel het geval is, gaat het gebouwde zoals het is naar productie. Zonder wijzigingen. Dit klinkt streng, maar eigenlijk willen bijna altijd alle partijen dit. Ieder vanuit hun eigen belang. Mits de acceptatiecriteria een goede weergave waren van de echte wensen.
Maak daarom van een acceptatietest een test waarin de acceptatiecriteria altijd volledig gecontroleerd worden en leiden tot een betrouwbare acceptatietest. Zorg ervoor dat de acceptatiecriteria weergeven wat de business wil. En maak van de acceptatiecriteria geen weergave van wat het scrumteam wil weten. Dit zijn twee verschillende zaken. We moeten dan ook allemaal, hoe moeilijk het soms ook is, leren om deze twee soorten beschrijvingen los van elkaar te gaan zien. En het belangrijkste daarbij is vertrouwen. Vertrouwen dat je er zonder contract met handtekening, maar met overleg, ook wel samen uit gaat komen.
Geen opmerkingen:
Een reactie posten
Opmerking: Alleen leden van deze blog kunnen een reactie posten.