Testen als een team: het derde stadium van Agile Testen

In agile projecten heeft het testen een ontwikkelingscurve doorgemaakt. In de beginjaren (2001 – 2004, het beginstadium) werd de rol van de tester ontkent; het testen viel binnen de rol  van de ontwikkelaar en de klant. De ontwikkelaar moest rechtstreeks kunnen communiceren met de klant. Dit staat ook zo beschreven in de boeken van Kent Beck over eXtreme Programming (XP). Overigens was dat niet zo heel vreemd, want in die tijd waren er ook nog maar weinig testboeken geschreven waarin samenwerken met andere disciplines benoemd werd als een voordeel. Laat staan dat boeken over testen überhaupt leesbaar zijn voor niet-testers… We zullen het ontbreken van dat inzicht de agile visionairs dan ook niet aanrekenen🙂

Vervolgens kwam vanaf 2004 het ‘bewustwordingstadium’, waarin het duidelijk werd dat de tester een toegevoegde waarde in agile projecten had. In die periode werd er  veel ontwikkeld en op conferenties gediscussieerd over hoe die rol er nu precies uit ziet: meer technisch of juist meer domeingericht, veel tooling of juist handmatig Exploratory testen, etcetera. Die discussies werden min of meer vastgelegd in een tweetal boeken: ‘Agile Testing – A Practical Guide for Testers and Agile Teams’ (Crispin & Gregory, Addison-Wesley, jan 2009) en ons eigen boek ‘Testen2.0. De praktijk van agile testen’ (Tijman en Jimmink, Sdu Uitgevers, nov 2008). Je ziet nu veel agile teams deze rollen van testers in agile teams implementeren. Het is voor veel testers nog best een flinke uitdaging, maar inmiddels zijn er ook veel testers verknocht geraakt aan hun ‘spin-in-het-web’ rol.

Inmiddels zijn we aan een derde fase toe, het ‘teamstadium’. Daarin draait het niet meer om de rol van de tester in een agile project, maar op hoe het team het testen invult in het agile project. Het team neemt aan de hand van de Definition of Done de verantwoordelijkheid voor het realiseren van een kwaliteitsproduct. De practices die nodig zijn om tot die kwaliteit te komen worden neergelegd bij diegene die dat het beste kan en zich daar ook aan wil committeren. Het multidisciplinaire team werkt daarin samen als ware het een voetbalelftal: soms moet de aanvaller ook meeverdedigen en soms moet de verdediger ook mee aanvallen. Waarom? Omdat hij (of zij) specifieke kwaliteiten heeft die het team op dat moment versterken en het doel –de wedstrijd winnen- het belangrijkst is! En zo gaat het dus ook met het agile team. Soms kan een tester goede analytische vragen stellen en is hij deels een business analist of ontwerper. En soms kan de ontwerper uitstekend overweg met testscripts en testgevallen en vervult hij (deels) de rol van tester. En soms kan een beheerder hele kritische vragen stellen over de implementatie en beheerbaarheid van het systeem en neemt hij deel in de systeem- of acceptatietest. Waarom? Omdat het doel –het opleveren van een kwalitatief goed product binnen de gestelde kaders- het belangrijkst is. Het gaat niet om je rol, of je verantwoordelijkheden, maar om het resultaat wat je als team boekt. Wat ons betreft wordt ieder agile team wereldkampioen software ontwikkelen! En dat wij dus hier bloggen over Testen3.0 is geen toeval🙂.

Over Anko Tijman

Managing Consultant on Agile & DevOps at Ordina. Connector. Listener. Thinker. Collaborator. Pianist. Dad. http://nl.linkedin.com/in/ankotijman
Dit bericht werd geplaatst in Agile methodieken, Agile ontwikkelen, Agile Requirements, Agile Testen, Testen3.0 en getagged met , , , , , , , , , , , . Maak dit favoriet permalink.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s