Verslag Agile Testing Day Netherlands 2015

In vervolg op de succesvolle editie van vorig jaar organiseerden Diaz & Hilterscheid en KZA op 19 maart 2015 wederom de Agile Testing Day in Nederland. Het 15 uur durende evenement werd gehouden in Houten en is een spin-off van de Agile Testing Days in Potsdam (Duitsland). Op het podium stonden zowel internationale als nationale sprekers die zich bezig houden met Agile en testen vanuit een eindgebruikers-, coaching- of consultancy rol. De opening werd verzorgd door José Diaz (Diaz & Hilterscheid) en Joost van Haarlem (KZA). Agile groeit erg hard de laatste jaren en lijkt niet meer te stoppen. Dit heeft ook effect op testen. Joost vertelde dat vijf jaar geleden al werd gezegd dat testmanagers op den duur niet meer nodig zouden zijn. Lange tijd bleek die voorspelling niet uit te komen. Maar KZA heeft dit jaar nog geen enkele aanvraag gehad voor testmanagers. Dus het lijkt er op dat de testwereld de veranderingen niet meer uit de weg kan gaan. In het programma stond daarom de vraag centraal hoe we hier als testers mee kunnen en moeten omgaan. Hieronder een samenvatting van de presentaties.


Rachel Davies – Continuous Testing

Agile Testing Day Netherlands 2015 foto 2

Testen in Agile omgevingen voelt soms nog steeds als mini watervallen. Maar bij de klant waar Rachel nu werkt gebruiken ze Extreme Programming (XP). Binnen XP zijn er geen vastgelegde regels maar een aantal “Waardes”. Zoals het simpel houden, feedback geven, communiceren , moed tonen en respectvol zijn naar elkaar. XP zorgt er voor dat de software in een rustige gecontroleerde stroom op het team afkomt. Dit is dus niet het testteam, maar “het team”. We moeten echt een team worden en niet een aparte ontwikkelclub en testclub. Met Continuous Testing ontwikkelen en testen alle teamleden samen om snel kwalitatieve software op te leveren die ook echt van toegevoegde waarde is voor de business. Checks worden geautomatiseerd zodat het team zich kan richten op Exploratory Testing. Want handmatig testen blijft nodig omdat de checks geen resultaten kunnen interpreteren. Het team ontwikkelt bijvoorbeeld via Mobbing. Samen zitten voor een groot scherm programmeren en testen, terwijl om de tien minuten een andere teamlid achter het toetsenbord gaat zitten. Het team gaat ook zo vaak mogelijk samen zitten met de business om het product te laten zien en te controleren of dit is wat de business wil. Feedback wordt gegeven aan de rest van de organisatie door schermen op te hangen met daarop het aantal uitgevoerde testgevallen, bugs, etc. Bij Rachel’s klant werkt deze aanpak en ook steeds meer bedrijven stappen hierop over. Daarom is Rachel’s boodschap: “Sta open voor de vernieuwingen en denk na over hoe jij zelf past binnen en bij kan dragen aan de veranderende testwereld”.


Ben Williams en Tom Roden – The changing face of test management

Agile Testing Day Netherlands 2015 foto 3

Volgens Ben en Tom is testmanagement aan het verdwijnen binnen Agile, althans de rol testmanager. Want testmanagement is iets anders dan de rol van testmanager. Maar als die rol verdwijnt, wat doen de testmanagers dan binnen Agile? Ben en Tom hebben onderzoek gedaan en daaruit blijkt dat 90% van de testmanagers andere verantwoordelijkheden heeft gekregen. Ze doen nu meer aan coaching van de teams op het gebied van testtechnieken, treden op als mentor, doen aan stakeholder management en zorgen voor een totaalbeeld over de teams heen. Verder bleek uit het onderzoek dat ze veel minder plannen, rapporteren, testplannen schrijven, project management werkzaamheden uitvoeren en documentatie reviewen. Er zijn ook een aantal zaken gelijk gebleven binnen hun werkzaamheden. Namelijk budgetteren, training geven, tests reviewen, problemen oplossen en metrics verzamelen.
Maar is dat dan de toekomst van de testmanager? Persoonlijk denken Ben en Tom dat de rol van testmanager gaat verdwijnen, maar dus niet testmanagement. Testmanagers krijgen een nieuwe rol als testcoaches, met een bredere scope waarvoor ze andere vaardigheden moeten gebruiken. Ze coachen de teams hoe ze moeten testen, met welke technieken. Ze beantwoorden vragen en reviewen het werk van de testers. Ze zorgen voor een helicopterview over de teams heen, zodat de testwerkzaamheden van de team op elkaar aansluiten en elkaar niet in de weg (gaan) zitten. Ze geven trainingen, lossen algemene testproblemen op en ze verzamelen metrics van alle teams om zo de kwaliteit van de systeemontwikkeling inzichtelijk te maken. De teams zelf moeten veel meer verantwoordelijk gehouden worden voor de kwaliteit van de software die ze opleveren. Maar niet alleen door middel van testen, maar door de combinatie van al hun werkzaamheden. Maar dat kunnen ze niet alleen. Dus testmanagers: “Stop met managen en begin met mogelijk maken”.


Fanny Pittack en Alex Schwartz – Insight from happy change agents

Agile Testing Day Netherlands 2015 foto 4

Op conferenties hoor en leer je een hoop nieuwe dingen. Deze zaken neem je mee naar je werkplek. Maar hoe overtuig je je collega’s en hoe maak je ze net zo enthousiast over de dingen die je hebt gehoord en geleerd? Alex heeft bijvoorbeeld ooit geleerd tijdens een conferentie dat je binnen een organisatie geen tools moet gebruiken die alleen worden gebruikt door testers. Deze tools zorgen namelijk voor afbakening en obstakels tussen de teamleden. Maar toen hij terug kwam op z’n werk en daar een tool de deur uit werkte bleek dat toch niet zo’n succes. De gebruikers wilde hun tool helemaal niet kwijt en naderhand was zijn relatie met de gebruikers van die tool slechter geworden. De les is dat je niet zomaar een verandering moet doorvoeren zonder overleg. Je moet namelijk het team aan de hand nemen en samen een verandering doorvoeren. Via een mini testing dojo werd de zaal geconfronteerd hoe het voelt om zonder overleg een verandering door te moeten maken. De hele zaal moest in duo’s een oefening uitvoeren. Eerst mocht je de andere naar een plek duwen die jij had uitgekozen en daarna moest je de ander vragen om mee te gaan naar een bepaalde plek de je aanwees. Uiteraard liet dit zien dat mensen er niet van houden om ergens heen “geduwd” te worden. Ze willen namelijk weten waar ze heen gaan en waarom. Dus duw je collega’s volgende keer niet in een bepaalde richting, maar neem ze mee aan de hand met wat je geleerd hebt om samen een betere situatie te bereiken.


Manon Penning – Agile hacks for testing a medicale device

Agile Testing Day Netherlands 2015 foto 5

Toen Manon de eerste dag bij haar nieuwe klant kwam ontdekte ze dat wat ze daar Exploratory Testing noemden, dat helemaal niet was. Ze testen volgens bepaalde scenario’s die werden voorgeschreven door de kwaliteitsafdeling, wat natuurlijk loodrecht staat op de gedachte achter Exploratory Testing. Het uitvoeren van de scenario’s duurde bijna twee weken en zaten daarnaast ook nog eens vol met handmatige copy-paste acties. Wat de kwaliteit niet ten goede kwam. Voor Manon was het ook een raadsel hoe de audit afdeling ooit akkoord was gegaan met deze testaanpak. Vooral omdat het ging om de software van een medisch apparaat. Exploratory Testing was ver te zoeken dus besloot ze een “Agile hack” toe te gaan passen. Ze begon iedere ochtend de aanpassingen in de code te lezen sinds de laatste build en stelde daarover vragen aan de ontwikkelaars. Op die manier wist ze waarop ze de focus moest leggen bij het testen. Het sloeg aan en binnen kort tijd werd ze meer en meer onderdeel van het team. De ontwikkelaars gingen haar meer waarderen omdat ze in de gaten kregen dat haar vragen en opmerkingen er echt toe deden. De kwaliteit van hun werk werd beter en ze gingen zelf hun eigen werk ook beter unit-testen buiten de voorgeschreven paden om. Manon’s boodschap is dat ook al lijkt de situatie er niet altijd geschikt voor, er toch altijd wel ergens ruimte is om veranderingen door te voeren.


