Het eigen Agile Testing Manifesto

Auteur: Yanto Hesseling ● yanto.eu ● @yantohesseling

Ik ben van nature altijd bezig om te kijken hoe iets slimmer of beter kan. Het geeft mij voldoening om iets te creëren waar iemand anders blij van wordt. Jarenlang dacht ik dat iedereen zo was, maar sinds Agile meer gemeengoed is geworden, is mijn beeld veranderd. Van ieder hulpmiddel vraag ik mij af of iemand er baat bij heeft. En misschien nog belangrijker: of iemand er behoefte aan heeft. Wie wordt hier gelukkig van? Wordt er een probleem opgelost door deze IT-techniek in te zetten? Wordt de organisatie of mijn omgeving hier aantoonbaar beter van? Ik vraag altijd voor wie we het product aan het ontwikkelen zijn. Vaak krijg ik helaas een antwoord wat verre van concreet is.
Denken vanuit business perspectief
Toen was daar ineens Agile. Denken vanuit een business perspectief. Toegevoegde waarde leveren. Mensen blij en gelukkig maken met jouw product! Helaas zie ik weinig van deze mindset terug in de praktijk.
Als je mij nu vraagt wat er minimaal in een business case hoort te zitten, ga ik Google gebruiken om het kader op te zoeken. Een goede businesscase geeft antwoord op de vraag waarom het project moet worden uitgevoerd. Wat wil de opdrachtgever bereiken met het resultaat? Een testplan benoemt wel iets. Maar vaak is dit toch gericht op de software of het systeem.
Toch is het handig om als lid van een Agile-team te weten wat de rechtvaardiging is van het project. Al is het alleen handig om impact van een constatering te wegen. Of bijvoorbeeld om de keuze te kunnen maken om te testen in productie. De wereld is groter dan risico’s alleen. Kwaliteit is toch ook vaak de waarde die iemand hecht aan een product.
Kwaliteit bepalen als team
Voor het Agile tijdperk deed vaak alleen de tester iets met kwaliteit. Dit is best een vreemde situatie, aangezien de tester alleen constateert en afhankelijk is van stakeholders en eindgebruikers. Maar wil je als team resultaten bereiken met Agile, dan is het gehele team verantwoordelijk voor de kwaliteit.
Soms worden er code reviews uitgevoerd door ontwikkelaars. Verreweg de meeste Agile-teams die ik heb gezien maken de tester verantwoordelijk voor kwaliteit. In de praktijk voert een tester als enige teamlid checks uit op software. Meestal om de simpele reden dat alle teamleden deze situatie logisch vinden, waaronder de tester zelf.
Agile belofte
Waar Agile uitgaat van snel waarde realiseren, werd mij ineens iets zichtbaar. Door een kort-cyclische aanpak worden in hoog tempo producten of deelproducten gerealiseerd. De oorspronkelijke gedachte is dat producten die de meeste waarde creëren als eerste worden gerealiseerd. Het prioriteren van deze producten, maar ook het definiëren van deze producten is al ‘iets doen met kwaliteit’. Ik zag in dat een tester veel nauwer betrokken wordt bij de ontwerp-keuzes van een product.
Een andere Agile benadering is het kijken naar het project. Door de kort-cyclische aanpak worden snel problemen zichtbaar bij het realiseren van een product. Door snelle feedback is het mogelijk om de oorzaken van deze problemen in een vroeg stadium weg te nemen. Een dergelijke benadering is effectiever dan wanneer aan het einde van een project deze problemen zichtbaar worden. Een project dat op een Agile manier wordt uitgevoerd zal daarom uiteindelijk meer waarde opleveren.
Een tester in een Agile-team heeft zowel met het product als het project te maken. In deze beide Agile benaderingen zie ik de tester als een persoon die een nuttige bijdrage kan leveren. Een tester kan namelijk alles overzien en continu inzicht verschaffen in het product en het project.
Agile Testing Manifesto
Waarde bepalen kan lastig zijn. Regelmatig heb ik het Agile Manifesto gebruikt om te kijken of wij met het team werkzaamheden verrichten die te maken hebben met de rechterkant of de linkerkant van het Agile Manifesto. Deze vier gebieden komen voort uit twaalf principes die ingaan op softwareontwikkeling. En testen maakt onderdeel uit van softwareontwikkeling.

