De laatste jaren hebben we in rap tempo de markt om ons heen zien veranderen en kunnen zien dat wijzigingen elkaar steeds sneller opvolgen. De ene nog sneller dan de andere. Veel organisaties die volgens de traditionele watervalmethode ontwikkelen en testen, hebben moeite om deze wijzigingen bij te houden. Hierdoor verlopen dergelijke projecten nauwelijks nog volgens het boekje. Agile ontwikkelen en testen biedt hiertoe de mogelijkheid.
Agile testen maakt onderdeel uit van het Agile-ontwikkelproces. Deze methoden zoals bijvoorbeeld Scrum en RUP werken met multidisciplinaire teams, waar testen een integraal onderdeel van uitmaakt. Het uitgangspunt van een Agile-ontwikkelproces is om in een iteratie de ruwe vereisten verder uit te werken, de software te bouwen, testen voor te bereiden en uit te voeren. Ook werkt men aan documenten die de software ondersteunen. Deze activiteiten worden door het multidisciplinair team uitgevoerd, waarbij een ieder gefocust is op het eindproduct en kwaliteit een teamverantwoordelijkheid is.
Agile testen kent een aantal principes en waarden die betrekking hebben op de problemen uit het
traditioneel testproces. In een Agile-team heeft iedereen hetzelfde doel voor ogen: werkende software opleveren! Alle disciplines in het team, waar testen één van is, hebben een zichtbare toegevoegde waarde. De voornaamste toegevoegde waarde van testen is het geven van feedback, het liefst zo vroeg mogelijk. Vroeg betrokken zijn in een project heeft als voordelen:
• dat de tester de opgestelde vereisten SMART kan maken door te reviewen. Hierdoor zijn de criteria niet voor meerdere uitleg vatbaar en komen er minder vragen over de uiteindelijke werking van het systeem
• dat de tester inzicht krijgt in de risico's die hij op zijn pad kan tegenkomen
• dat de voorbereidingstijd lang genoeg is om alle testvoorbereidingen af te ronden voordat de testuitvoering begint.
Het zo vroeg mogelijk in een project betrokken worden is een voorwaarde voor een goede planning en een goede voorbereiding van het testtraject. Dit wordt ondersteund door vrijwel alle testliteratuur: we moeten er op tijd bij zijn.
Behalve er vroeg bij zijn, is ook de communicatie een belangrijk element. Vaak worden testers ervaren als lastig, tegendraads en kritisch over de producten. Dit terwijl ze allemaal hetzelfde doel zouden moeten nastreven: het leveren van een kwalitatief goed eindproduct. Blijkbaar kunnen de testers dit minder goed overbrengen en worden zij afgerekend op de kwaliteit van vorige opleveringen. Omdat het testteam communiceert vanuit hun eigen belevingswereld en geen zichtbare toegevoegde waarde laat zien worden ze gezien als lastig en contraproductief. Heldere en eenvoudige communicatie is in een multidisciplinair team daarom vereist. Het is hét smeermiddel om tot een goed resultaat te komen. Sub-groepjes binnen een team vormen een blokkade als het gaat om het realiseren van een goede communicatie. Daarom is het een must om alle disciplines in één ruimte te zetten en specifieke communicatiemomenten in te plannen. Denk aan de volgende communicatiemomenten:
• kick-off sessie aan het begin van een iteratie
• dagelijkse voortgangssessie
• evaluatiesessie aan het einde van een iteratie
Allen hebben het doel de communicatie in stand te houden en waar nodig de werkwijze te verbeteren.
Testen zonder case
Agile projecten worden vaak gezien als projecten waar geen testbasis voor is en waarbij geen documentatie gebruikt of geschreven wordt. Het tegendeel is echter waar. Documentatie maakt onderdeel uit van een oplevering. Gedurende de iteratie heeft de tester deze informatie nodig. Hij gaat hier achteraan en spreekt met de auteur(s). Aan het einde van een iteratie is er dus altijd up-to-date documentatie: precies dat wat de klant (gebruikers en beheerders) nodig heeft. Dit vereist een flexibele aanpak en houding.
De testbasis in een Agile-team bestaat uit meer dan de uitgangsdocumenten; de testbasis is alle informatie over het product die in het team aanwezig is. Deze informatie moet er zijn voor het starten van een iteratie. De gebruiker, de informatie analist, de ontwerper, de ontwikkelaar en de tester zorgen ervoor dat de informatie actueel is en blijft.
De voordelen van actuele informatie zijn:
• de testuitvoering kan goed worden voorbereid en is hierdoor effectief
• het team weet waar de grootste risico's zitten in het systeem en dus waar de meeste testinspanning aan besteed moet worden
• de planning is realistisch en betrouwbaar
• het vormt een goed verificatiemiddel in geval van afwijkingen
Bij agile productontwikkeling staan de gebruikers, of beter gezegd de klant, aan het roer; zij bepalen de koers van het project. Naast het feit dat een afgevaardigde onderdeel uitmaakt van het multidisciplinair team krijgen zij op afgesproken tijdstippen werkende software opgeleverd. Op die manier krijgen ze vroegtijdige feedback op hun ideeën en leveren zij op hun beurt input voor de volgende oplevering. Acceptatie wordt hierdoor sterk verbeterd, het is immers hun eigen product geworden. Door de iteratieve benadering staat het project toe dat er voortschrijdend inzicht ontstaat. Het is dus een gegeven dat men leert, het project is daarop ingericht.
Conclusie
Testen in een Agile-ontwikkelteam is geen aparte activiteit. De benodigde feedback wordt al zo vroeg mogelijk gegeven. Door middel van reviews op criteria, maar ook door al in een zeer vroeg stadium testgevallen uit te voeren. Zo vroeg mogelijk feedback geven, betekent ook een zo vroeg mogelijke betrokkenheid bij het project. Betrokkenheid houdt niet op bij het fysiek aanwezig zijn. Ook je betrokken voelen bij het project is van belang. Betrokken voelen en betrokken zijn vormt een goede basis voor de samenwerking die binnen een multidisciplinair team van groot belang is. Door een goede samenwerking kan iedereen elkaars werk goed aanvullen en waar nodig overnemen. Een Agile tester die zijn expertise deelt met zijn teamleden, stelt anderen daarmee in staat om zelf effectiever te testen. Als testers vroeg betrokken zijn in een Agile-team, betekent dat ook dat testen niet meer aan het einde van het project gebeurt en dus van het kritieke pad af is.
Brahim,
Testen = (gebruikers)documentatie. Wij (L&L) maken al jaren gebruikersdocumentatie (van traditioneel papier, online help, content voor (e-)learning) en ervaren nog veel te vaak dat testen en documentatie ondergeschoven zijn, ook in Agile-trajecten. Hebben daarom een training ontwikkeld die ontwikkelaars tips en trucks levert om snel goede en toegankelijke documentatie te maken in ontwikkeltrajecten. Er komt nog eens een tijd…
Wederom een goed artikel van Brahim. Alleen de functietitel ‘Agile tester’ blijft vreemd, omdat we niet anders (willen) werken dan in de tijd voor Agile een huishoudnaam werd of in huidige non-Agile omgevingen. Want als tester streef je er altijd naar om zo vroeg mogelijk betrokken te zijn, denk bij waterval maar aan een requirements check en statisch testen. Je wil zo kort mogelijk op je collega’s in andere disciplines zitten en samen werken, waarmee je ook meteen je vakmanschap kan delen. Het zal wel lekker bekken, maar ik prefereer toch gewoon ’tester in agile omgevingen’.
@Brahim: misschien je volgende stuk ‘Is Agile tester wel een functie?’. Ik ben benieuwd naar je mening c.q. conclusie.