Een ‘agile’ ontwikkelingsmethode, zoals Scrum, vereist een andere test-aanpak dan de klassieke ‘waterval’-methode. En dat zal de tester geweten hebben.

In de klassieke ‘waterval’-ontwikkelingsmethode, gaat de tester gewoonlijk pas laat aan het werk, wanneer de software zo goed als af is. Dat is onmogelijk in een ‘agile’ omgeving, waar telkens weer heel gericht kleine(re) stukken code worde opgeleverd op weg naar het ultieme geheel. Een geheel dat niet noodzakelijk al gekend is op het ogenblik dat het project van start gaat, want zowel de ‘requirements’ en de mate waarin die worden gerealiseerd kan (en zal) veranderen tijdens de ontwikkeling, conform de veranderende noden van het bedrijf. Zeger van Hese, tester en service owner ‘agile testing service’ bij CTG, merkt dan ook droogweg op dat dit “een initiële paniekreactie bij een klassieke tester” kan oproepen.

Verschillen

Worden bij het klassiek testen mogelijke veranderingen tot een absoluut minimum gehouden, dan gaat ‘agile’ ontwikkelen er van uit dat “verandering de realiteit is!” De planning is niet zo gedetailleerd en wordt bijgesteld op basis van de geboekte vooruitgang en de (nieuwe) noden. In tegenstelling tot de uitgebreide documentatie-output van de klassieke aanpak, geldt voor een ‘agile’ omgeving “zoveel als nodig maar niet meer, zodat geen verloren werk wordt verricht.” Een testplan in een ‘agile’ omgeving zal dan ook “in plaats van zeg maar 30 pagina’s liever op één A4’tje passen, met verwijzingen naar nodige informatie zonder die te dupliceren.”

Cruciaal is dat de tester van bij de aanvang (en zelfs vroeger) in het project actief is. “Hij zal helpen bij de iteratieve planning. Hij kan helpen als ‘vertaler’ tussen de klant en de ontwikkelaar,” zodat hij wat een ‘schaduw’-functionele analist kan zijn, terwijl hij ook kan helpen bij het inschatten hoeveel werk de ontwikkelaar per iteratie aankan. Zijn rol is dan ook “niet zo vast omlijnd als in de klassieke aanpak.” De tester kan zelf ook wat ontwikkelaar zijn, maar dat hoeft niet echt, klinkt het. Zelf was van Hese eertijds een mainframe-persoon, met slechts een geringe achtergrond als programmeur.

De opgeleverde stukjes code is het materiaal dat de tester onder handen neemt, waarbij hij zorgt voor een zo snel mogelijke terugkoppeling met de ontwikkelaars. Dat impliceert naast technologisch en een bedrijfsinzicht, ook een meer onderhandelingsgerichte rol en communicatieve vaardigheden. Een onvindbare witte raaf? Je vindt allicht niet alles in een persoon, geeft van Hese toe, meer je stelt een ‘agile’ team samen met het oog op een goede mix. “het hele team is verantwoordelijk voor het product, en de tester is zeker niet bedoeld als een kwaliteitspolitie. Samenwerking is het doel.” In een agile omgeving spelen vergaderingen dan ook een belangrijke rol, waarin duidelijkheid primeert boven welbespraaktheid of een vlotte pen. Het belangrijkste is dat de tester meer een manusje van alles wordt, wiens mening wordt gevraagd en gerespecteerd.

Andere tools

“Bovendien is een agile omgeving gericht op een continue verbetering, wat ook het werken aan de eigen skills inhoudt.” Het is een omgeving voor wie wil bijleren, ook in zelfstudie, klinkt het, wat allicht contrasteert met meer ‘klassieke’ (test)omgevingen, waar vaker “testers niet echt gepassioneerd bezig zijn met het uitvoeren van testscripts. Je kan beter testers aanmoedigen om ook aan andere dingen dan scripts te doen denken, wat motiverend werkt.”

Dat geldt ook voor de tools waar gebruik van wordt gemaakt. “De tools van de grote leveranciers zijn vaak te log en onvoldoende flexibel,” aldus van Hese, “Het gebruik ervan vormt een eigen specialisatie, met een eigen taal, en maakt dat de testers afgescheiden blijven van de rest van het team.” Zelf ziet hij meer in ‘light weight’ tools, die makkelijk kunnen worden aangepast.

Dat lukt wel voor ‘unit’-testen (het testen van de kleinste stukken code), maar wat met performantie- of stress-testen van het geheel? Een ‘end to end’-geheel is inderdaad niet altijd beschikbaar, maar van bij de aanvang wordt vaak wel een ‘story’ ontwikkeld, zeg maar de staaldraad die doorheen het hele pakket loopt. En dat kan al helpen. En voorts onderstreept van Hese nogmaals het belang om toch al zo snel mogelijk feedback te bezorgen aan de ontwikkelaars, zelfs als het nog niet de toepassing in haar geheel betreft. Je zal op het einde ook makkelijker bij eventuele problemen ontdekken in welk deeltje) van de code de oorzaak schuilt.

Van Hese verwijst overigens graag naar de ‘agile testing qua-drants’ die Lisa Crispin hanteert om zowel de technologie- als bedrijfsaspecten van een toepassing ten volle te testen. In het kader daarvan moeten eindgebruikers echte voorbeelden uit de praktijk formuleren, waaraan de ontwikkelaars en de testers hun code kunnen toesten. Uiteindelijk ziet van Hese al bij al heel wat personen, in het bijzonder wie vandaag afstudeert als ict’er, geschikt om aan agile testing te doen. “Na wat initiële drempelvrees met een ‘ik kan het niet’-reflex zullen ze inzien dat het een plus is, goed voor een grotere verscheidenheid in de taken en een grotere betrokkenheid […] In hun plaats zou ik denken van ‘Joepie, ik mag in een agile omgeving werken!'”

Guy Kindermans