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
Aan de slag. Maar hoe?
Bent u geïnteresseerd in dit onderwerp en kunt u niet wachten er meer mee te doen? Dan is mijn tip: verdiep u! Lees het boek van Katrina Clokie. En kom op 23 januari 2018 naar event ‘Bijtanken bij Bartosz’ die geheel in het teken van de ‘shift right’ zal staan. Aanmelden kan door een mail te sturen naar info@bartosz.nl
Grappig, op LinkedIn staat tevens een stukje van DKTP met titel Shift Left. Zou dat schuiven naar “Left” en “Right” gerepresenteerd worden door de lemniscaat die vaak i.r.t. DevOps wordt gebruikt?
Ik begrijp het idee over feedback uit (pre)productie, maar om nu te stellen dat dat “fast” is? Een van de sterke punten van agile development is de korte feedback loop, mede versterkt door testactiviteiten als TDD bij programmeren ATDD bij ontwerpen en accepteren. Die feedback loops samen (in elkaar vallend) geven heel vroeg veel info over de technische en functionele kwaliteit van de te leveren functie. Het betrekken van ervaringen uit productie zal zeker helpen bij het qua bruikbaarheid ontwerpen en ontwikkelen van applicaties die snel zullen worden geaccepteerd. Bedenk wel dat er altijd een geheel traject nodig is om te komen tot de MVP.
Ik krijg wel een beetje het gevoel dat we steeds meer mogelijkheden proberen te vinden om zo min mogelijk vooraf te hoeven nadenken. Achteraf corrigeren, ook op de kleinste MVP, is nog altijd “waste”!
Interessant artikel, dank! Ik kan alleen maar onderschrijven dat zaken als Canary testing “the next step” zijn in devops en agile processen. Omdat het niet evident is hoe canary-testing en -releasing te implementeren, hebben wij Vamp.io ontwikkeld. Vamp.io is opensource, en werkt samen met veelgebruikte moderne container systemen als Kubernetes, Mesosphere DC/OS en Docker, op zowel public clouds als Azure, AWS en Google als op eigen datacenters, of een combinatie daarvan. Als je zelf eens met canary-releasing wilt experimenteren is de “hello World” een perfect introductie! https://vamp.io/documentation/tutorials/