Alexandra Schladebeck en Huib Schoots – Where words fail, music speaks

Agile Testing Day Netherlands 2015 foto 6

Alexandra en Huib laten de parallellen zien tussen het spelen va muziek en Agile. Als je heel slecht speelt op een muziek instrument dan hoor je meteen dat het mis gaat. Bij Agile krijg je ook meteen feedback. Ook al speel je al jaren op een instrument, dan kun je het nog steeds op de verkeerde manier doen. Dus ervaring zegt niet dat je expertise hebt. Probeer ook niet meteen te complex te beginnen, maar oefen met makkelijke muziekstukken. In Agile moet je ook simpel beginnen en daarna uitbouwen. Het leren van de fundamentele handelingen op een instrument horen bij het leerproces. Ook al is het soms erg saai om honderden keren een toonladder te oefenen. Maar oefening baart kunst. Ook dit geldt voor Agile. Mensen horen in muziek allemaal iets anders. De zaal moet z’n ogen dicht doen en luisteren naar de muziek die Alexandra en Huib maken. Daarna vragen ze aan het publiek wat ze hoorden. De antwoorden lopen uiteen van dinosauriërs tot een begrafenis. Zorg er dus voor in je Agile team dat iedereen hetzelfde doel voor ogen heeft en dezelfde boodschap uit “de muziek” haalt. Je kunt muziek spelen in je eentje of met anderen. Alleen is maar alleen. Met een heel orkest heb je een dirigent nodig. Maar bij een band of bij jam-sessies leer je een hoop van elkaar op het gebied van muzikale vaardigheden en samenwerken. Zo ook in Agile teams. Maak ze niet te groot. Muziek bevat een bepaalde cadans. Net als in een Agile team. Probeer die cadans te ontdekken en ga er op mee. De samenwerking en het resultaat worden er beter van. Je kunt improviseren als je muziek aan het spelen bent. Daar ontdek en leer je nieuwe vaardigheden mee. Improviseer ook bij het uitvoeren van je werk als tester door het toepassen van Exploratory Testing. Op die manier ontdek je bugs en leer je nieuwe testtechnieken. Door te experimenteren in muziek en in Agile krijg je een uitkomst die van te voren niet te voorspellen is. Wat wel het geval is bij het spelen van bladmuziek of het uitvoeren van van te voren vastgelegde testscripts. Pas je manier van spelen aan op je publiek. In een hele kleine zaal ga je niet mega boxen neerzetten om je luisteraars vervolgens omver te blazen. Zo ook in Agile. Pas je manier van communiceren aan aan degene die de boodschap ontvangt. De lessen uit de vergelijking tussen muziek en Agile zijn: Leer de melodie van je team. Eindig je sprints in een goede cadans. Herken je rol in het team en de context. Oefen, herken de patronen en pas je aan.


Agile Games Market

Agile Testing Day Netherlands 2015 foto 7

Na deze muzikale opsteker was het tijd voor de Agile Games Market. Bart Knaack, bekend van onder andere het TestLab, had speciaal voor deze dag een spelletjesmarkt in elkaar gezet. Gedurende anderhalf uur konden op diverse plaatsen in het complex spellen gedaan worden die de Agile gewaarwording moesten versterken. Daarnaast werd er ook een schatkaart uitgedeeld waarmee de code van een kluis kon worden gevonden. De eerste persoon die de juiste code wist te ontcijferen won de prijzen die in de kluis lagen.

