Fast feedback betekent testen in productie

Testen is nooit een doel op zich. Softwarekwaliteit is dat wel. Daarom streven we naar Quality Infected Teams. In zijn reeks blogartikelen op de site van Bartosz over dit onderwerp geeft Robert Lourens uitleg over wat we daarmee bedoelen. Eén van de zaken die Lourens aanhaalt is het belang van fast feedback: snelle feedback stelt het ontwikkelteam in staat om agile te zijn. Op basis van feedback kan worden bijgestuurd in de ontwikkeling van het product.

Vaak wordt bij fast feedback gedacht aan het voorkomen van fouten. Maar er is meer! Binnen fast feedback signaleren we de trend ‘shift right’: het gebruik van ervaring uit productie bij de ontwikkeling van het product. In deze blog ga ik in op een aantal verschillende manieren van verzamelen van feedback in productie.

Fast feedback is niet nieuw

Het gebruik van feedback uit productie binnen softwareontwikkeling is uiteraard niet nieuw. Zoals bij veel ontwikkelingen is het wel zo dat het combineren van bestaande zaken kan leiden tot vooruitgang. Agile-ontwikkelmethoden leveren door de kort cyclische aanpak de mogelijkheid om keuzes ten aanzien van het product continu bij te stellen. De DevOps manier van werken brengt de wereld van de developer en de operations engineer bij elkaar. En met de opkomst van continuous delivery en continuous deployment kunnen continu kleine wijzigingen aan het productiesysteem worden doorgevoerd, waarbij de DevOps aanpak het eenvoudiger maakt om te leren van hoe het systeem gebruikt wordt.

Quality infected teams kennen de waarde van snelle feedback. We hebben het dan ook steeds meer over feedback engineers, in plaats van over agile-testers. De feedback engineer voorziet het ontwikkelteam continu van waardevolle feedback over de status van het product onder ontwikkeling.

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 procent 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 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…

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 de 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 de 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 zijn 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 u 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.

Maarten Piepers, manager bij Bartosz ICT