De afgelopen tijd heb ik in een opdracht collega’s mogen adviseren over de positieve impact van het Test Automation Framework BDD rondom het thema Agile. In een vorige blog ‘Transformation’ is te lezen wat BDD voor mij betekent en hoe BDD voor synergie zorgt tussen verschillende disciplines binnen Agile-teams met als doel het leveren van kwalitatief hoogwaardig software aan de eindgebruiker.
Toch zie ik dat er binnen Agile projecten nog steeds veel onnodige (saaie) “manuele testen” worden uitgevoerd. Waarom? Mijn advies is om het anders aan te pakken! Los van het feit dat manueel testen tijdrovend en arbeidsintensief is, zorgt het ook voor vertraging van test feedback door sommige complexe onderdelen. Deze vertraging is nou precies wat je als team en organisatie niet wilt hebben. Het team is onnodig druk en daardoor vaak in stress, zeker als op het laatste moment van de sprint nog bugs gefixed en hertest moet worden. Daarnaast kost dit verschijnsel ook simpelweg onnodig veel geld. Testautomatisering is het middel dat op lange termijn zowel de Business als het Development Team hierbij kan helpen. Een win-win situatie!
Wat is de toegevoegde waarde van testautomatisering voor mij?
Binnen Agile projecten is het ontzettend belangrijk dat testautomatisering een integraal onderdeel van het Agile project is. Met name wanneer je vertraging van test feedback en tijd- en geldverspilling wilt voorkomen. Daarnaast is het primaire doel van testers/testautomatisering om de kwaliteit van het product te bevorderen (Agile/BDD mindset). Om dit te kunnen bereiken hebben we tijd nodig om de structuur en intelligentie van testen op een betrouwbare manier in te richten. Echter, het is wel belangrijk om dit met de nodige snelheid en focus te realiseren. Zeker als er sprake is van een twee wekelijkse release naar productie. Er is gewoon weinig tot geen tijd en energie om elke iteratie manueel te testen. En zelfs, mochten we die tijd wel hebben, wij testers blijven mensen en mensen maken fouten. Laten we daarom slim zijn en in ieder geval het vele repetitieve werk overdragen aan machines. Hierbij zijn de drie centrale kwaliteitsattributen leesbaarheid, herbruikbaarheid en onderhoudbaarheid de sleutel. Graag sta ik hierna even stil bij hoe ik dit zou aanpakken.
Selecteer een framework wat het beste binnen het Agile project past: SpecFlow, Cucumber, Behat, JBehave etc.
Na installatie van de betreffende framework kunnen we al meteen starten met het schrijven van de Feature Files, welk bestaan uit scenario’s en steps. Met behulp van Step Definitions leggen we de connectie tussen de Feature File en Applicatie Interface. Door een extra laag tussen de Step Definitions en de Applicatie te plaatsen, kunnen we de applicatie elementen op één plek onderhouden en beheren. Het is nu een teamverantwoordelijkheid om het Test Automation Framework BDD correct te implementeren!
Een feature file is een plain text format die een stuk functionaliteit beschrijft in de taal van de Business, ook wel Domain Specific Language (DSL) genoemd. Het doel van een feature file is enerzijds het creëren van een levende documentatie die ook voor de Business begrijpelijk is en anderzijds het automatiseren van je acceptatie criteria die in de user story staan beschreven. Op basis van je acceptatie criteria worden de testscenario’s in de feature file door middel van “Given-When-Then” steps geautomatiseerd.Feature Files
Hoe ziet de relatie tussen user story en testscenario binnen BDD eruit?
De feature file nodigt in dit geval de Business uit voor communicatie. Tip: wees er wel van bewust dat de scenario’s in plaats van imperatief juist declaratief geprogrammeerd moeten worden. Het verschil tussen deze twee is dat je bij imperatief programmeren door middel van acties de programmatuur de opdracht geeft wat er moet gebeuren, terwijl je bij declaratief programmeren juist aangeeft wat het resultaat moet zijn. Door declaratief te programmeren kom je snel tot de kern van de zaak. Daarnaast zijn je testscenario’s veel meer overzichtelijker, leesbaarder en herbruikbaar.
Step Definitions
Step Definitions is een methode die gedefinieerd is in een willekeurige programmeertaal. De teststeps vanuit de feature file worden direct gemapt in je Step Definitions (Glue Code). Dit vormt dan een connectie tussen je feature file en applicatie interface. Step Definitions kunnen resulteren tot de volgende statussen: Succesvol, in afwachting, onbepaald of gefaald. Status in afwachting, onbepaald of gefaald houdt in dat je als tester nog werkt te doen hebt. Wel is het een mooie reminder vanuit het framework om de test volledig te maken. Vanuit de applicatie zoeken we elementen op en voeren we waarden in om de feature file succesvol te maken. Waar men wel voor moet waken is dat testscenario’s op lange termijn groeien. Wanneer je hetzelfde element op meerdere plekken in de code gaat gebruiken, dan kan dat heel zwaar worden. Zodra dat element om welk redenen dan ook in het Agile project wijzigt, dan moet je als tester veel mini changes in je code uitvoeren om de testscenario’s werkend te krijgen. Dit is tijdrovend en leidt tot meer foutgevoeligheid! Mijn advies is om Page Object Models (POM) in het Agile project te gebruiken. Ik weet zeker dat dit tot een veel betere aanpak leidt.
Page Object Models
Een Page Object Model (POM) is een separate file class waarin de elementen van de applicatie te vinden zijn en waar deze gevalideerd kunnen worden. Alle gebruikers-interacties worden op één pagina gedefinieerd. Zodra een wijziging plaatsvindt in het Agile project, dan kan de wijziging op één plek in de code doorgevoerd worden in plaats van op meerdere plekken. Page Object Models stimuleert leesbaarheid, herbruikbaarheid en onderhoudbaarheid van je Glue Code met als doel het verminderen van het optreden van onzekere gebeurtenissen. Dit is waar het om programmeren en testen om draait. Toch?
Mocht je vragen hebben of iets anders willen opmerken? Graag, dat kan hieronder. Ik hoop dat je het interessant vond.
תגובות