Test engineering

Shift left en shift right zijn inmiddels ingeburgerde termen binnen de testwereld. Met shift left-activiteiten proberen we zoveel mogelijk vroegtijdig risico’s af te dekken. In de praktijk blijkt dat alle risico’s afdekken met enkel shift left-activiteiten niet mogelijk is. Zeker niet in de wereld met steeds meer autonomere teams. Er blijven eigenlijk altijd wel wat restrisico’s over. Deze restrisico’s dekken we in productie af met shift right. Spannend? Ja, want hoe doe je dat zonder het productieproces te verstoren? Feature flagging biedt hierbij uitkomst! In deze blog bespreek ik vier feature flagging toepassingen waarmee jij als tester zeer flexibel in productie de laatste restrisico’s gecontroleerd kunt checken. Lees je mee?

Wat is feature flagging?

Feature flagging – ook wel feature toggles, feature flippers of feature switches genoemd – is een techniek voor softwareontwikkeling waarmee je een feature in productie flexibel kunt inzetten. Je beïnvloedt hiermee het ‘gedrag’ van het systeem, zonder nieuwe code te deployen. Wanneer je bijvoorbeeld een nieuwe feature beschikbaar wilt stellen aan een selectieve groep gebruikers voor het verkrijgen van feedback, kan een feature flag deze toegang regelen. Daarnaast kun je met een feature flag – wanneer de feature toch niet naar behoren werkt – de feature uitzetten en na het corrigeren eventueel weer aanzetten. Feature flagging stelt je in staat om in productie bepaalde situaties uit te proberen en zo eventuele restrisico’s gecontroleerd te checken.

Vier toepassingen van feature flagging

Feature flagging kent meerdere toepassingen. Hieronder bespreek ik de vier die ikzelf het meest gebruik in de dagelijkse praktijk.

  1. ‘Kill switch’ of ‘remote configuration’

Hiermee kun je een feature op afstand aan- of uitzetten. Je zet een feature in productie, maakt het voor de gebruikers zichtbaar en wanneer het niet voldoet of als er (tijdelijke) issues zijn, schakel je de feature heel eenvoudig weer uit. Na het verbeteren, maak je de feature weer zichtbaar voor de gebruikers. Met behulp van de zogenoemde kill switch kunnen ontwikkelaars een (deel van) een feature eenvoudig, zonder opnieuw te hoeven deployen, aan/uit schakelen. Het voordeel is dat je niet de hele applicatie hoeft te stoppen vanwege een enkele niet werkende feature, of een externe koppeling.

Een variant op de kill switch, is de remote configuration. Als na het releasen van een nieuwe feature blijkt dat bijvoorbeeld de performance onvoldoende is, kan ervoor gekozen worden om de nieuwe feature aan te laten voor iedereen die hem al ontdekt heeft, en uit te zetten voor de overige gebruikers. Terwijl het probleem opgelost wordt, moet je dan natuurlijk wel blijven monitoren of de performance voor de beperkte groep die wel al toegang heeft, acceptabel blijft. Zo niet, dan kan ervoor gekozen worden om de feature voor iedereen uit te schakelen (kill switch).

3

Voorbeeld: door een nieuwe release van de creditcard feature van een mobiel bankieren app, werkt deze niet naar behoren. De bank besluit de creditcard feature uit te schakelen. Gebruikers van de app kunnen gewoon hun bankzaken blijven doen en hebben toegang tot hun lopende rekening en spaarrekeningen. Het onderdeel creditcard is tijdelijk niet zichtbaar.

  1. Geschaald releasen

Bij deze mogelijkheid geef je de feature gecontroleerd, gefaseerd vrij. Slechts een beperkte groep gebruikers krijgt de nieuwe feature te zien. Hiermee verminder je het risico op negatieve resultaten die een groot percentage gebruikers treffen. Bovendien kun je bij het ontdekken van een bug of storing, de feature makkelijk weer terugdraaien. De feedback van de groep gebruikers kun je gebruiken om de feature te verbeteren.

Zonder titel (536 x 536 px)

Voorbeeld: Een mailprogramma heeft een nieuwe versie. In eerste instantie krijgt slechts 10% van de gebruikers deze nieuwe versie te zien. De overige 90% gebruikt nog steeds de oude versie. Achter de schermen wordt gekeken hoe een gebruiker door de nieuwe versie navigeert en op basis van dit gedrag worden eventuele verbeteringen doorgevoerd. Vervolgens wordt het aantal gebruikers geleidelijk opgeschaald naar 20%, 30%, 50%, 75% en 100%. Bijkomend voordeel is daarnaast dat wanneer je bijvoorbeeld bij 90% problemen ontdekt met de performance, je heel eenvoudig weer kunt terugschalen naar bijvoorbeeld 75%.

  1. Experimenteren met (extra) features

Met A/B testing vergelijk je twee of meerdere varianten om te testen welke de beste resultaten oplevert. Je experimenteert in productie wat wel en wat niet werkt. Toon bijvoorbeeld twee varianten van dezelfde website aan verschillende gebruikersgroepen en analyseer welke variant meer conversies genereert.

2

Voorbeeld: Een webshop biedt verschillende werkende betalingsmogelijkheden aan (iDEAL, Creditcard, Klarna en PayPal). Omdat de webshop een sterke voorkeur heeft voor betalingen via iDEAL worden er drie varianten getest om deze betalingsmogelijkheid te laten opvallen. Variant 1 is iDEAL een opvallend kleurtje geven, variant 2 is een knipperende pijl plaatsen bij iDEAL en variant 3 is achter iDEAL ‘meest gekozen’ zetten. Door middel van A/B testing ontdekt de webshop welke variant het beste resultaat oplevert. Een ander voorbeeld is Netflix die bij de lancering van een nieuwe serie alleen in Australië twee verschillende covers laat zien. Er wordt geanalyseerd welke cover de meeste clicks oplevert en vervolgens wordt deze cover wereldwijd ingezet.

 

  1. Permissing flags

Met de inzet van permissing flags geef je bepaalde mensen toegang tot de nieuwe feature en anderen niet. Deze mogelijkheid is handig als je een nieuwe feature bijvoorbeeld enkel beschikbaar wenst te stellen aan een vooraf bepaalde groep gebruikers. Dit kunnen gebruikers zijn die zich aangemeld hebben voor beta releases of gebruikers die zich aangemeld hebben voor friends & family testen. Mensen die graag de nieuwste features als eerste willen met een kleine kans op onvolkomenheden.

4

Conclusie: flexibel, met vertrouwen en in control met feature flags

Feature flagging stelt je in staat om nieuwe features te releasen met vertrouwen, flexibiliteit en daarbij in controle te zijn en te blijven. Ondanks dat je met een klein risico naar productie gaat, kun je de impact voor klanten zeer beperken in het geval de feature – ondanks al het eerdere testwerk – toch niet zo functioneert als verwacht. Deze manier van werken, met iets meer risico naar productie, versnelt je ontwikkelproces aanzienlijk. Daarnaast ontvang je op deze manier snel feedback uit productie en kun je op basis daarvan je features verder verbeteren.

Er is wat lef nodig om shift right toe te passen, durf jij het aan

Sla dit artikel op óf

Deze artikelen zijn ook echt iets voor jou…

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

Ontwerp zonder titel (19)

Werken bij Bartosz?

Bekijk de Vacatures

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.

vincent.verhelst@bartosz.nl
06 22 29 84 38

Mijn Paarsz