Agile Testing Day Netherlands 2015 foto 8

Agile Testing Day Netherlands 2015 foto 9


Olaf Lewitz – Integral Quality

Agile Testing Day Netherlands 2015 foto 10

Olaf vertelt dat Conway’s Law zegt dat elk systeem zo goed is als de organisatie die dat systeem maakt. We willen dat onze systemen op alle niveaus van goede kwaliteit zijn. We willen dat ze goed functioneren, snel, gebruikersvriendelijk, zinvol en succesvol zijn. Maar hoe creëren we organisaties die zulke fantastische systemen kunnen maken waar de klanten blij van worden? Daarvoor moeten organisaties veranderen. Ze moeten hun vertrouwen stellen in de teams, het aandurven om de verantwoordelijkheden bij het team neer te leggen en er van uit gaan dat het team deze “last” aan kan. Maar hoe zetten we die verandering in gang? De verandering begint altijd bij jezelf. Want mensen willen niet veranderd worden. Olaf vergelijkt het me de film The Matrix waarin Neo zelf moet beslissen om losgekoppeld te worden van de Matrix. We moeten de ander eerst inzicht geven in de situatie en vervolgens een aantal opties voorleggen. Op die manier kan iemand weloverwogen zelf de keuze maken voor een verandering. We kunnen elkaar inzicht geven door duidelijke taal te gebruiken zodat de teamleden zelf hun eigen beeld kunnen vormen. Geef ook duidelijk aan wat de context en het doel is van bepaalde code of functionaliteit zodat het juiste gebouwd kan worden. Luister naar elkaar zodat je weet wat de ander wil. Deel je visie om er voor te zorgen dat het team gezamenlijk dezelfde kant opkijkt. Dus maak die keuzes. Hierdoor stijgt het vertrouwen in jezelf, in elkaar, in het product en in de organisatie. De kwaliteit zal hierdoor omhoog gaan en de klanten meer tevreden.


Victor Willing – Agility through Continuous Delivery

Agile Testing Day Netherlands 2015 foto 11

Bij Victor’s werkgever werken ze volgens Agile en teams bestaan uit zes leden, maar daar zitten volgens hem geen testers bij. Maar hoe doen ze dat? Ten eerste door intensieve samenwerking, Dus samen code schrijven en zo de kwaliteit bewaken. Het twee paar ogen principe. Verder automatiseren ze alle checks en reviewen ze elkaars werk via Peer Reviewing. Naast code reviews binnen het team kunnen de teams onderling ook elkaars code gebruiken als ze dat willen, om zo de veranderingen ook in hun eigen bouwsels te gebruiken. Dat is dus het derde paar ogen dat naar dezelfde code kijkt. Vervolgens wordt de code in een centrale plek opgeslagen zodat iedereen met dezelfde code moet werken, waardoor het aantal paar ogen dat naar de code kijkt nog groter wordt. De code op de centrale plek moet in zo’n staat zijn dat het altijd naar de productie gebracht kan worden. Op deze manier moeten de teams continue nadenken over een mogelijke productiegang van hun code en dus over de kwaliteit.

Kritische kanttekening van de redactie: Hoewel Victor dus aangeeft dat er geen testers in het team zitten is dat nog maar de vraag. Want samen programmeren, checks automatiseren en elkaars code reviewen vraagt wel degelijk om testkennis en inzicht. Dus misschien heten ze dan wel geen testers, maar ze zijn het wel degelijk.


Jan Jaap Cannegieter – Flexible testing and using different sides of your brain

Agile Testing Day Netherlands 2015 foto 12

