A guest blog by Ernest van Riel
Zelf werk ik in een scrumteam en ben ik er geen fan van om elke drie weken manuele regressietesten uit te voeren. Met mij zijn denk ik velen die naar verloop van tijd tegen de muur oplopen bij de zoveelste sprint en dus ook regressie run. Dan moet je wel erg veel aan gamification doen wil je gemotiveerd blijven.
Regressietesten automatiseren
Gelukkig hebben ze hier iets op gevonden. Direct bij het ontwikkelen van je functionaliteit bouw je de automatische regressietest die herhaaldelijk uitgevoerd kan worden om dit onderdeel te testen. Dit kost dan heel wat tijd als je het onderhoudbaar en robuust wilt doen, maar dan heb je ook wat. De 3 dagen à 2 personen voor het uitvoeren van de regressietesten wordt vervangen door een geautomatiseerde set die er maximaal een paar uren over doet. Het liefst gebeurt dit ook nog ergens op een speciaal ingerichte omgeving zodat de testers ondertussen verder kunnen met exotische testen uitvoeren of andere belangrijke zaken.
Code schrijven om code te testen om code te testen…
Dit automatiseren doe ik veel zelf en ik houd ervan om het zo onderhoudsvriendelijk mogelijk op te zetten. Op dit moment moet ik hiervoor veel code schrijven. Noem het maar ‘code first‘. Op zich is dat geen probleem, maar toch moet je ermee uitkijken denk ik. Je schrijft code om code te testen. Waar is het einde? Gaat er straks ook weer iemand anders code schrijven om mijn code te testen?
Dit is louter een gedachte die bij me speelt, maar daagt wel weer uit tot het verdedigen van automatisering in deze vorm.
Waarom ook alweer?
Allereerst is er daadwerkelijke tijdswinst met automatiseren van regressietesten ook al kost het veel tijd om alles werkend te houden. Dit onderhouden doe je vaak op het niet kritieke pad waardoor het voor de delivery tijd niet uitmaakt. Aan het begin van de sprint bijvoorbeeld als er meer tijd voor is. Verder is er nog een mooi voordeel wat misschien niet een, twee, drie als eerste argument wordt aangevoerd, maar wat erg belangrijk is. Namelijk dat het saaie, repetatieve werk wordt weggenomen bij de testers. Dit werk is namelijk zo de-motiverend. Dat is een zeer belangrijk positief aspect en heel wat waard.
Blijf kritisch
Natuurlijk is het wel zaak om jezelf continu tijdens het opzetten van automatisering van testen af te vragen of je wel goed bezig bent. Testen de testscripts wel iets nuttigs of lijkt dit maar zo? Vaak zie je dat je code gaat schrijven met in je hoofd een testcase maar dat het werkend krijgen van het script op zich een doel wordt. Waarschijnlijk bouw je hierbij dan ook de nodige logica in je test om alles werkend te krijgen wat weer bugs in je test kan opleveren.
Code op code is verantwoord
Samenvattend als antwoord op mijn gedachtevraag zou ik kunnen antwoorden. Testen van code door code in de vorm van regressietesten automatiseren, is verantwoord als er maar niet teveel logica in de testscripts zit. Anders kunnen daar ook weer bugs uitkomen.
Wil je tips over testautomatisering? Lees dan dit blog van mijn collega.
—
Dit was een guestblog met toestemming geplaatst. Reacties welkom!