Spelenderwijs Agile testen!

Auteur: Sanne Müskens ● sanne.muskens@bartosz.nl ● @SanneMuskens
Op woensdag 10 juli vond de TestNet Summer School plaats in het NBC te Nieuwegein. Als hoofdsponsor van TestNet én ervaren Agile testpartij organiseerde Bartosz de workshop The Agile Test! Competitie, fun en ervaringen uitwisselen met Agile testen.
In totaal hadden 25 Agile testers zich opgegeven voor deze workshop, allen zeer ervaren tester(manager)s met tot vier jaar specifieke ervaring in Agile testen bij verschillende bedrijven in uiteenlopende branches, zoals financiële dienstverlening, overheid en telecom.
Game en Quiz
We starten met een leuke game om op te warmen, genaamd ‘Woosh Boing Pow’, verzorgd door Anil Ramautar. Een hilarisch tafereel waarbij kernaspecten van Agile zoals omgaan met veranderingen, snel reageren en samenwerken, de rode draad vormen van deze game. Daarna beginnen we met de quiz waarin de ervaringen van de deelnemers die zij hebben met Agile testen, centraal staan. De quiz bestaat uit twee ronden met steeds vier vragen, waarbij er geen goed of fout antwoord is; de doelstelling is om de deelnemers met elkaar in discussie te laten gaan en van elkaar te leren over de verschillende onderwerpen, alle betrekking hebbend op Agile testen. Uitgangspunt hierbij is dat de deelnemers hun ervaringen inbrengen en niet alleen hun mening.
Agile en Product Risico Analyse
De eerste ronde heeft als thema Product Risico Analyse (PRA) in een Agile omgeving. Er zijn vier vragen geformuleerd die gaan over het gebruik en de toepassing van PRA binnen Agile. Zo is er een vraag over wanneer het juiste moment is om een PRA uit te voeren. De meeste deelnemers zijn het erover eens dat het beste moment om een PRA uit te voeren de Sprint Planningsbijeenkomst is. Je schat dan met het hele ontwikkelteam het ontwikkel- en testwerk voor de komende sprint. Maar er zijn ook deelnemers die van mening zijn dat de PRA moet plaatsvinden tijdens de Sprint Review, omdat hier business afgevaardigden en Scrum Team leden aanwezig zijn die tezamen heel goed impact en faalkans van toekomstige User Stories kunnen inschatten. Een PRA toepassen gedurende Sprint Nul wordt ook genoemd. Ook al is dit geen formele Scrum gelegenheid, dit is volgens enkele deelnemers wel hét moment om stil te staan bij productrisico’s. Er ontstaat naar aanleiding van deze eerste quizvraag consensus over het feit dat je de PRA op meerdere momenten zou moeten toepassen. Bijvoorbeeld een generale PRA in Sprint Nul en daarna per sprint een PRA voor de eventuele aanpassingen.
De tweede vraag gaat over wie een Product Risico Analyse uitvoert in een Scrum context. Het overgrote deel van de groep vindt dat de Product Owner hiervoor verantwoordelijk is. Hij is vanuit zijn rol in staat om zowel met de business als met het ontwikkelteam te schakelen. Dit moet dan echter wel worden gecombineerd met iemand uit het ontwikkelteam, liefst een tester, want het is immers zijn vakgebied. Echter, ook een aantal deelnemers vindt dat de Testmanager de PRA dient uit te voeren in een Scrum context. De Testmanager is namelijk de meest neutrale persoon. Andere zijn het daar niet mee eens, omdat de Testmanager vaak inhoudelijk niet voldoende weet.
De derde vraag van de eerste quizronde gaat over wat een Agile PRA is. Het overgrote deel van de deelnemers vindt dat een Agile PRA meer is dan een klassieke PRA, omdat het input betreft voor het hele ontwikkelteam. Ook ontwikkelaars immers gebruiken de uitkomsten van de PRA om beslissingen op te baseren. Het andere deel van de groep zegt juist dat een Agile PRA niet anders is dan een klassieke PRA. Want er is toch ook geen RUP PRA? Zij zijn het er dus niet mee eens dat een Agile PRA meer is dan een klassieke PRA.
De laatste vraag stelt aan de orde waarvoor de uitkomsten van een Agile PRA gebruikt worden door de tester. Vrijwel iedereen geeft aan dat de uitkomsten worden gebruikt om de diepgang van het testen te bepalen waardoor de Story Points beter  kunnen worden ingeschat. Maar daarnaast zijn de uitkomsten van een Agile PRA ook belangrijk voor het bepalen waar nadruk op gelegd moet worden in regressietesten. Iedereen is het er in ieder geval over eens dat de uitkomsten van een PRA niet gebruikt worden om te kunnen aantonen dat een tester zijn werk goed heeft gedaan.
‘Tegeltjeswijsheden’
Na deze veel bediscussieerde vragen krijgen de deelnemers de opdracht om in groepen hun eigen tegeltjeswijsheid te maken over PRA in Agile. De ultieme ervaring, oftewel het beste advies, om op een tegeltje te plaatsen, een spreuk over PRA die nuttig is voor iedere Agile tester. De deelnemers laten hun creatieve kant zien en komen met wijsheden zoals ‘Eerst een PRA, de sprint komt er na’, ‘Met de PRA goed verwerkt, blijven de (sprint) kosten beperkt’, ‘Voorkomen is beter dan genezen’ en ‘Communicatie is belangrijker dan de vorm’.

