InnoveerJijMee met Gojko Adzic en Anko Tijman

Op maandag 31 januari organiseerde Ordina een vrij toegankelijke ‘InnoveerJijMee’ sessie over agile testen, de eerste in een reeks van Agile onderwerpen. De zaal zat vol; begrijpelijk, met klinkende namen als Gojko Adzic en Anko Tijman als sprekers.

Met 2 boeken, diverse artikelen en vele indrukwekkende presentaties, is Gojko Adzic een gevestigde naam binnen de Agile community. Hij geldt als een autoriteit op met name de communicatie met de klant en de vertaalslag van het klantdomein naar geautomatiseerde acceptatie testen.
Bij het introduceren van Gojko Adzic vraagt de gastheer zich af, of de spreker de confrontatie opzoekt.

Gojko Adzic – “Sleeping with the enemy”
Gojko Adzic weet het publiek te prikkelen, door te beginnen met een uitspraak van Keith Braithwaite:
When are we [programmers] going to stop telling testers how to do their job? They know testing much better than we do!

De meeste modellen voor de totstandkoming en het opleveren van software zijn gebaseerd op een gebrek aan vertrouwen.
Wanneer de ‘samenwerking’ gekenmerkt wordt door requirements signoffs, code freezes, en onafhankelijke testteams, dan hebben de meeste partijen een alibi voor als het project de mis gaat. Als bij een stoelendans is dan voor de testers vaak geen stoel meer over.
Vanuit de Agile (Lean) gedachte moeten al deze alibi genererende maatregelen gezien worden als verspilling (waste) in het proces; het voegt immers geen enkele waarde toe voor de klant.