De oude manier van testen is op z’n retour en past niet meer in de manier van werken tegenwoordig. Het is tijd voor meer Agility. Meer Exploratory Testing. Checks worden geautomatiseerd zodat de testers handmatige tests kunnen uitvoeren waarbij ze hun creativiteit gebruiken. Maar testers gebruiken vooral de linkerkant van hun brein en dat is niet de creatieve kant van onze hersenen. De linkerkant is namelijk de kant die het beste is in het lezen van de requirements en het omzetten naar testscripts. Voor creatief testen moet je juist de rechterkant van de brein gebruiken. Hoe kunnen we er voor zorgen dat we onze rechterhelft van ons brein gebruiken en zo creatieve testers worden. Begin met het weghalen van grenzen, door bijvoorbeeld al je testboeken weg te gooien. Die leggen namelijk zaken op en blokkeren om er zelf over na te denken. Moedig flexibiliteit aan en laat de vakmensen zelf bepalen hoe ze hun werk moeten doen. Vertrouw op je gevoel, want daarmee ontdek je inconsequenties. Brainstorm. Leer van elkaars ideeën. Gebruik je voorstellingvermogen en doe aan empatisch testen. Speel spelletjes en train zo je hersenen. Gebruik visualisatie technieken. Op die manier komt informatie op verschillende manier aan in je hoofd. Stel vragen en ben en blijf kritisch. Maar blijf uiteraard ook je linkerhelft gebruiken in combinatie met je rechterhelft. Op die manier bezit je de ideale combinatie. De analytische creatieve tester.


Mike Sutton – Test beyond quality, beyond software

Agile Testing Day Netherlands 2015 foto 13

Mike is een Agile Coach. Volgens hem houden we van details. Dat is namelijk ons werk als tester. Maar in de details van software ontwikkeling vinden we vaak specialisaties die er voor zorgen dat we niet als team fungeren maar zorgen voor een splitsing tussen mensen en disciplines. Dit staat de vooruitgang in de weg. De zoektocht naar het verbeteren van de kwaliteit binnen je bedrijf brengt onzekerheid en risico met zich mee en vereisen al onze vaardigheden en passie. We hebben situationeel leiderschap nodig afhankelijk van de situatie. Dit kan de tester zijn. Agile teams zijn de plek om gedrag en cultuur te cultiveren op weg naar een nieuwe realiteit. Je hoeft niet van elkaar te houden maar je hebt dezelfde interesses en je probeert elkaar niet te vermoorden. Testes zijn vaak de connectie tussen de ontwikkeling en de business, dus ook binnen een team kunnen ze de “lijm” zijn die het team bij elkaar brengt en houdt. Maar helaas lijken de Agile teams tegenwoordig maar al te vaak op legbatterijen. Elke dag plopt er een ei uit, dag in, dag uit. De teams denken niet meer buiten hun eigen team. Ze stellen geen vragen. Maar testers stellen die vragen wel. Dus testers, sta op en stel de vragen. Vragen als: Wat zoeken we? Hoe weten we dat we de toegevoegde waarde opleveren die we denken dat we opleveren? Waarom duurt het zo lang om …? Wat gebeurt er als …? Testers help de Agile teams en de testwereld om op te staan en verder te gaan dan software. Kijk verder dan alleen het testen en ga de organisatie in om de boodschap uit te dragen dat je samen op zoek wilt gaan. Op zoek naar de wens om te verbeteren. Op zoek naar de passie om samen te werken. Op zoek naar de liefde en de intelligentie om te ontdekken wat we moeten testen. Doe het samen. Niet als testers. Niet als team. Niet als afdeling. Maar met het hele bedrijf.


Afronding

Het was een lange maar leerzame dag. We gaan allemaal terug naar onze organisatie en gaan daar als analytische en creatieve testers onze collega’s aan de hand meenemen bij het doorvoeren van de veranderingen. Om zo een organisatie te worden die streeft naar kwaliteit. We stoppen met managen en we gaan het gewoon mogelijk maken. Samen. Als team.