Het allerbelangrijkste in deze situatie: voer je testen twee keer uit. Normaal bereid je je testen voor en zodra de ontwikkelaar klaar is, voer je ze uit. In deze situatie voer je ze twee keer uit. Een keer voordat de wijziging is opgeleverd. Een keer nadat de wijziging is opgeleverd.
Waarom twee keer? De eerste keer kan je zien als de basismeting. Zodra je weet hoe de applicatie nu werkt en je weet wat er gaan wijzigen, kan je voorspellen hoe de applicatie na de wijziging gaat werken. Bijvoorbeeld als er 20% van het totaalbedrag afgehaald moet worden, kan je van tevoren nagaan wat het totaal bedrag is voor de wijziging. En vervolgens moet het totaalbedrag na de wijziging 20% lager zijn. Als er via een import een persoon moet worden aangemaakt, kan je de gegevens handmatig invoeren en het eindresultaat vastleggen. Tenslotte zal in veel gevallen het resultaat gelijk moeten zijn.
Daarnaast heeft dit nog een ander voordeel: de snelheid. Als je voor de oplevering van de wijziging al precies weet wat de wijziging is, welke gegevens ingevoerd moeten (maar vooral ook kunnen) worden, en wat het eindresultaat moet zijn, kan je zeer snel testen. De kans op onverwachte invoerproblemen of op extra vragen is een stuk kleiner. En hierdoor is de testuitvoering opeens een stuk sneller.
Deze manier van testen is even wennen. Je voorbereiding voelt zeker minder Agile aan, vooral omdat het vraagt om meer documentatie. Maar wat je behoudt is je flexibiliteit. Je bent in staat te testen, ongeacht kennisproblemen. En als het moet, kan je snel testen. En nog een extra: problemen komen eerder naar voren, waardoor je meer tijd hebt om ze op te lossen. Grootste obstakel: jij en je team. De bereidheid te testen op een manier, die werkt. En niet op een manier volgens het boekje.
Geen opmerkingen:
Een reactie posten
Opmerking: Alleen leden van deze blog kunnen een reactie posten.