Collective test ownership – Kwaliteit is een teamverantwoordelijkheid

Een algemeen toegepaste werkwijze vanuit eXtreme Programming (XP) is collective code ownership. Dat houdt in dat alle teamleden gezamenlijk de code beheren, volledige inzage hebben, en bijvoorbeeld ook de fouten oplossen in code die door een ander is geschreven. Dat impliceert dat er één gezamenlijk systeem moet zijn voor het beheren van de code, en uiteraard is het ook alleen werkbaar als er tevens continuous integration wordt toegepast. Voorts moet er sprake zijn van veel uitwisseling van kennis, bijvoorbeeld door middel van reviews of pair programming.

Sommige teams gaan nog een stap verder, door ook alle testware in source control te plaatsen, en deze als team gezamenlijk te beheren. Elisabeth Hendrickson noemt dat: collective test ownership.

Collective Test Ownership. bron: Elisabeth Hendrickson

Collective test ownership

De essentie van collective test ownership is dat het team gezamenlijk verantwoordelijkheid neemt voor het testen en haar werkwijzen in het zelforganiserende team daarop afstemt.  Collective test ownership voorkomt daarmee dat het testen de bottleneck in de iteratie gaat worden doordat het hele team meedenkt en meewerkt. In Testen3.0 benoemen we collective test ownership als een must-have: deze gedachte met werkwijzen moet in het team aanwezig zijn, of het moet een groeidoelstelling voor het agile team zijn.  We hebben gemerkt dat het van het team het nodige eist om collective test ownership in praktijk mogelijk te maken. Coding standards zullen moeten worden doorgetrokken naar testdocumenten en testcode. Testen worden zo dicht mogelijk gekoppeld aan de code. De vertaalslag van requirements naar testen moet duidelijk en traceerbaar zijn. Bij wijzigingen in de code of in de requirements moet het gehele team over voldoende overzicht beschikken, om adequaat te kunnen beslissen over de testen die moeten worden uitgevoerd, en hoe deze verder moeten worden beheerd.

Veel van de testen in een agile project worden geautomatiseerd. Het inrichten van de testautomatisering wordt belegd bij de specialisten binnen het team en de zelforganiserende werkwijze zorgt ervoor dat de juiste zaken tijdig getest worden. Het beheer van de testen komt daarna bij alle leden van het team te liggen. Dat houdt in dat kennis actief moet worden gedeeld, en er regelmatig in paren zal worden gewerkt om mogelijke kennisgaten zo snel mogelijk te dichten.

Gelijkheid binnen het team
Het klinkt zo gemakkelijk: gelijke monniken, gelijke kappen. Het is echter wel een hele mentaliteitsverandering om collective test ownership in te voeren, en beslist eentje die weerstand oproept. Nog altijd zien veel programmeurs het testen als monnikenwerk, iets waar ze bewust niet voor hebben gekozen. Toch kan het zomaar gebeuren dat van een programmeur of een analist wordt verlangd dat hij of zij gaat meehelpen met het uitvoeren van testen die niet zijn geautomatiseerd! Kwaliteit is immers een teamverantwoordelijkheid en code schrijven die niet getest kan worden is verspilling… De bereidheid om werk uit te voeren en zich te ontwikkelen buiten de eigen comfort zone is dus noodzakelijk om het team als geheel succesvol te laten zijn. Daar helpt collective test ownership absoluut bij.

Wat ook belangrijk is voor de benodigde gelijkheid binnen het team, is dat iedereen wordt behandeld als een volwaardige professional, die niet hoeft te worden beknot in zijn of haar rechten. Geef dus een tester gewoon schrijfrechten op de code en de unit tests, en geef een bouwer de mogelijkheid om met één druk op de knop de inhoud van een compleet testscript te wissen. Ze zijn immers allemaal professioneel genoeg om hun rechten niet te misbruiken (en alles staat toch in source control). Het gaat er om dat iedereen haar verantwoordelijkheid neemt en scheiding van rechten kan dat belemmeren. Wat vermeden wordt met het uitdelen van full control, is dat er berichtenverkeer buiten de codebase nodig is. Dat laatste levert alleen maar verwarring en vertraging op, en is dus een vorm van verspilling.

Een medewerker die onvoldoende technisch onderlegd is om zelfstandig een test te implementeren of aan te passen, kan deze allicht wel met een paar commentaarregeltjes omschrijven in de code. Maak afspraken over de te gebruiken tags in de testcode, en richt het build proces er op in.

Beheren van testware
Als een team er serieus werk van wil maken om gezamenlijk de testen te beheren, dan moet de testcode zo veel mogelijk gezien worden als reguliere code. Testcode heeft namelijk ook onderhoud nodig. Testcode moet op een onderhoudbare wijze worden opgezet. Allicht moeten teamleden elkaars testcode reviewen. Mogelijk komt er uit zo’n review dat een test eenvoudiger kan of bijvoorbeeld herhalingen bevat. Kortom: refactoring van testcode zou gebruikelijk moeten zijn. Het enige probleem daarbij is dat er geen vangnet van geautomatiseerde testen voorhanden lijkt te zijn om wijzigingen aan de testcode mee te borgen. Dat is echter niet helemaal waar. Gebruik het versiebeheersysteem om zowel de code als de testcode “uit te checken”. Houd bij het refactoren van testcode de productiecode constant, en zie er op toe dat de testen “groen” blijven!

Links
Artikel
in Testing Experience, waarin Collective Test Ownership wordt gebracht als natuurlijk resultaat van het continue verbeterproces dat centraal staat in de agile methodiek.
QRC
(Quick-Reference Card), waarop Collective Test Ownership in 1 A4 wordt uitgelegd.

Over ericjimmink

Eric Jimmink is een testconsultant met een achtergrond als ontwikkelaar / meewerkend voorman. Zijn eerste agile project was al in 2001. Eric geniet bekendheid als co-auteur van het boek 'Testen2.0', als schrijver van artikelen over agile testen, en door het geven van presentaties. Momenteel is Eric bezig met 'Testen3.0', waarvan enkele fragmenten geplaatst worden op de AgileOrdina blog.
Dit bericht werd geplaatst in Agile ontwikkelen, Agile Testen, Implementatie van agile, Testen3.0 en getagged met , , . Maak dit favoriet permalink.

Een reactie op Collective test ownership – Kwaliteit is een teamverantwoordelijkheid

  1. Pingback: Testen 3.0 en RUP op Maat | AgileOrdina

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