Chair Game
Na de pauze neemt Anil het roer weer over voor een ‘Energizer’ in de vorm van een tweede Agile game. Dit keer de Chair Game! De deelnemers worden verdeeld in drie (Scrum)groepen en iedere groep krijgt een opdracht die in meerdere sprints moet worden uitgevoerd. De belangrijkste spelregel is dat de groepen niet mogen communiceren en dat zorgt ervoor dat de stoelen letterlijk door de ruimte vliegen! Uiteindelijk slaagt de groep er toch in om, binnen drie kleine sprints, tot een gezamenlijk plan te komen en door samenwerken de sprintdoelen te bereiken.

Agile en Testtechnieken
Snel door met de tweede quizronde, dit keer over testtechnieken binnen Agile. Vraag één gaat over ‘Working Software over Comprehensive Documentation’. Dit is een van de uitgangspunten van het Agile Manifesto. Aangaande documentatie zijn de deelnemers het er redelijk over eens dat een testset de opgeleverde functionaliteit zó goed beschrijft dat er verder geen documentatie meer nodig is. Zo geeft een deelnemer als voorbeeld dat de testtool Fitnesse gebruikt wordt voor het vastleggen van de requirements én de testcases als enige documentatiemiddel. Een ander deel van de groep vindt dat een testtechniek prima kan worden toegepast op basis van vooraf opgestelde acceptatiecriteria en met behulp van interviews. Vaak is er sprake van druk, er is geen documentatie voor handen, maar de deadline moet gehaald worden. Dan moet een tester wel de opgestelde acceptatiecriteria als basis gebruiken.
De tweede vraag gaat over statische testtechnieken binnen Agile. Op basis van de ervaringen van de deelnemers kan (grotendeels) gesteld worden dat testers deze testtechnieken elke dag gebruiken. Het is de enige testtechniek die vroegtijdig fouten vindt. Als tester ben je elke dag bezig met de kwaliteit van je applicatie en dus met statische testtechnieken. Een ander gedeelte van de groep zegt dat een tester alleen de statische testtechnieken gebruikt om de hoofdlijnen van de requirements en architectuur te toetsen. Testtechnieken worden niet iedere dag gebruikt, tenminste niet in de meeste projecten. In ieder geval is de hele groep het er over eens dat het niet zo is dat de tester er niets mee doet en dat de statische testtechnieken geen toegevoegde waarden zouden hebben voor testers.
Bij de derde vraag, die een aantal algemene stellingen omvat over testtechnieken binnen Agile, zijn de meningen redelijk verdeeld. Een groot aantal geeft aan testtechnieken toe te passen aan de hand van de uitkomsten van de PRA, net zoals dat in een waterval project zou gebeuren. Een vijftal deelnemers zouden het liefst de testtechnieken geautomatiseerd willen toepassen door middels van een tool. Model Based testen binnen Agile heeft volgens hen een mooie toekomst. Een zestal zegt testtechnieken slechts incidenteel in te zetten, om bijvoorbeeld een belangrijke berekening volledig door te kunnen testen. Maar ook zeggen een paar testers dat formele testtechnieken geen waarde hebben binnen Agile. Op basis van hun ervaring kunnen ze bepalen welke testen nodig zijn. Deze vraag zorgt dus voor discussie en er zijn grote verschillen in hoe de deelnemers hierover denken.
Bij de laatste vraag worden vier uitspraken gedaan over de inzet van ketentesten als Agile tester. Hoe doen de deelnemers dit? De meeste geven aan dit vanaf de eerste sprint te doen. Zij zeggen de ketentest stap voor stap op te bouwen en deze is onderdeel van de regressietest in elke sprint. Een andere groep deelnemers vindt dat de ketentest niet moet worden ingezet door testers in de sprints. Dit is namelijk het feestje van de overall Testmanager, die verantwoordelijk is voor het testen van de integratie van de hele keten.
Lessons Learned
De workshop wordt afgesloten met een opdracht aan de deelnemers om naar aanleiding van de vragen over testtechnieken in groepjes de ‘Lessons Learned’ op te schrijven. Dit wordt wederom gedaan op basis van de ervaringen van de deelnemers en de tips die zij willen meegeven. De belangrijkste positieve ervaringen zijn verzameld op flipover vellen:

• Testtechnieken moeten altijd blijven worden toegepast, ook in Agile;
• Testexpertise en testexperts zijn essentieel bij Scrum;
• Bij Exploratory Testing zijn testtechnieken een goede aanvulling op de bestaande testtechnieken;
• Bij Agile word je als tester vanaf het begin betrokken;
• Testtechnieken hebben een belangrijke plaats, er zijn vele wegen die naar Rome leiden, door goed communiceren kan men de juiste weg kiezen;
• De dekkingsgraad kan beter  worden beheerst met testtechnieken;
• Statische testtechnieken kunnen gebruikt worden om te reviewen en bij Backlog Grooming;
• Exploratory Testing en Error Guessing zijn goed toepasbaar tijdens de sprints.

Negatieve ervaringen die de deelnemers hebben benoemd bij de ‘Lessons Learned’ zijn:

• Testtechnieken kosten veel tijd en vaak  is er sprake van snel testen zonder dat  de risico’s echt worden afgedekt;
• Met uitgebreide testtechnieken is het lastig om te communiceren;
• Het toepassen van Scrum in een watervalorganisatie blijft erg moeilijk;
• Ketentesten zijn complex in een Agile organisatie;
• Het nut of de noodzaak van testtechnieken in de perceptie van de bouwer is meestal negatief;
• Tijdens een sprint is er voor testers vaak (te) weinig tijd om op basis van een testtechniek tot een echt goede uitwerking te komen;
• User Stories geven niet altijd voldoende informatie om te dienen als goede input voor een testtechniek;
• Vaak wordt er niet aan vastlegging gedaan waardoor men bij sommige testtechnieken niet weet hoe er getest moet worden;
• Het onderhouden van testtechnieken kost veel tijd en energie.

Geslaagde test over Agile testen
Wij vonden het een geslaagde, succesvolle en vooral leerzame avond. Spelenderwijs hebben we ervaringen uitgewisseld en van elkaar geleerd door het doen van een test over Agile testen. We bedanken de deelnemers voor hun inzet en TestNet voor de organisatie van de Summer School. Wij kijken uit naar volgend jaar, tot dan!
Deze workshop is mede mogelijk gemaakt door Joost van Haarlem, Rob den Broeder, Anil Ramautar, René Bliekendaal, Petra Heesink, Robert Lourens, René Getkate, Norbert Kerkdijk en Sanne Müskens van Bartosz ICT.