Als je een beetje thuis bent in de wereld van softwareontwikkeling en softwaretesten kan het je niet ontgaan zijn. Je moet shiften! De één roept: “shift-left en je bent alle problemen voor.” De ander roept: “shift-right en je kunt alles verbeteren.” En bij nader inzien sluiten ze elkaar niet uit, maar versterken ze elkaar. Je zou er geschift van raken.
In deze blog neem ik je mee in de wereld van het shiften. Waarom willen we shiften? Maar waarom blijken ook deze toverformules geen garantie voor kwaliteit? Agile teams hebben meer nodig om succesvol te blijven. Daarom vind ik shift-left testing en shift-right testing nog niet genoeg. Kortom, als je nu verder leest, kom je er misschien wel gestretcht uit, maar het biedt ook perspectief om minder gestrest te zijn.
Waarom willen we shift-left testing? Zelfs in traditionele watervalprojecten werd door testers al vaak geroepen dat ze eerder betrokken wilden zijn. Preventief werken is goedkoper dan detectief en correctief werken. Je zou dit al als een eerste oproep van shift-left kunnen interpreteren. Maar met DevOps teams en CICD-pipelines gaat shift-left toch verder. De technologie biedt steeds meer mogelijkheden om heel kleine brokjes software zo snel mogelijk te ontwikkelen en te deployen, ondersteund door testautomatisering die volledig is geïntegreerd met de CICD-pipeline. Het gaat om vroeg en veel testen; op basaal niveau en gericht op bekend gedrag van de applicatie. Om aan te tonen dat nieuwe brokjes software goed functioneren en in principe kunnen integreren met de andere onderdelen. Denk hierbij aan unit testing, contract testing en component testing.
Het shift-left principe is vooral goed in het realiseren van snelheid in de CICD-pipeline, zonder in te leveren op kwaliteit.
Waarom willen we shift-right testing? Omdat niet alles voorspelbaar is. In complexe omgevingen kan softwareontwikkeling uitmonden in een zoektocht. De kracht van preventief werken blijkt niet meer toereikend om de kwaliteit te kunnen garanderen. Dan is er meer nodig. Het snel kunnen anticiperen op veranderende of onvoorziene omstandigheden, o.a. door goede monitoring en alerting kan een middel zijn om grip te krijgen. Dit heeft ook een preventief karakter, bijvoorbeeld ingrijpen bij drempelwaarden voordat de gebruiker het merkt. Maar het testen in productie is ook een wezenlijk onderdeel bij shift-right testing om grip te krijgen op het onvoorspelbare. Denk hierbij aan A/B testing en beta testing, vormen waarmee met name in marketingcontext wordt geëxperimenteerd. Het ‘fail fast’-principe past hier ook prima bij, mits er maar goed op wordt geanticipeerd.
Het shift-right principe is goed om in een complexe omgeving met onvoorspelbaar gedrag snel te kunnen anticiperen om voldoende kwaliteit te (blijven) leveren.
Is dit dan alles? Nee, volgens mij niet. Voor agile teams in complexe omgevingen biedt shift-left en shift-right wel verbeteringen, maar nog geen garantie voor voldoende kwaliteit. Er ontstaan vaak ‘witte vlekken’. Wat is er dan aan de hand? Het artikel When Good Teams Go Wrong van Harvard Business Review (Paul F. Levy, 2001) geeft een boeiende beschrijving van een fenomeen dat ik vaak terug zie bij agile teams. Het team krijgt na aanvankelijk succes dusdanig veel vertrouwen in het eigen handelen, dat het ze ontgaat dat er om hen heen randvoorwaarden (nodig) zijn die cruciaal blijken voor dat succes. Ze missen het zicht op het grotere geheel. Het Harvard artikel beschrijft hoe het succesvolle team de eigen primaire behoeften – zoals schoon water – langzamerhand vernietigt, zonder dat hier reflectie op is. In het volgende citaat is dit kernachtig samengevat: “A team can easily lose sight of the big picture when it is narrowly focused on a demanding task. The task itself becomes the big picture, crowding other considerations out of the frame. To counteract this tendency, smart managers supply reality checks by exposing their people to the perspectives and practices of other organizations.”
Het zicht op en besef van het grotere plaatje in de context van een applicatielandschap of complexe organisatie wordt vaak een witte vlek bij agile teams. De afbakening van backlogs, de opdeling in sprints en het opknippen in kleine (voor het oog onafhankelijke) user stories leiden na aanvankelijk succes, op termijn vaak tot problemen bij grotere integraties of onvoorziene complexiteit.
Volgens mij raken we hier de achilleshiel van het agile software ontwikkelen. Het eens zo succesvolle, autonome team knalt de afgrond in. Juist de volledige focus op snel en flexibel waarde leveren, versterkt door een roep om autonomie, is een valkuil. De primaire focus op functionaliteit en gebruikerstevredenheid wint het van minder sexy onderwerpen als compliancyregels of architectuurkaders voor de langere termijn. Waarde leveren op korte termijn is niet altijd hetzelfde als duurzaam waarde creëren. Het artikel van Harvard heeft dit al in 2001 beschreven, op basis van een situatie uit de periode van 1960-1997. Dus het wordt tijd dat we gaan anticiperen op deze inzichten.
Wat dan? Naast shift-left en shift-right testing zullen we ook naar boven moeten kijken, dus shift-up! Ook agile teams moeten zich bewust zijn van hun context en het grotere plaatje. Grotere organisaties blijven worstelen met het integraal testen van complexe ketens. Om echte businesswaarde te leveren is een breder blikveld nodig dan de primaire focus van menig agile team en Product Owner. Bij frameworks voor scaling agile lijkt dit fenomeen soms aangestipt te worden, maar de focus gaat al gauw naar de processen in plaats van naar de productkwaliteit.
Met shift-up testing vraag ik aandacht voor testvariaties die anders tussen wal en schip geraken van de verschillende teambacklogs. Voorbeelden uit de praktijk zijn securitytesten en ketenintegratietesten. Maar shift-up gaat over meer dan testen alleen. Om kwalitatief goede software te kunnen leveren, waar stakeholders op durven te vertrouwen, zullen we breed moeten blijven kijken. Hoe zijn de systemen ingebed in de organisatie en in de architectuur? Wat zijn de toekomstplannen en hoe voorkom je een ondoorzichtig en gebruiksonvriendelijk versnipperd applicatielandschap? Maar ook: kunnen we het systeem vertrouwen als het gaat over compliance, privacy etc.?
Tal van kwaliteitsaspecten raken ondergesneeuwd als teams een te scherpe focus krijgen op het leveren van businesswaarde op de korte termijn. Een fenomeen dat wordt versterkt als het agile team in een flow terecht komt waarin ze worden bejubeld door gebruikers. Maar zoals de sportwereld ons leert: het is makkelijker om aan de top te komen dan om aan de top te blijven.
De uitdaging is om bij softwareontwikkeling een integraal kwaliteitsbeeld voor ogen te houden. In dit beeld zelf zit meestal ook een vorm van complexiteit vanwege tegenstrijdige belangen. Zo moet gebruiksvriendelijkheid regelmatig concurreren met security-eisen. En gebruikerswensen kunnen op gespannen voet staan met de beoogde architectuur voor de toekomst. Probeer dat maar eens weer te geven in de simpele kleurtjes van de managementporno. Het ultieme kwaliteitsdashboard laat zien of het product bijdraagt aan de doelstellingen van de organisatie.
In complexe applicatielandschappen is het bijna ondoenlijk om als agile team dit geheel goed te bestrijken. Ondersteuning aan de PO en het team is nodig om te helpen het integrale kwaliteitsbeeld transparant te krijgen en waar nodig passende maatregelen te initiëren. De kwaliteit is erbij gebaat als we blijven stretchen, niet alleen naar links en naar rechts, maar zeker ook naar boven. Kortom, ook shift-up, en dan bij voorkeur voor meer dan testen alleen. Want uiteindelijk wil iedereen kwaliteit leveren.
Nieuwsgierig geworden en wil je meer weten over testen? Neem dan contact op met Praegus – 085-1305977 / info@praegus.nl of kijk op www.praegus.nl
