ORDINA BLOGT

Samen Duurzaam Innoveren

Ordina over... Samen Duurzaam Innoveren

  • Kaspar van Dam
  • 2 mei 2014

Samen met collega's Sven van Laar en Remko de Jong de volgende prikkelende advertorial gepubliceerd in de meest recente uitgave van het Java-Magazine:

Je bent aangenomen voor een project dat in het intake gesprek fan-tas-tisch lijkt. De nieuwste technieken en tooling. “Ja, wij werken hier super agile en willen veel vaker gaan releasen dan wij nu doen” hoor je de project manager nog vol trots roepen.  Vol goede moed begin je je eerste dag, maar dan constateer je eigenlijk meteen dat de agility vooral in de definitie zelf zit en dat vaker releasen vooral neerkomt op minder vrije weekenden. Diezelfde avond zit je thuis na te denken – je kunt deze wanorde niet loslaten (herkenbaar?) – en zet je eens op een rijtje wat er allemaal beter kan. Je constateert het volgende.

Gebrek aan samenwerking, user stories zijn slecht gespecifieerd doordat ze alleen door een business analist worden opgesteld. De analist maakt uiteraard geen deel uit van het team. Als tester werk je eigenlijk nooit samen met een developer om na te denken over hoe moet worden getest en waar wat wordt afgedekt. Daarbij begint het “testen” eigenlijk altijd pas nadat de developer “klaar” is en de code heeft opgeleverd en de story netjes in “to verify ” (iemand zich ooit afgevraagd waarom dit een aparte “swimming lane” verdient?) heeft gehangen. Water-scrum-fall?

Developers voelen zich hierdoor ook niet echt verantwoordelijk voor testcode. Testers definiëren louter op logisch niveau, waarna de developer de fysieke implementatie alleen mag uitvogelen. Toen het project nog bestond uit één team ging dat ook altijd prima, maar nu we met meerdere teams op één trunk werken, begint het toch een beetje te knellen. De regressie test duurt nu een paar uur en doordat tests afhankelijk van elkaar zijn is parallel draaien helaas ook geen optie. Testcode wordt niet als productiecode behandeld, zit vol duplicatie en de tests hebben de neiging arbitrair te falen. Kan dit niet anders?

Een paar simpele ideeën. User stories worden opgesteld volgens het three amigo’s principe. Product owner, developer en tester zorgen samen voor een gemeenschappelijk beeld. De tester helpt de developer met het bepalen en schrijven van zinnige unit tests. Samen zorgen ze ervoor dat niet al het testwerk blijft liggen tot de laatste dag van de sprint. De developer helpt de tester om de geautomatiseerde testsuite clean en schaalbaar te houden. En wanneer de testsuite faalt en de deployment pipeline stil is gelegd, gaan ze direct samen aan de slag om dit probleem te fixen. De developer leert van de tester op een andere manier naar code te kijken en de tester leert van de developer hoe hij zelf kleine stukjes code kan schrijven. En dit allemaal door middel van pairing.

Grote aanpassingen? Nee. Nieuwe ideeën? Nee. En toch komen we pairende developers en testers in het wild nog maar weinig tegen. Met agile zien we de rollen binnen een team steeds vager worden. De klassieke tester bestaat niet meer. De klassieke developer ook niet. Het sleutelwoord is samenwerken.  Vanaf het allereerste begin van de sprint tot de oplevering. Elke sprint opnieuw. Samen duurzaam innoveren. Zo denken wij erover. En jij?

Over de auteur:

Kaspar van Dam

Kaspar van Dam is test(automatisering) consultant bij Ordina en adviseert collega's en klanten over vraagstukken rondom de thema's agile testing, behavior driven development (BDD), testautomatisering en meer.