Het Agile Manifesto is opgesteld door zeventien ontwikkelaars. Het geeft tenminste iets van inzicht in de waarde van onze activiteiten als team. De beste situatie voor iedereen is directe interactie en betrokkenheid van de klant.
De Agile manier van werken is ook gericht op het vroegtijdig feedback verzamelen en leren. Hoe gaat het team snel feedback verzamelen om daarmee betere kwaliteit te kunnen leveren? De lat hiervoor ligt bij mij hoger dan het implementeren van testtools.
In mijn zoektocht naar antwoorden vond ik het Agile Testing Manifesto van Sam Laing en Karen Greaves. Het oorspronkelijke Agile Manifesto is opgesteld door zeventien ontwikkelaars. Het Agile Testing Manifesto is opgesteld door twee testers. Om de gedachte achter het Agile Testing Manifesto te begrijpen, heb ik contact opgenomen met de bedenkers Karen Greaves en Sam Laing.
Wat zijn de Agile Testing Manifesto principes?
Karen Greaves en Sam Laing en leggen voornamelijk de nadruk op de mindset wanneer we het over Agile testing hebben. Hierbij gaan ze uit van vijf principes.

Testing throughout OVER testing at the end
Een belangrijke Agile kwaliteitsbenadering maar ook een belangrijke kwaliteitsbenadering in het algemeen is om de feedback cirkel te reduceren tussen het vergaren van informatie en het valideren hiervan. Het kern principe van Agile softwareontwikkeling is gericht op snelle feedback, frequent releasen en hoge interactie met klant.
Test zo vroeg mogelijk in de softwareontwikkelingscyclus. Testers zouden zich nog beter kunnen richten op alles wat is gerelateerd aan het systeem op ieder moment. Dit gaat verder dan de systeemeisen maar het gaat ook om non-functional requirements, infrastructuur en werkprocedures. Ook een businesscase kan zeer waardevol zijn.
Preventing bugs OVER finding bugs
Sommige mensen denken dat het testen gaat om het ‘vinden van bugs’. We zouden ons beter kunnen richten op het voorkomen van fouten door het stellen van de juiste vragen wat ons in staat stelt om zijn om te kijken naar grote geheel vanuit verschillende standpunten. Door uitsluitend te concentreren op het vinden van bugs wordt er bijvoorbeeld een ‘wij tegen hen’ mentaliteit gecreëerd tussen testers en ontwikkelaars. Relaties en vertrouwen in elkaar zijn belangrijke in Agile softwareontwikkeling. Het continue ‘bug hunten’ zal deze relaties verstoren. Testen is ook het leren van het systeem en het verschaffen van inzichten.
Testing understanding OVER checking functionality
Testers die controleren of de applicatie werkt zoals verwacht kunnen beter tijd besteden aan iets anders. Geautomatiseerde tests zijn hier namelijk veel beter voor. In plaats daarvan kunnen testers ervoor zorgen dat iedereen begrijpt wat de klant echt nodig heeft. En wat de klant verwacht van het systeem voordat de code is geschreven.
Building the best system OVER breaking the system
Soms denken mensen dat het testen gaat om ‘het breken van een systeem’. Deze mentaliteit kan een barrière creëren tussen teamleden. In plaats daarvan is het beter dat teams samenwerken en elkaar helpen om daarmee het beste systeem te kunnen bouwen voor de klant. Natuurlijk worden er ‘bugs’ gevonden in een systeem, maar plaats de nadruk op het creëren van waarde.
Team responsibility for quality OVER tester responsibility
Testers worden soms verantwoordelijk voor de kwaliteit van het systeem gehouden. In feite is het gehele team verantwoordelijk voor de kwaliteit van het product dat zij bouwen. Ieder persoon in het team speelt een belangrijke rol bij de ontwikkeling en draagt bij aan de bouw van een product van waarde voor de eindgebruiker. Het is van belang dat het team begrijpt waar de klant naar op zoek is, maar ook waar de klant waarde aan hecht.
Bespreek kwaliteit
Nadat ik dit Agile Testing Manifesto had geprint, ontstond er een gezonde discussie over kwaliteit binnen mijn eigen team. Ook vroegen andere testers zich af wat voor ‘plaatje’ het was. Dit is wat mij betreft waar het Agile Testing Manifesto van Karen Greaves en Sam Laing voor dient. Een gesprek op gang brengen over kwaliteit binnen het team. Het gehele team is verantwoordelijk voor de kwaliteit van het product. Deze gedeelde verantwoordelijkheid was er in mijn optiek overigens ook al voordat Agile gemeengoed werd.
Toen ik de eerste keer het Agile Manifesto las, dacht ik: dat is logisch. Natuurlijk gaat software ontwikkeling over mensen, werkende software en de klant. Uiteindelijk heeft het Agile Manifesto mij wel geholpen om deze onderdelen binnen projecten bespreekbaar te maken.
Het Agile Testing Manifesto van Karen Greaves en Sam Laing zie ik dan ook als een hulpmiddel om kwaliteit binnen Agile projecten bespreekbaar te maken. Het is een manier om software te ontwikkelen die aansluit bij de behoefte van de klant. En daar wordt volgens mij iedereen gelukkig van!