"Binnen Bartosz hebben we het dan ook steeds meer over Feedback Engineers, in plaats van over Agile testers"
Testen in DevOps
In de wereld van DevOps is het eenvoudiger dan voorheen voor het ontwikkelteam om feedback uit productie mee te nemen als input voor het ontwikkelproces. Katrina Clokie schreef recent een interessant boek, A Practical Guide to Testing in DevOps, waarin ze onder andere een helder overzicht geeft van de verschillende test practices die zij onderscheidt in de DevOps wereld. Daartoe definieert ze drie categorieën: Feedback in Production, Exposure control en Test practices in production. Ik geef van alle drie een voorbeeld.
Feedback in production
Binnen Ops is het gebruik van Monitoring en Logging tools een belangrijk middel om beschikbaarheid en continuïteit van applicaties te borgen. Er is een grote variëteit aan volwassen tooling beschikbaar waarmee eindeloos veel parameters aangaande het gedrag van applicaties, maar ook het gedrag van de gebruikers van die applicaties, inzichtelijk kan worden gemaakt. Allemaal waardevolle feedback uit productie. Deze gegevens worden gebruikt om de kwaliteit van het product te waarborgen of te verbeteren. Bijvoorbeeld door het gebruik van alerting functionaliteit op het moment dat het gedrag van de applicatie gaat afwijken of in gevaar komt. Zodat er bijvoorbeeld actie kan worden genomen voordat een harde schijf volloopt, er een crash van de applicatie plaatsvindt of er bepaalde connectiviteit niet tot stand komt.
De gegevens vormden ook altijd al een waardevolle bron aan informatie als het gaat om het verbeteren van een product: als bepaalde incidenten regelmatig optraden kon het Ops team, eventueel in overleg met het Dev team, op zoek naar het achterliggende probleem. Om vervolgens tot een change verzoek te komen zodat het Dev team verbeteringen in de applicatie kon doorvoeren. Traditioneel kwamen de wijzingen dan mee in een release (die meestal een beperkt aantal keer per jaar plaatsvond).
Het integraal gebruiken van deze Ops informatie in het Dev proces is een belangrijke stap in de Shift Right beweging, waarbij productiegegevens directe snelle input wordt voor het ontwikkelteam. DevOps werken maakt het eenvoudiger dan voorheen om dit te implementeren.
Exposure control
Het is onmogelijk om alles aan en rond een applicatie te testen. Het is een illusie om te denken dat 100% testdekking door middel van automatisering mogelijk is. En in het kort cyclische karakter van een agile traject is de tijd tussen releases steeds korter… dus waarom niet leren van de wijze waarop echte gebruikers nieuwe functionaliteit gebruiken? Dat is de basisgedachte achter de volgende strategieën.
Bij Canary releasing wordt nieuwe functionaliteit eerst aan een kleine groep van gebruikers aangeboden. Vervolgens wordt en het gebruik nauwkeurig gemonitord in productie. Hierbij wordt waardevolle informatie verzameld over het daadwerkelijk gebruik van de software. Deze informatie geeft het team de kans de kwaliteit te verhogen. Pas als de kwaliteit het juiste niveau bereikt heeft wordt de release naar alle gebruikers uitgerold. De eerste gebruikers van nieuwe functionaliteit kun je natuurlijk heel specifiek kiezen. Een voorbeeld daarvan is Dogfooding, dat uitgaat van het principe dat je als maker van een product dat product als eerste ook zelf gebruikt. Daar zitten twee interessante psychologische kanten aan. Ten eerste wekt het vertrouwen. Denk maar aan de talloze reclames die de boodschap ‘we gebruiken hem zelf ook’ bevatten. Maar ook richting de makers van het product zit er een boodschap in: realiseer je dat je het zelf ook gaat gebruiken. Zou het zo zijn dat een team dan nog meer gefocust wordt op kwaliteit? Denk bijvoorbeeld aan een bedrijf dat deursloten maakt die door software worden aangestuurd. De ontwikkelaars hebben deze sloten zelf op hun voordeuren en elke nieuwe release van de software wordt eerst uitgetest op hun sloten…
"Het integraal gebruiken van deze Ops informatie in het Dev proces is een belangrijke stap in de Shift Right beweging, waarbij productiegegevens directe snelle input wordt voor het ontwikkelteam"
Test practices in production
Als we in staat zijn om functionaliteit gecontroleerd aan te bieden aan deelgroepen van gebruikers en vervolgens het gedrag van de software te meten, zijn we ook in staat om het gedrag van de gebruiker te meten. En dat is interessant, want wellicht kunnen we dat ook meenemen in ons ontwikkelproces… Dat is waar het om gaat bij A/B testing. A/B testing is een vorm van testen waarbij een hypothese ten aanzien van het gedrag van een gebruiker in productie wordt getest. Door functionaliteit op twee verschillende manieren aan te bieden aan twee gebruikersgroepen kun je meten wat het verschil in gedrag tussen de groepen is. Denk bijvoorbeeld aan Netflix, die in haar catalogus van programma’s aan verschillende gebruikers verschillende vormen van visualisatie aanbiedt. Gebruikersgroep X ziet bij een specifieke film in de film catalogus een andere afbeelding dan gebruikersgroep Y. Netflix meet welke gebruikersgroep vaker overgaat tot het aanschaffen van die film. En leert op die manier hoe het aankoopgedrag van haar gebruikers beïnvloed kan worden.
Tijdens het ontwikkelproces constant keuzes ten aanzien van het product toetsen in productie en op basis daarvan die keuzes gericht maken is heel krachtig. Spotify past dit gegeven continu toe in de ontwikkeling van haar platform. Bij nieuwe ideeën wordt eerst een MVP (mimimum viable product) ontwikkeld. Deze wordt aan een kleine groep gebruikers ter beschikking gesteld. Binnen deze groep worden door middel van A/B testing hypotheses getoetst. Via een aanpak die Spotify ‘Measure, Learn, Adapt’ noemt wordt er net zo lang ontwikkeld totdat de keuze wordt gemaakt de functionaliteit breder uit te rollen of te laten vervallen. Deze manier van werken wordt beschreven in het boek The Lean Startup van Eric Ries. Niet eerst een uitgewerkt plan maken, maar beginnen met een simpel prototype om een aanname te testen: dat is de kern van de lean start-up-methode.
Het is interessant om je te verdiepen in verschillende manieren waarop ervaren klantwaarde gemeten kan worden. Wellicht kan het ontwikkelteam daar wat leren van de marketing wereld? Gebruik maken van dit gegeven in het ontwikkelproces kan een enorme versnelling in het leveren van klantwaarde betekenen.
Aan de slag. Maar hoe?
Ben je geïnteresseerd in dit onderwerp en kun je niet wachten er meer mee te doen? Dan is mijn tip: verdiep je! Lees het boek van Katrina Clokie. En kom op 23 januari 2018 naar onze Bijtanken bij Bartosz die geheel in het teken van de Shift Right zal staan.