Het nieuwe testen

Uit de veranderkunde kennen we 2 redenen waarom mensen willen veranderen: als het oude gedrag erg pijn doet, of als het nieuwe gedrag veel plezier oplevert. Vaak is de verandering gedreven door  een combinatie van beide motivatoren: afscheid van het oude en verwachtingen van het nieuwe. In het testvak hebben we ook een leuke uitdaging voor de boeg: aansluiten bij de wens van veel organisaties om agile te gaan implementeren. In deze column ga ik in op hoe agile testen met traditionele ‘spoken’  afrekent en welke voordelen dit nieuwe testen met zich meebrengt.

Afrekenen met spoken
Uiteraard ben ik ook gewoon begonnen in traditionele testprojecten. Alhoewel… mijn eerste project in 1997 was millennium testen bij een bank en daar had men wel werkende systemen  in productie, maar geen begeleidende systeemdocumentatie. Komt je dat bekend voor…?   Maar ook in keurige V-model trajecten liepen we tegen de beperkingen van de geldende testmethodes aan. Die methodes schreven voor dat het testen onafhankelijk en objectief moest gebeuren, dat het na het ontwerpen en bouwen gepositioneerd werd en een aparte testmanager de  kwaliteit van het product en het testproces waarborgde. Maar in de praktijk waren er de nodige problemen : er was veel miscommunicatie tussen ontwerp, bouw en test, het testen bevond zich op het kritieke pad  en de klant schrok tijdens de Acceptatietest nog wel eens van het product dat hij opgeleverd kreeg. Gesprekken op TestNet avonden leiden al snel tot de conclusie dat deze ‘spoken’  generiek waren: veel testprojecten hadden er in meer of mindere mate last van. 

Bruggen bouwen
Al snel heb je dan door dat communicatie in alle gevallen centraal staat: met je team, met de projectleider en met de klant. Dus ga je bruggen gaan bouwen met ontwerpers en ontwikkelaars. De ontwerpers bepalen jouw specificaties en zoals een duidelijke uitspraak van testgoeroe Boris Beizer vaststelt: “The design isn’t done until the test cases are ready”. Door vanuit het testen input te leveren op de specificaties wordt het een beter uitgedacht en beter testbaar systeem.  Eerlijk gezegd heb ik dat zelden succesvol gedaan door aanspraak te maken op de teststrategie en te claimen dat wij testers hun documenten mochten reviewen. Wat ik wel deed was in een goed gesprek de voordelen voor beide partijen benadrukken en de risico’s te benoemen van het niet reviewen.  In een  dialoog bereik je immers veel meer als je dat insteekt vanuit een gezamenlijk belang.

Tussenopleveringen
Ontwikkelaars hebben code die jij moet testen en zij baseren zich op dezelfde specificaties. Dus als je samenwerkt kan je enerzijds meer leren over hoe zij de specs interpreteren en anderzijds kun je hen sneller feedback geven op de werking van hun code. Als tester geef je immers inzicht in de kwaliteit en daadwerkelijke voortgang van het project. Zo heb ik als testcoördinator regelmatig om tussenopleveringen gevraagd, ook als die tussenopleveringen geen onderdeel waren van de projectplanning. Op die manier konden er al tests worden uitgevoerd  en hadden we  meer grip op de opgeleverde kwaliteit.

Klantinteractie
En als de klant constateert dat het product dat je oplevert niet het product is dat hij nodig heeft, dan blijkt die relatieve “rust”  tijdens een software ontwikkel traject waarin je bouwt en test en waarin geen interactie met de klant hebt, dus een verloren moment om te verbeteren. Dan blijkt dus dat je veel beter ook tijdens die fasen op zoek moet naar interactie momenten . Om scherp te stellen, verwachtingen te managen en vooral: de communicatie op gang houden. Zelfs zonder dat je functionele wijzigingen toestaat kun je wel degelijk de acceptatiegraad verhogen tijdens een traditioneel project.  Door de klant te laten meekijken (met aangepaste verwachtingen!) tijdens de systeemtest bijvoorbeeld. Zij krijgen inzicht, jij krijgt feedback. Het aanleggen van een breedband communicatiekanaal met de klant is essentieel als je als team succesvol wilt zijn.
Wanneer je vervolgens je realiseert dat het beheersen van deze risico’s, deze traditionele testspoken, in centraal staan in een nieuwe aanpak  genaamd agile software ontwikkeling dan ben je, net als ik, snel om!

Genieten van het nieuwe
Los van het oplossen van oude problemen, biedt agile testen ook nieuwe voordelen voor testers. Het belangrijkste verschil dat ik in de praktijk van agile projecten ervaar is dat het multidisciplinaire team een commitment aangaat met betrekking tot het opleveren van een kwaliteitsproduct. Dat gaat dan om de Definition of Done – de definitie van de exitcriteria van de iteratie. Daarin staat opgesomd wat het team van zichzelf vindt dat het werkend moet opleveren en uiteraard wat de klant verwacht. Die criteria kunnen variëren van dekkingsgraad op de unittest tot en met een installatiehandleiding. Met dat commitment ontstaat er een gezamenlijke verantwoordelijkheid om een goed product op te leveren.

Van functie naar rol
Als tester betekent dit concreet dat jouw functie meer een rol wordt: iedereen in het team test op enig moment als onderdeel van zijn eigen werkzaamheden. Dat betekent dat jouw rol er een wordt van kennisdeler (testtechnieken, testgevallen),  coördinator (teststrategie, testsoorten) en communicator (klant). Deze gedeelde verantwoordelijkheid voor testen en kwaliteit is iets wat in de traditionele context slechts zelden ontstond doordat de fasen en activiteiten gescheiden waren. Het gevolg is echter dat testen nu eindelijk de rol speelt die wij als testers altijd al hoopten: als integraal onderdeel van de softwareontwikkeling, waarde toevoegend bij iedere stap in het proces.

Paradigma verandering
Voor veel testers betekent dit nogal een paradigma verandering: in plaats van je verantwoordelijkheid nemen voor testen, moet je deze vooral gaan delen met niet-testers. Dat betekent dat je meer op de ander gericht  moet zijn. Je zult met je teamleden moeten praten over testen en bespreken hoe testen voor hen waarde toevoegt. Ik heb er veel met niet-testers over gepraat en testen is voor hen maar één ding: feedback! Simpelweg zeker weten aan welke eisen het resultaat van de handeling moet gaan voldoen en het testen of dat inderdaad ook zo is. Daarbij maakt het niet uit of het om requirements gaat (AcceptanceTDD – acceptatietests vooraf schrijven) of om code (Test Driven Development). Testen is zeker weten!

Mindset
Wanneer jij je teamleden gaat helpen met testen dan stelt dat eisen aan jouw communicatieve vaardigheden, maar vooral om jouw mindset! Kun je multidisciplinair denken? Ben je bereid na te denken over testen met ontwerpers, ontwikkelaars en met de klant? Ben je daartoe in staat en kun je ze duidelijk maken wat ze missen als ze niet goed testen? En uiteraard moet dat niet vanuit een arrogante houding, maar als die een van een medespeler uit het team: je werkt samen!

Ik hoop dat ik een tip van de sluier rondom de mogelijkheden van agile testen heb kunnen oplichten. Het helpt je om traditionele problemen te tackelen en biedt kansen voor aanzienlijke verbeteringen als het gaat om testen een integraal  en gewaardeerd onderdeel van systeemontwikkeling te laten zijn.  Doe jij mee of toch nog niet? Vertel hieronder waarom!

———————————–
Anko Tijman is werkzaam bij Ordina als testconsultant en Partner Agile Testen.