Video review: Commonsense Agile

Auteur: Gilbert Smulders ● gilbert.smulders@viqit.nl

Binnen mijn opdracht is er momenteel wat discussie over hoe Agile wij zijn en hoe onze Agile processen werken. Daarbij is ook vaak de rolverdeling een onderwerp van gesprek. Ook bij gesprekken bij andere klanten kom ik vergelijkbare discussies tegen. Toen ik tijdens mijn zoektocht voor een nieuwe video review tegen deze video van Alan Richardson over Agile Testing aanliep, leek me dit een mooi onderwerp voor een review.

 

De spreker

Alan Richardson is een Brit die zichzelf ten doel heeft gesteld om teams beter te laten opleveren, automatiseren en testen. Hij is ook bekend onder zijn pseudonym Evil Tester. Onder die naam publiceert hij regelmatig blogs, podcasts en video’s. Daarnaast verzorgt hij trainingen en schrijft hij boeken. Alan heeft ervaring als softwaretestingconsultant bij diverse financiële instellingen, gaming, media, luchtvaart, energie en telecombedrijven. Daarnaast is hij actief als spreker op conferenties over de hele wereld. Daarbij heeft hij uiteraard ook op TestNet gesproken. Ook toen wist hij mij al erg te inspireren.

De presentatie

Alans presentatie is geënt op een aantal vragen die hij regelmatig ontvangt. Deze negen meestgestelde vragen beantwoordt hij nogmaals uitgebreid in zijn presentatie. De vragen gaan over Agile, over testen en over automatiseren.

De eerste vraag is ‘Wat is Agile Testing?’ Vaak wordt Agile development wel uitgebreid uitgelegd. Maar er wordt eigenlijk nooit over testen gesproken. Dit wordt vaak gezien als een standaard onderdeel bij Agile development. Het testen moet echter worden geplot op het developmentproces. Dit is overal verschillend. Het is namelijk afhankelijk van de technologie, de tools, de teams, de stakeholders en de communicatie binnen de organisatie. Daarom wordt er vaak slechts generiek over testen gesproken en heb je ervaren testers nodig om dit te kunnen vertalen naar een Agile team.

De tweede vraag is ‘Wat doet een Agile Tester?’ Eigenlijk is dat niet meer dan een model maken en deze vergelijken met het systeem. Dat vergelijken doe je met exploreren en experimenteren. Het proces van een model maken is gecompliceerd. Dit vraagt echte testexpertise. Daarbij worden requirements, acceptatiecriteria, risico’s en dergelijke gebruikt. Bovendien blijft de tester dit model continu uitbreiden door te observeren, te exploreren en het systeem te manipuleren.

De volgende vraag is ‘Hoeveel moeten we automatiseren?’ Dit is heel erg afhankelijk van wat je wil bereiken. Wat heb je nodig en heb je dit continu nodig? Het is dus heel erg afhankelijk van de specifieke situatie. Helaas zie je vaak dat automatisering niet om die reden wordt gedaan. Daarbij wordt gewoon zoveel mogelijk geautomatiseerd zonder te kijken naar wat er wel of niet nodig is. Eigenlijk is dit antwoord ook van toepassing op de vraag of je überhaupt moet automatiseren.

En dan komt de veelgestelde vraag ‘Hebben we testers nodig in Agile?’ Gelukkig is het antwoord volmondig ja. Testers zien mogelijkheden om te testen die anderen niet zien. Ze gaan dieper in op de vraag of we voldoende zekerheid hebben. Op basis van nieuwe vragen en nieuwe experimenten blijven zij het model steeds verder verfijnen.

Alan vervolgt met de vraag ‘Hoe kunnen we automatiseren én de sprint afronden?’ Vaak zie je dat er te veel programmeerwerk in een sprint zit en dat er te weinig wordt gekeken naar risico’s en gebruikersbehoefte. Dan ontstaan aparte testsprints die door de testers wordt uitgevoerd. Je moet echter werken als een team. Dus samen ontwikkelen, automatiseren en testen om Agility te waarborgen. Het team moet commitment geven voor het geheel.

Over de vraag ‘Wat is een Agile Tester?’ is Alan vrij kort. De Agile Tester is flexibel. Hij houdt zich bezig met de context. Hij stelt vragen en exploreert het systeem. En houdt niet vast aan processen en rituelen.

De eennalaatste vraag is ‘Welke tools moeten we gebruiken?’ Ook hier hangt het weer af van de context. Welke tools passen er en welke zijn er nodig? Tools moeten de mogelijkheden uitbreiden om de acceptatiecriteria te kunnen verifiëren. Gebruik geen specifieke testtools, maar integreer de tools binnen het gehele team.

Alan sluit af met de vraag ‘Hoe kunnen we alle testen afronden in de sprint?’ Eigenlijk is dat heel simpel. Pak niet meer op dan het team aan kan. Iedereen in het team heeft een bijdrage in het testen. De tester doet de beste test. De rest helpt mee in de overige testtaken.

Mijn visie

Alan hanteert een aantal standaard antwoorden. Zo heeft hij het vaak over de context. Vroeger had ik een beetje een aversie tegen dit soort antwoorden. Immers, als je zoekt naar een antwoord, wil je niet horen dat het afhankelijk is van de situatie. Je wilt gewoon een antwoord op jouw vraag. Maar helaas is het antwoord op de vraag wel degelijk afhankelijk van wie deze vraag stelt in welke context. Bij ViQiT hebben wij het vaak over ‘nadenken in plaats van nadoen’. Dat komt eigenlijk op hetzelfde neer. Iets wat werkt in de ene situatie hoeft in een andere situatie helemaal niet de beste oplossing te zijn. Je moet dus goed bedenken wat je wil bereiken en wat je daarvoor nodig hebt. Dat bepaalt welke oplossing het beste is.
Daarnaast ben ik blij met zijn antwoord over de rol van tester in Agile. Zoals hij de testrol beschrijft, denk ik dat wij een goede toegevoegde waarde hebben in ieder Agile team. Het komt ook overeen met hetgeen ik vaak zeg in Agile teams. Het gaat er om de kritische vragen te stellen en dieper ingaan op de vraag of we voldoende zekerheid hebben. Gebaseerd op onder andere risico’s en gebruikersbehoefte bepalen we welke zekerheid we nodig hebben en zorgen we ervoor dat we die krijgen.

Al met al een video van Alan Richardson die een aantal zaken nogmaals bevestigt. Toch is het goed om deze bevestiging weer eens te krijgen. Daarom een aanrader om deze video eens te bekijken.

Bekijk de video hier

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *