Vaak wordt geroepen dat testautomatisering binnen een Agile project een onmogelijkheid is. Testautomatisering vergt immers een stabiel systeem, zo is het credo. De kritiek daarbij is dat bij iedere sprint nieuwe functionaliteiten toegevoegd worden, bugs gerepareerd worden en dat het aan het begin van een sprint niet duidelijk is waar het eindigt. Volgens ons kunnen (grote) Agile projecten echter niet zonder testautomatisering.
Om de stelling, dat testautomatisering in een Agile omgeving veel voordelen heeft, te onderbouwen is het belangrijk eerst de toegevoegde waarde van testautomatisering te onderkennen. Stel er is een Agile ontwikkeltraject dat bestaat uit vier sprints van twee weken waarin telkens eenzelfde hoeveelheid (nieuwe) testgevallen wordt opgeleverd. Tijdens de eerste sprint worden 25 handmatige testgevallen ontwikkeld en uitgevoerd. Tijdens de volgende sprint worden weer 25 nieuwe handmatige testgevallen ontwikkeld, waardoor het totale aantal handmatige testgevallen nu op vijftig staat. Wanneer we deze trend doorzetten moeten er in de laatste sprint honderd testgevallen uitgevoerd worden in een periode van twee weken. Hiervan zijn 75 testgevallen regressief van aard.
Uit bovenstaand voorbeeld wordt meteen duidelijk dat de testgevallen t.b.v. regressietesten een steeds groter deel van de tijd in beslag zullen nemen. Men wil immers voorkomen dat ontwikkelde functionaliteit uit eerdere sprints ‘omvalt’ door toevoegingen of wijzigingen op het systeem. Dit is waar de juiste inzet van testautomatisering volgens ons het verschil kan maken. Bijkomend voordeel is dat vroegtijdig over de regressie testset wordt nagedacht, iets waar regressietesten anders nog wel eens “later in het project een keer gedaan wordt” en daarmee het risico loopt een goedbedoelde ambitie in plaats van een realiteit te worden.
Team effort
Organisaties die kiezen voor testautomatisering binnen een Agile project worstelen doorgaans met de positie ervan. De initiële opzet kost namelijk tijd die ook besteed had kunnen worden om nieuwe functionaliteit te realiseren. Vaak wordt ervoor gekozen om regressietesten buiten de sprints te trekken. De onderbouwing hiervoor is dat het sprintteam zich hierdoor kan richten op nieuwe functionaliteit en geen kennis hoeft op te bouwen rondom testautomatisering. Door het te plaatsen bij een gescheiden afdeling wordt het werk immers wel gedaan, maar is het geen verantwoordelijkheid van het sprintteam.
Wij zijn van mening dat dit niet binnen de Agile richtlijnen past. Wij opteren voor een testautomatiseringstrategie die gericht is op de beschikbaarheid van een voldoende technisch onderlegde tester (of ontwikkelaar met testkennis) binnen het sprintteam. Deze tester zal zich bezig houden met de user stories die gericht zijn op de geautomatiseerde tests. Daarnaast zal hij volgens de Agile filosofie ook overige user stories toebedeeld kunnen krijgen.
Binnen omvangrijke Agile trajecten kan echter ook gekozen worden voor het uitwerken van een aparte user story ten aanzien van de testautomatisering. Indien nodig kan een andere sprintmedewerker, zoals een ontwikkelaar of informatieanalist, bijspringen om de werklast binnen de gestelde tijdskaders af te ronden. De eindverantwoordelijkheid van de geautomatiseerde regressietest blijft hiermee bij het hele team liggen.
Vroeg starten
De geschetste voordelen kunnen eenvoudiger worden gerealiseerd wanneer gebruik gemaakt wordt van een automatiseringsaanpak die al begint vóór het schrijven van het eerste testgeval. Door een 'sprint 0' te introduceren waarin voorbereidende werkzaamheden uitgevoerd worden met betrekking tot architectuur en testautomatisering kan een zeer solide basis voor alle toekomstige sprints worden gelegd. In plaats van te wachten tot de handmatige testgevallen gereed zijn voor automatisering dient geen verschil meer te worden gemaakt tussen handmatige en geautomatiseerde testgevallen: elk testgeval kan zowel geautomatiseerd als handmatig uitgevoerd worden, afhankelijk van de staat en mogelijkheden van het systeem. Dit kan gerealiseerd worden door de testgevallen altijd op te delen in herbruikbare acties. Deze gegroepeerde acties zorgen voor herbruikbaarheid, snelheid en uniformiteit in de opbouw van de testgevallen. Wanneer het testgeval wordt opgesteld kan de tester immers putten uit de reeds beschikbare acties.
Een ander bijkomend voordeel van de geschetste aanpak is dat na afloop van de laatste sprint al een grote hoeveelheid (regressie)testgevallen geautomatiseerd klaar staat. Hierdoor hoeft de beheer- of testafdeling minder tijd te investeren in het opzetten van een (geautomatiseerde) regressietest. In de beheerfase kan nu meteen de aandacht worden gelegd op het onderhouden van het systeem zelf. Wijzigingen op het systeem, door bijvoorbeeld RFC's of bug-fixes, kunnen daarbij sneller worden geïmplementeerd en met beperkt risico in gebruik genomen worden. De regressieset is immers voor een groot deel al klaar bij oplevering van het systeem. In een business case ten aanzien van testautomatisering zal dit punt dan ook zeker meegenomen moeten worden ter onderbouwing.
Tot slot…
We hebben ervaren dat bij het bepalen van de aanpak een aantal factoren van groot belang zijn. De inrichting van de testactiviteiten binnen de sprint, teamsamenstelling en algemene testaanpak zijn hier belangrijke voorbeelden van. Vanzelfsprekend moeten ook een aantal algemene zaken zoals tooling en de keuze voor de specifieke testsoort bepaald worden. Deze keuzes behoren echter thuis in ieder test automatiseringstraject en staan daarom los van de Agile aanpak. De belangrijkste constatering is dat met de juiste opzet de synergie tussen Agile en testautomatisering mogelijk is. Testautomatisering in een Agile omgeving is daarmee geen onmogelijke werkelijkheid… het is realiteit!
(Computable-expert René de Jong heeft deze opinie geschreven in samenwerking met Bernd Schörgers, test specialist bij Identify).
Interessant en leuk artikel om te lezen.
Ik ben het eens met de constatering dat Testautomatisering en het hanteren van een Agile ontwikkelproces prima samen gaan. Sterker nog: naar mijn mening zijn automatisch tests een vereiste voor het succesvol uitvoeren van een Agile ontwikkeltraject.
De keuze voor een Agile project aanpak wordt namelijk gemaakt wanneer de requirements voorafgaand aan het project nog niet bekend zijn. Impliciet betekent dit dat zowel het design als de implementatie gedurende het project aan verandering onderhevig zijn. De enige manier om te garanderen dat bestaande features niet worden gewijzigd tijdens het implementeren van nieuwe features is het herhaaldelijk uitvoeren van geautomatiseerde regressie tests. Het inzetten van TDD i.c.m. met code coverage analyze helpt bovendien bij het creeren van focus op de ontwikkeling van regressie tests, aangezien deze in eerste instantie bedoeld zijn als progressie tests, en de vertaalslag naar de requirements van het software systeem.
Met vriendelijke groet,
Niels Brouwers.
Bij XP (Extreme programming is een Agile Ontwikkelings methode) is het zelfs verplicht. Of eigenlijk: De gehele XP/Agile methode bestaat uit: Test First principe.
Ik ben het eens met de qoute
“Wij zijn van mening dat dit niet binnen de Agile richtlijnen past. Wij opteren voor een testautomatiseringstrategie die gericht is op de beschikbaarheid van een voldoende technisch onderlegde tester (of ontwikkelaar met testkennis) binnen het sprintteam. Deze tester zal zich bezig houden met de user stories die gericht zijn op de geautomatiseerde tests. Daarnaast zal hij volgens de Agile filosofie ook overige user stories toebedeeld kunnen krijgen.”
Echter ik heb wel het gemerkt bij grote en kleine bedrijven die werken met SCRUM teams van beperkte omvang die maar een tester, die het functionele en het automatische moet uitvoeren, komt de testautomatisering als snel onder druk te staan. De tijd die gaat zitten in het automatisch testen voorbereiden en onderhouden gaat ten koste van het het lezen van de requirements v.d. functionele testcases en de uitvoering ervan. Als daarnaast de product owner zijn klanten tevreden moeten moet houden met het tijdig opleveren van (beloofde) requirements. De PO probeert dus zoveel mogelijk requirents in een sprint te te stoppen waardoor het automatisch testen nog meer onder druk komt te staan. Dus nog minder tijd om op een verantwoorde wijze testautomatisering.
Kiezen voor testautomatisering is dus een commitment.