Redactie: Eric Spaargaren
Auteur: Bas Dijkstra ● bas@ontestautomation.com
Eén van mijn klanten waar ik momenteel rondloop. zit midden in een transitie van traditionele projectorganisatie met softwareontwikkeling volgens de watervalmethode naar Agile, met als uiteindelijk doel om software op te kunnen leveren volgens de Continuous Delivery-filosofie. Dit zal veel van jullie wel bekend voorkomen, er zijn immers heel veel organisaties die deze transitie hebben gemaakt, er momenteel mee bezig zijn of er op zijn minst over nadenken.
Mijn specifieke opdracht in dit verhaal is om ervoor te zorgen dat testen, en dan vooral testautomatisering (dat is nou eenmaal waar ik denk iets vanaf te weten…) een passende plek vindt in de nieuwe werkwijze en organisatiestructuur. En dat is best een uitdaging in een organisatie die al zo’n grote transitie aan het doormaken is.
Een van de vragen die afgelopen week weer eens naar boven kwam, is dezelfde vraag die ik ook bij een aantal van mijn eerdere opdrachtgevers al heb zien langskomen:
‘Hoe maken we testautomatisering onderdeel van onze Definition of Done?’
Op zich is dit natuurlijk een logische vraag. Ik zie het nog te vaak gebeuren dat iedereen in het team – en gelukkig ook veel mensen daarbuiten – testautomatisering een belangrijk, zo niet onmisbaar onderdeel vindt van het softwareontwikkelproces zodra men volgens Agile principes gaat werken. Echter, zodra er ook maar iets van tijdsdruk of uitloop om de hoek komt kijken, is testautomatisering ook het eerste dat van de wagen valt.
Testautomatisering onderbrengen in de Definition of Done (DoD) is dan een voor de hand liggende manier om te borgen dat er ook daadwerkelijk voldoende aandacht aan besteed wordt gedurende de sprint. Het opzetten en onderhouden van geautomatiseerde tests is nu eenmaal een software-ontwikkelactiviteit op zich en niet iets dat je er af en toe even ‘bij doet’ als je niks beter te doen hebt.
Maar hoe je dan precies testautomatisering onderdeel maakt van je DoD, daar worstelen veel teams nog mee. In dit artikel wil ik dan ook een paar tips en trucs geven om testautomatisering op een bruikbare manier een plek te geven in je DoD.
Het belangrijkste om je te realiseren wanneer je met een Definition of Done aan de slag gaat, is het volgende:
Testautomatisering is een middel, geen doel op zich!
Ik heb het maar even dik gedrukt, want met de huidige focus van veel test- en ontwikkelteams op de invoering van testautomatisering lijken we dit nog wel eens te vergeten… Bedenk altijd dat:
- Het doel is om waardevolle en bruikbare software op te leveren als ontwikkelteam.
- Geen enkele klant of eindgebruiker je betaalt voor de geautomatiseerde tests die je als team hebt gemaakt. Het eindproduct levert die waarde.
- Testautomatisering je helpt om gecontroleerd met een bepaalde gecontroleerde snelheid (de velocity) software met een bepaald basisniveau van kwaliteit op te leveren. Geautomatiseerde tests kunnen veel, maar lang niet alles.
Veel statements die ik in een DoD lees en die betrekking hebben op testautomatisering, maken geautomatiseerde tests echter een doel op zich. Even een paar voorbeelden:
‘Voor elke opgeleverde feature moeten geautomatiseerde tests geschreven zijn’
Statements zoals deze roepen bij mij meteen de vraag ‘Echt waar? Waarom dan?’ op. Soms weet je al bij het opleveren van een feature dat deze in komende sprints nog grondig verbouwd gaat worden of misschien zelfs wel weer wordt verwijderd. Levert de extra investering die het schrijven van geautomatiseerde tests met zich meebrengt wel voldoende op? Vergeet hierbij ook het onderhoud van die scripts niet!
Er zijn ook genoeg voorbeelden van features die wel waarde leveren, maar die zich niet of niet eenvoudig lenen voor testautomatisering. Wijzigingen in de infrastructuur. Implementeren van logging en monitoring. Verbeteren van de gebruiksvriendelijkheid. En ga zo maar door…
Mijn punt is: wanneer je bovenstaande punt, of iets soortgelijks, opneemt in je DoD, wordt testautomatisering een doel op zich en niet een middel om een hoger doel mogelijk te maken. Natuurlijk is het een goed idee om voor belangrijke functies een kwalitatief goede set van geautomatiseerde tests te hebben. En ja, daar moet je tijd voor plannen. Maar er zijn meer en in mijn ogen betere manieren om dit te bereiken.
Bespreek de noodzaak van geautomatiseerde tests bijvoorbeeld tijdens een refinement-sessie en maak er vervolgens tijdens de sprintplanning een taak voor aan. Neem een statement als ‘Er zijn geautomatiseerde tests geschreven voor de feature, tenzij het team het er over eens is dat dit niet noodzakelijk is’ op in je DoD om ervoor te zorgen dat dit wordt nageleefd.
‘De bij de features behorende unit-tests hebben een code coverage-percentage van x %‘
Ook hier geldt dat een dergelijk statement testautomatisering tot doel verheft, terwijl het alleen maar een middel is om een ander, hoger doel eenvoudiger te bereiken. Toch zie ik nog vaak dat teams (of managers) waarde hechten aan een bepaald code coverage-percentage. Vaak met als enige achterliggende reden dat zo’n percentage eenvoudig te meten is en er makkelijk op te sturen valt.
Maar bedenk wel dat code coverage op zichzelf helemaal niets zegt over wat er nu eigenlijk wordt getest of over de kwaliteit van de tests. Het enige dat deze metriek zegt, is hoeveel code er is uitgevoerd tijdens het uitvoeren van de testsuite. Het is (theoretisch, al heb ik het helaas ook in de praktijk wel zien gebeuren…) mogelijk om 100% code coverage te halen zonder een enkele check of assertion aan je tests toe te voegen. Er wordt dus wel code uitgevoerd, maar geen enkele keer wordt een uitkomst vergeleken met een verwachte waarde en dat is nou net het belangrijkste onderdeel van een geautomatiseerde test!
De enige echt waardevolle informatie die een metriek als code coverage geeft, is het inzicht in welke onderdelen van de code nog niet door tests worden geraakt. Het opnemen van een specifiek code coverage-percentage in je DoD, of een vergelijkbare metriek, zoals het aantal geraakte paden, alleen is naar mijn mening dan ook geen goed idee. Tip: als je toch echt iets over de kwaliteit van je (unit-)tests in je DoD wilt opnemen, kijk dan eens naar een techniek als mutation testing.
Samenvattend
Ja, natuurlijk is het een goed idee om in je DoD plek in te ruimen voor testautomatisering. Ik zie te vaak gebeuren dat testautomatisering ‘vergeten’ wordt, of dat er onder tijdsdruk uiteindelijk niet genoeg tijd voor vrij gemaakt wordt onder druk van deadlines, terwijl iedereen maar blijft roepen dat testautomatisering zo belangrijk is…
Vastleggen in de DoD is een goede manier om de juiste aandacht te blijven geven aan testautomatisering, maar blijf je realiseren wat het doel is van een user story en van een sprint. Testautomatisering is een middel om dat doel op een efficiënte manier te bereiken en aan kwaliteitsborging te doen, maar het mag nooit een doel op zich zijn. Wat wil je bereikt hebben aan het einde van je sprint?