Succesvolle teams integreren het testen
Voor zijn nieuwe boek (http://www.specificationbyexample.com/ ) heeft Gojko 50 agile teams geïnterviewd, die uitzonderlijk succesvol waren in het realiseren van een hoog kwaliteitsniveau. Dit hield in dat die teams nagenoeg geen defects door lieten gaan naar productie. Bij die teams was er nergens sprake van onafhankelijke validatie, dus zeker geen afzonderlijk test/QA team. Velen hadden een oplevercyclus van slechts één dag, of enkele uren. Een andere uitkomst van zijn analyse was het gebruik van open source test tools. Gojko’s verklaring is dat juist omdat die tools geen licentie kosten met zich mee brengen, zowel de business als de (gehele) IT er gebruik van kan maken. En dat komt het resultaat ten goede.

Behoud de rollen, maar dump de titels
Wanneer er niemand het woord “Test” in zijn of haar functieomschrijving heeft, dan zal iedereen in het team testen uitvoeren. Zijn er wel dergelijke “testpersonen”, dan het kan team gemakkelijk vervallen tot een gedrag waar het team heel veel of alle testtaken op het bordje van de tester schuift. Daarmee test het team als geheel minder en komt het testen op het kritieke pad van het project. Testen moet dus als een rol gezien worden, niet als een functie. Voor veel testen maakt het immers niet uit wie de test uitvoert. Deel testkennis actief, bijvoorbeeld door het testen paarsgewijs uit te voeren.
Het multidisciplinair uitvoeren van het testen verhoogt het wederzijds vertrouwen. Gojko: “Wees daarin de goede instructeur die voordoet en uitlegt hoe je moet rijden, niet de slechte die je er op wijst dat je de auto in de prak hebt gereden.”

Maak kwaliteit zichtbaar
Kwaliteitsdoelstellingen moeten zichtbaar en meetbaar zijn, en een gezamenlijk doel om naartoe te werken. Als kwaliteit een duidelijk zichtbare beperking wordt voor het behalen van een persoonlijk doel of een beloning, dan zullen mensen creatieve manieren vinden om het te laten werken.


Genoemd, niet getoond door Gojko, als uitstapje bij het zichtbaar maken van kwaliteit: bij Google hebben ze er een soort van video game van gemaakt. Resultaat was dat aantallen defects lager werden en doorlooptijden daarvan merkbaar korter.

Wie moeten de eigenaars zijn van de testautomatisering? Programmeurs of testers?
Gojko vraagt het publiek: “Wie hoort de eigenaar te zijn van de testautomatisering?” Enkele mensen in de zaal steken een hand op voor “de testers”, iets minder voor “de programmeurs”, en een meerderheid kiest voor “beide groepen”. Zelf had ik aarzelend mijn hand opgestoken voor “de programmeurs”. In feite was dat ook het antwoord van Gojko, want:
• Als testers de testautomatisering onderhouden, dan lopen ze vaak tegen de muur op, en moeten ze schipperen tussen het uitvoeren van handmatige testen, en het bijhouden van de geautomatiseerde testen. Willen de testers al het extra werk voor het automatiseren zelf oppakken, omdat ze de ontwikkelaars niet vertrouwen?
• Zet het bijhouden van de testen op het kritieke pad voor de ontwikkelaars, en zij zullen er voor zorgen dat het automatiseerbaar wordt opgezet. Een tester is dan nog pakweg 30% van zijn of haar tijd kwijt aan het adviseren wat er getest moet worden, en misschien 10% met het zelf uitvoeren van testen die expertise van een specialist vereisen.

Al met al zou de “richting” van de werkverschaffing moeten omdraaien. Zo wordt “de tester” niet het afvoerputje waar het hele team het werk op uit stort, maar de test architect die testwerk aangeeft aan de bouwers.

Tenslotte
Resumerend: wat is de toegevoegde waarde van de tester in dit plaatje:
• Bewerkstelligen dat de juiste testen uitgevoerd gaan worden (critical thinking)
• Zelf toepassen van testexpertise
• Overdragen van testkennis

Tijdens de pauze praten veel mensen na over de presentatie van Gojko Adzic; velen ervaren het verhaal als heel herkenbaar. Ook is men enthousiast, en hoeft het publiek niet gemaand te worden om weer plaats te nemen voor het vervolg.
Als spreker en als partner van Ordina behoeft Anko Tijman weinig introductie.

Anko Tijman – Building a Quality Driven Team
Als opening begint Anko met het schetsen hoe succesvol een voetbalteam zou zijn wanneer er alleen binnen de eigen discipline wordt samengewerkt. Wat gebeurt er als aanvallers zich alleen bezig houden met aanvallen, alleen overleggen met andere aanvallers en hun eigen manager hebben? Dat voetbalteam gaat niet ver komen. Maar een dergelijke ineffectieve organisatie van een team is op dit moment de norm in de IT. Echter, voor ieder team moet de focus liggen op het gezamenlijke doel.

(Kunnen) beantwoorden aan de vraag van de klant
De klant wil de gehele scope binnen budget, zonder verrassingen in planning en budget. Wat houdt dat in voor het team?
• Iedere stap moet de juiste zijn.
• Er moet keer op keer kwaliteit worden geleverd, gereed om in productie te nemen.
• En dat alles als een herhaalbare vorm van dienstverlening.

Hoe bereik je dat? Anko laat een plaatje zien van de zaken die een team zoal uitvoert in een iteratie.

Als iedere stap de juiste moet zijn, mag er geen ruimte zijn voor verschillen in de interpretatie van de requirements. Dus: Requirements == Test cases. De meest voor de hand liggende implementatie daarvan, is ATDD (Acceptance Test Driven Development).

Ten aanzien van unit- en integratietesten geeft hij aan dat dáár de solide basis voor het borgen van de kwaliteit van het systeem moet liggen. Dit biedt goede mogelijkheden voor het bundelen van testkennis en vaardigheid in het automatiseren van testen.

Exploratory Testing vormt een aanvulling op de unit- en integratietesten. Geautomatiseerde tests zijn feitelijk checks en die vangen alleen verwachte fouten; systemen en gebruikers gedragen zich veel minder voorspelbaar. Mogelijke fouten betreffen niet alleen de functionaliteit, maar bijvoorbeeld ook usability en security. Overigens geldt voor die kwaliteitsattributen dat er veel winst behaald kan worden als een bouwer beschikt over een goede checklist. Een tester kan hier veel waarde toevoegen door zijn kennis te delen.

Continue acceptatie
Pas als een klant werkende software ziet, kan hij informele feedback geven (en beter formuleren wat hij nodig heeft). Er moet sprake zijn van informele acceptatie (feedback) van de klant, lang voordat het moment aanbreekt voor de formele acceptatie (bevestiging). Zo niet, dan wekt het leuren om een handtekening weerstand op, met mogelijk vertraging in het project tot gevolg. Gun de klant de tijd om mee te groeien in het proces (‘emotional acceptance’), en geef gehoor aan zijn of haar feedback door enkele aanpassingsverzoeken te honoreren, dan wordt de acceptatie aan het eind een formaliteit.

Communicatie
Vervolgens begint Anko met een aantal quotes ten aanzien van het omgaan met mensen:
• Communicatie is: zo dicht mogelijk langs elkaar heen praten: ga er van uit dat er altijd ruis op de lijn zit.
• Het gaat niet om wat je zegt, maar wat de ander begrijpt: pas je communicatie aan aan de luisteraar.
• Begrijp eerst voordat je begrepen wilt worden: luister meer dan dat je zendt.
Voor het overdragen van kennis komt Anko met enkele termen (faciliteren, onderwijzen, laten zien, samenwerken), die veel overeenkomsten vertonen met het leermodel van Kolb. Hoe leren mensen: denken en voelen, kijken en doen. Vaak is het een combinatie van die dingen, dat het beste werkt.

Ergo: faciliteer als tester het leren van je teamleden en wees zelf ook bereid om iets van hen op te steken. Durf dingen te doen buiten je eigen vakgebied, doe dingen samen, en durf te falen.

Vragen uit de zaal:
Q: Anko, in het plaatje stond ATDD overlappend geplaatst, deels vóór en deels tijdens de iteratie. Was dat bewust zo gedaan?
A: Jazeker. Er zal wat voorbereidend werk gedaan moeten worden. Beslist geen big design upfront, maar wel genoeg voor de gezamenlijke beeldvorming van het team. Als de teamleden voldoende duidelijk weten wat ze moeten doen (d.w.z. aan het begin van de iteratie zijn de requirements Ready), dan kunnen ze commitment afgeven.

Q: Waar zitten de testen van nonfunctionals, zoals performance en security?
A: Die heb ik bewust uit het plaatje gelaten, maar ze behoren wel zoveel mogelijk binnen de iteratie. Wellicht doe je een lichtgewicht variant binnen de iteratie. Alle controles die je uitstelt, zullen resulteren in late feedback en mogelijk tijdrovende herstelwerkzaamheden.

Presentatiemateriaal
Beide sprekers hebben hun presentaties met ons gedeeld door ze online te zetten. Zie de hyperlinks hieronder.
Presentatie van Gojko Adzic
Presentatie van Anko Tijman

Aankondiging
De volgende InnoveerJijMee sessie in deze reeks zal gehouden worden op dinsdag 19 april. Sprekers zullen dan zijn: Jurgen Appelo (auteur van Management 3.0) en Remi-Armand Collaris (Ordina; auteur van 3 boeken over RUP Op Maat / ScrumUP).

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, Presentaties. Bookmark de permalink .

Een reactie op InnoveerJijMee met Gojko Adzic en Anko Tijman

  1. Anko zegt:

    Jullie reacties zijn welkom!

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