Martijn Gelens is testmanager bij Veritest en gedetacheerd bij Miplaza, onderdeel van Philips Research. Daar krijgt hij de ruimte om de Agile-werkwijze uit te breiden zodat deze aanpak gecomplementeerd en intrinsiek voorziet in testen.

29 August 2008

Wie zoekt op Wikipedia kan over Agile allerlei artikelen vinden. Ook over het testen van software is volop informatie beschikbaar. Een van deze artikelen vermeldt zelfs onder testontwikkelmethoden ’Agile testing‘, maar als je probeert op deze link te klikken, dan krijg je de melding dat er nog geen artikel bestaat met die naam. Dat is een mooi beeld voor de huidige stand van zaken, want maar weinig testers hebben een plaats binnen de Agile-omgeving. Dat is onterecht, want testen binnen Agile brengt interessante complicaties met zich mee.

Laat me voor de niet-ingewijden in Agile de arena eens omschrijven. De klant is te allen tijde beschikbaar voor het team. Door middel van korte iteraties van een tot vier weken implementeert het Agile-team user stories – een vorm van featurebeschrijving. De klant plaatst deze user stories met een prioriteit op de zogenaamde backlog, waarna het Agile-team ze realiseert. In de planningsessie aan het begin van de iteratie wordt de definitie van de user stories en de omvang in taken bepaald. Aan het einde van de iteratie levert het team de software werkend op met de nieuwe user stories aan boord.

Het gehele Agile-team is verantwoordelijk voor de uitvoering van al deze taken. Door middel van pair programming implementeert het de enigszins complexe ontwikkeltaken. Op deze wijze is de kennis van de interne code wijdverspreid en vindt er al tijdens de implementatie een code review plaats. Automatische unittests worden ingezet om de componenten na elke wijziging opnieuw te kunnen controleren op fouten en negatieve wijzigingen en acceptatietests worden geautomatiseerd. Uiteraard is er nog een scala aan andere kenmerken, maar deze vallen buiten de scope van dit artikel.

agile illustratie 2

Agile heeft van zichzelf al een hoop eigenschappen die de kwaliteit van de software positief beïnvloeden. Waarom is er dan toch ruimte voor de specifieke Agile-testerrol binnen het Agile-team? Tests geschreven door ontwikkelaars hebben vaak de eigenschap de user story te bewijzen zoals hij gevolgd zou moeten worden, onder de juiste omstandigheden. Dit zijn de zogenaamde clean cases (goedweergedrag). De Agile-tester bekijkt het systeem anders. Hij maakt de aanname dat het systeem fouten bevat en heeft als doel die onjuistheden te vinden. De zogenaamde dirty cases (slechtweergedrag). Het is dit verschil in visie waarmee de Agile-tester zich onderscheidt van de ontwikkelaar.

Met de volgende tien best practices kun je binnen de Agile-testerrol direct invulling geven aan het testen binnen de Agile-omgeving. Deze best practices sluiten bovendien ook mooi aan bij de klassieke testwereld.

1.

Tijdens de iteratieplanningsessie is de Agile-tester aanwezig om de klant kritische vragen te stellen over het verloop van de user story. Daarbij richt hij zich vooral op de details die vaak worden vergeten, zoals foutafhandeling of een situatie waarin het systeem zich niet zou moeten maar wel zou kunnen bevinden. Door het stellen van deze vragen krijgt de user story heel snel meer diepgang, waardoor het ontwikkelen eenvoudiger gaat en het resultaat ook minder fouten zal bevatten. Tevens komen hierdoor de eerste testgevallen bovendrijven. Andere testcases worden gedurende de iteratie duidelijk.

2.

De Agile-tester is een soort klantvertegenwoordiger. Hij maakt de verschillen inzichtelijk die zijn ontstaan tussen het ontwikkelde product, gebouwd uit user stories, en het verwachte product, een beeld dat de verkoopafdeling vooraf heeft geschapen en is ingekleurd door de goede eigenschappen van de eerste demonstrators en presentaties.

3.

De Agile-tester kent de eindgebruiker. Hij is in staat om de risico‘s in kaart te brengen die het bedrijf loopt met het product als het niet functioneert zoals beoogd. Hij beschrijft hiervoor testgevallen die deze risico‘s verkleinen. Op deze manier ontstaat er een Moscow-analyse (Must, Should, Could, Won‘t) van de producteigen features. De Moscow-analyse wordt als prioriteitenlijst ingezet en bepaalt de volgorde van implementeren en de diepgang van de tests. De kern van de analyse is dat sommige eigenschappen (terecht) minder belangrijk zijn en daarom ook minder aandacht verdienen en krijgen.

4.

Het is tevens aan de Agile-tester om een goede teststrategie te bedenken. De Moscow-analyse heeft bepaald welke features de meeste diepgang behoeven en de Agile-tester zal nu een selectie moeten maken van testsoorten om de features met de juiste diepgang te raken.

5.

Bij de teststrategie hoort ook het bepalen van de gewenste infrastructuur om het systeem te kunnen testen. Hierbij dient de Agile-tester rekening te houden met de uiteindelijke werkelijkheid waarbinnen het systeem zal gaan worden gebruikt en met het testbudget. Door middel van slimme testtools (simulatie) kan hij het systeem gecontroleerd aan de tand voelen, zonder dat er echte bedrijfsrisico‘s worden gelopen. Het onderhoud van deze (test)infrastructuur valt onder de verantwoordelijkheid van het gehele Agile-team.

6.

Dit brengt een interessant standpunt met zich mee. Automatisch testen is een must, maar niet de totale oplossing. Met automatisch unittesten kun je elke wijziging in de code zeer snel op betrouwbaarheid en gevolgen beoordelen, terwijl de kosten zeer laag zijn. Ook is het verstandig om systeemrequirements vast te leggen in automatische acceptatietests om degradatie van het bestaande systeem te voorkomen, maar dit wil niet zeggen dat alles automatisch testen de volledige oplossing is. Op systeemniveau is het verstandig ook op een andere manier te valideren, om ook de ongewenste ’features‘ aan het licht te brengen.

Op dit niveau is semiautomatisch testen een goede aanpak. Semiautomatische tests zijn grotendeels geautomatiseerd, maar nog steeds handwerk. Tooling maakt het werk eenvoudiger, maar het subjectieve oordeel van de tester is heel belangrijk omdat de mens een belangrijke factor is in het gebruik van het systeem. Het is de enige goede manier om een systeem te valideren dat moet interacteren met mensen. Een gebruikersinterface brengt verwachtingen en mogelijkheden met zich mee die een automatische test niet kan valideren en niemand vooraf kan voorzien.

Het is wel een goede eigenschap om automatische tests te gebruiken om te bewijzen dat oude problemen niet langer optreden. Voor het vinden van nieuwe problemen moet je toch echt handmatig (semiautomatisch) testen.

7.

Een krachtig middel om (semiautomatisch) te testen is Exploratory Testing. Deze werkwijze wordt meestal niet gebruikt omdat het een subjectief karakter kent, maar hierin ligt wel de kracht. Een teamlid (iedereen ziet andere dingen) zal gedurende een bepaalde tijd (Timebox) een feature of eigenschap van het systeem beoordelen (Scope) om daarmee aan te tonen dat het product aan de eisen voldoet of een risico bevat (Goal). Exploratory Testing zal naast allerlei foutrapporten ook een hoop kennis en ervaring bij de teamleden creëren, waardoor nieuwe medewerkers snel ingewerkt raken in het hele product en de ontdekte problemen in de toekomst worden voorkomen.

8.

De Agile-tester doet er goed aan om basiseigenschappen en -features vast te leggen in een smoke test. Dit is een korte test van ongeveer een kwartier die de primaire features van het product raakt en bovendien de menselijke interface van het systeem gebruikt. Met de smoke test kan het Agile-team heel snel (semiautomatisch) elke versie beoordelen op die punten die direct afbreuk zouden doen aan het product.

9.

De Agile-tester is het geweten van het team. Door regelmatig de tussentijdse kwaliteit van het systeem te meten – automatisch en semiautomatisch, kan hij tijdig escaleren naar de klant indien er een productrisico ontstaat dat de uiteindelijke klanttevredenheid in gevaar brengt.

10.

In de release-iteratie brengt de Agile-tester het product voor plaatsing bij de klant zo volledig mogelijk in kaart (systeemtest). Hij laat de ergste problemen reparen in zoverre dat nog op tijd mogelijk is. Het is ondenkbaar dat alle gevonden problemen opgelost zullen zijn. Er is bovendien een groot risico op introductie van andere problemen. Het is aan de Agile-tester en de klant om hierin een goede beslissing te nemen (Change Control Board). Tijdens de release-iteratie is het Agile-team alleen bezig met de release, niet met nieuwe features. Aan het einde van de release-iteratie wordt een systeem opgeleverd met een testrapport waarin de uitgevoerde testgevallen staan beschreven. In deze Release Notes staan de opgeloste en de overgebleven problemen vermeld en ze bevatten ook het advies van de Agile-tester dat uit de vorige twee rapporten volgt: go of no go.

Al met al wordt softwareontwikkeling steeds dynamischer. Methodieken zoals Agile zijn blijvertjes. De tijd van slechte requirements is voorbij, maar het hebben van een user story maakt het niet per se makkelijker. Agile geeft ons de ruimte om kritisch met de bril van de eindklant te kijken om de algemene productkwaliteit te verhogen.