Als je een Gantt chart leest van een doorsnee softwareproject, dan kom je vaak ergens aan de rechterkant, in de buurt van de livedatum, testactiviteiten tegen. De shift-left benadering zoekt juist mogelijkheden om in een eerder stadium al testen uit te voeren. Eigenlijk heel logisch als je erover nadenkt. Hoe eerder je op zoek gaat naar problemen en foutjes, hoe makkelijker en goedkoper het is om ze op te lossen. Dat is de kern van de shift-left benadering. Test eerder en test vaker. In deze blog vertel ik je er meer over.
Wat een badkamer hiermee te maken heeft?
Vorige zomer is onze badkamer flink onderhanden genomen. Muurtjes verplaatsen, vloerverwarming erin, nieuwe vloer en natuurlijk tegelen. Wij kozen voor de optie “Wij vakantie, u hard werken”. Terwijl wij met de camper in Frankrijk waren, kregen we een telefoontje van onze hardwerkende aannemer:
- “Ik zit nog eens goed naar die tegeltjes te kijken die je in de douche wil” (o jee, wat is er niet goed)
- “En ik wil graag even overleggen” (Nou, brand maar los. Ik ben benieuwd hoe veel meerwerk dit gaat kosten)
- “Omdat ze niet plat zijn gebakken en nogal klein zijn gaat het niet mogelijk zijn om deze kaarsrecht op de muur te zetten. Je zal af en toe wat zien verspringen en hierdoor zal de voeg ook niet perfect kaarsrecht zijn.” (phew dat valt mee!!)
Voor ons was dit geen issue. De aannemer zei dat klanten soms pas achteraf problemen zien, als alles al klaar is. Best logisch dus dat hij even een belletje gaf op basis van wat hij al eerder had meegemaakt.
In de IT-wereld is het niet ongewoon dat een klant plots met een probleem komt waarbij we bijna onze ogen rollen en denken: “Kon je daar niet eerder aan denken?”. Maar dan herinner ik me dat mijn klant niet elke dag met softwareontwikkeling bezig is. Soms moet ik echt even de stap zetten om dingen uit te leggen of opties voor te leggen.
Net zoals bij mijn aannemer. Hij kon er makkelijk vanuit gaan dat ik, de klant die de tegels uitkoos, wel zou begrijpen hoe ze aan de muur zouden komen. Maar hij besloot toch nog een check te doen. Die kleine moeite van 10 minuten zorgde voor een tevreden klant en voorkwam mogelijk gedoe. Want stel je voor dat ik die tegels niet eens een beetje scheef wilde hebben? Ze waren nog niet geplaatst, dus er was nog tijd om eventueel andere tegels te kiezen. Misschien niet de makkelijkste route, maar zeker goedkoper dan later alles eraf te bikken en nieuwe tegels te plaatsen.
Shift-left benadering & badkamerrenovatie
Dit is een voorbeeld van de “shift-left” benadering bij badkamerrenovatie.. Hoe eerder je potentiële problemen signaleert, hoe makkelijker en goedkoper het is om ze op te lossen. Stel je voor dat de aannemer ons niet had gebeld en we pas na de vakantie het werk zouden beoordelen. Dan hadden we ruwweg drie scenario’s:
- Geen probleem, ik vind de tegels prachtig en die paar scheve tegeltjes had ik zelf ook al verwacht.
- Ik zie bij thuiskomst scheve tegels en de aannemer legt uit waarom dit zo is. Ik bedenk me dat hij eigenlijk wel gelijk heeft, dat het m’n eigen schuld is en ik accepteer hoe het er nu uit ziet.
- Ik vind de scheve tegels onacceptabel en wil nieuwe. Er komt discussie over wie z’n schuld dat is. Kan de aannemer niet tegelen? Hoort dit bij de tegels die ik heb gekozen? Is dit nu een bug of een feature? Aannemer heeft 3 dagen extra werk om de tegels eraf te halen en andere te plakken. De rechtzaak over wie betaalt loopt nog…
Optie 3 is waar we allemaal bang voor zijn. Bug fixen is duur en ook al kosten in software ontwikkeling de meeste bugs niet drie dagen, je zal versteld staan hoeveel tijd ze opslokken. Plus, hoe vaak deadlines verschoven moeten worden omdat problemen pas laat in het proces aan het licht komen.
Shift-Left benadering in de praktijk
Hoe werkt dit in de praktijk? Er zijn diverse voorbeelden van shift-left in de praktijk. Als software tester ben ik nogal slecht van vertrouwen. Dat wil zeggen dat als ik requirements zie, ik er niet van uit ga dat die requirements 100% kloppen. Zelfs als een klant of business analist er uitgebreid over heeft nagedacht. Het dubbelchecken van requirements kan problemen later in het proces voorkomen.
Wat ook vaak voorkomt is dat we intuïtief wachten met testen tot de gehele flow klaar is. We denken dan dat we goed omgaan met de beschikbare tijd, omdat we aan het eind zoveel mogelijk checks in een zo kort mogelijke tijd kunnen uitvoeren. Het nadeel hiervan is dat we in een laat stadium problemen tegenkomen en daardoor deadlines in gevaar komen. Daarom is het soms nodig om tegen onze intuïtie in te gaan.
Vasthouden aan principes zoals ‘Test vroeg en test vaak’ kan ons hierbij helpen.
Agile testing & shift-left
Vroeger, toen we nog in watervalprojecten werkten, hadden ze ook al de shift-left benadering ontdekt, maar ze noemden het nog niet zo. Voor iedere fase was ook een check moment ingebouwd.
Daar waar het waterval model één grote release had, heeft het agile model te maken met iteraties en meerdere oplevermomenten.
Vanwege ‘haast’ wordt het testproces bij agile nog wel eens aan het eind van de sprint gezet. Alle code klaar, dan testen. Klinkt logisch toch? Volgens het shift-left principe niet. Praktijk leert ons dat testen aan het eind vaak een haast klus is en niet volledig tot z’n recht kan komen. Het zal je verbazen hoeveel testgerelateerde taken er ondernomen kunnen worden als de code nog niet helemaal klaar staat in de testomgeving. Een aantal voorbeelden:
- Unit tests
- Code reviews
- Requirements testen
- Test driven development
- Behaviour driven development
- Automatische regressietest
Shift left = vakkundig spreiden van testactiviteiten
Hoe eerder je gaat testen, hoe eerder je mogelijke problemen opmerkt en adresseert. Soms gaat dit tegen je gevoel in, maar met de juiste principes gedeeld door het hele team komen we er wel!
Wil je meer weten over softwaretesten in de praktijk? En over de spanningen die het soms geeft tussen testers en development?
Event
Op 2 april spreek ik op TestMass 2024. Deze conferentie staat volledig in het teken van software testing. En het mooie: er zijn nog kaarten beschikbaar!
Verder lezen
- https://en.wikipedia.org/wiki/V-model
- https://www.gitguardian.com/glossary/what-is-shift-left-testing
- https://www.dynatrace.com/news/blog/what-is-shift-left-and-what-is-shift-right/
- https://en.wikipedia.org/wiki/Shift-left_testing
- https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/ee330950(v=vs.110)?redirectedfrom=MSDN
- https://www.drdobbs.com/shift-left-testing/184404768
