Bartosz, Agile, Trendsz

Volgens Bartosz is testen nooit een doel op zich. Softwarekwaliteit is dat wel. Daarom streven we naar Quality Infected Teams. In zijn reeks blogartikelen over dit onderwerp geeft Bartoszian Robert Lourens uitleg over wat we daarmee bedoelen. Eén van de zaken die Robert 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. Binnen Bartosz hebben we 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.

Binnen Bartosz onderkennen we ook de kracht van leren en experimenteren. Binnen ons innovatie platform Bartosz Labsz definiëren we innovatieve experimenten. Een recent experiment was onze Exploration Track Shift Right. Met een groep van circa 10 collega’s onderzochten we het onderwerp Shift Right: testen in productie. De kennis die we daarin opdeden delen we in een aantal blogs. Ook verzorgen we in januari een Bijtanken bij Bartosz sessie over dit onderwerp. In deze eerste blog ga ik in op een aantal verschillende manieren van verzamelen van feedback in productie die we op dit moment al kennen en gebruiken: het is namelijk niet nieuw. In een volgende blog zal een collega verder ingaan op onze toekomstvisie op dit gebied.

 

 

"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.

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Ontwerp zonder titel (19)

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz