Belangrijk

De Multi-team mindset richt zich op de integratie tussen applicaties. Testen tussen applicaties resulteert inherent in veel complexiteit. Je focus in deze mindset is onderhoud. Elke test die je in deze mindset maakt, moet zoveel mogelijk waarde creëren met zo min mogelijk onderhoud. Houd daarom je tests en testdata eenvoudig. Deze eenvoud voorkomt dat je verdrinkt in de inherente (onderhouds)complexiteit van multi-team testen.

Problemen

Zelfs met alle focus op onderhoud, is dit je grootste probleem. Het probleem is inherent aan het testen met meerdere teams in een gedeelde omgeving. Het betrekken van meer teams in de gedeelde omgeving vergroot de testcomplexiteit exponentieel. Je ondervindt minder problemen als je minder teams betrekt in je keten.

De onderliggende reden voor de exponentiële toename in complexiteit is dat je tests (of testdata) zijn verspreid over meerdere teams. Je bent afhankelijk van de andere teams om je tests te laten slagen. Elk team heeft zijn eigen prioriteiten, die zelden overeenkomen. Het afstemmen met andere teams maakt het tijdrovend om dingen te bereiken. Bovendien, gedeelde omgevingen hebben vaak te maken met performance problemen vanwege zwakke serverhardware. Bij het maken van tests maak je je vaak niet druk over hun snelheid, wat resulteert in nog meer performance problemen.

Dan is er de olifant in de kamer: stabiliteit. Gedeelde omgevingen zijn vaak onstabiel omdat teams meerdere keren per dag niet-geteste versies van hun applicatie releasen. Omgevingsproblemen krijgen ook geen prioriteit, waardoor ze blijven liggen en gaan etteren.

Tools & Technieken

Het is verstandig om te starten met Risk-based Testen. Beoordeel je risico’s en schrijf je tests op basis van de risico-tot-onderhoud verhouding. Elke test die je schrijft, moet een hoge risico-tot-onderhoud verhouding hebben. Vergeet bij het beoordelen van de onderhoudslast de testdata niet. Data veroorzaakt vaak de grootste onderhoudslast van dit soort tests.

Beperk actief de scope van je tests. Je kunt de scope beperken door de omvang van de gedeelde omgeving te verkleinen (bijv. minder teams) of door het aantal tests te verminderen. Probeer niet alle onderdelen met alle teams te testen.

Een paar algemene adviezen:

• Houd elke test die je schrijft zo onderhoudbaar mogelijk. Hetzelfde geldt voor testdata.
• Houd je gedeelde omgevingen zo klein mogelijk. Meer teams betrekken stelt je in staat om iets meer te testen, maar vergroot de onderhoudslast exponentieel. Meestal is het de moeite niet waard.
• Communiceer actief met andere teams in de gedeelde omgevingen.
• Prefereer API-tests over GUI-tests omdat ze makkelijker te onderhouden en te debuggen zijn.
• Bij het schrijven van API-tests, houd je aan tools in een van de volgende categorieën:
  • Geschreven in een programmeertaal
  • Gemaakt in een applicatie zoals Postman, ReadyAPI, enz.
• Bij het schrijven van GUI-tests, gebruik alleen tools waarbij je tests schrijft in een programmeertaal.
• Pipelines zijn super om je tests periodiek uit te voeren. Een continuous integration pipeline kan ook een goed idee zijn.
• Houd bij het gebruik van pipelines rekening met omgevingsinstabiliteit. Mensen zullen een pipeline met willekeurige fouten na een tijdje negeren. Automatisch opnieuw draaien van falende tests kan helpen om de betrouwbaarheid van je pipeline te verbeteren.

Positie in het model

Met de multi-team mindset automatiseer je niet veel tests. In plaats daarvan focus je je op tests die veel waarde toevoegen met minimale onderhoudslast. De gebogen rechterrand van de Multi-team mindset laat ons zien dat we minder tests uitvoeren als we meer teams betrekken in de gedeelde omgeving. Je kunt veel testen met veel teams, maar de onderhoudslast wordt dan te groot worden. Als je meer wilt testen, haal dan teams uit de gedeelde omgeving. Als je het laatst overgebleven team bent in de omgeving, gebruik dan de Cherry-pick mindset.

Voorbeeld uit de praktijk

Een kort verhaal volgt over hoe een aantal teams de Multi-team mindset gebruikten in een bedrijf met ongeveer 45.000 werknemers (volgens LinkedIn). 8 teams werkten aan de Customer Relation Management applicatie. Alle klantgerichte medewerkers (ongeveer 10.000 per dag) gebruikten deze applicatie dagelijks. De applicatie was ook een belangrijke gegevensbron voor meer dan 30 andere applicaties in de organisatie.

Deze kritieke applicatie werd elk kwartaal gereleased. Elke release vereiste zeven weken handmatig testen. Drie weken voor end-to-end tests en vier weken voor acceptatietests. De organisatie wilde versnellen en vroegen de teams om elke twee weken te releasen.

De teams pakte alle handmatige testflows en automatiseerden ze in de GUI. Deze end-to-end GUI testsuite stelde hen in staat om elke twee weken te releasen. Ze probeerden de multi-team mindset te gebruiken, maar belandden te ver naar rechts en te ver naar boven in het model. Ze hadden problemen met release coördinatie met andere applicaties, teststabiliteit, testduur en andere zaken.

Na het bereiken van de mijlpaal van de tweewekelijkse release, wilden ze meer. Waarom niet elke week? Of elke dag? Misschien zelfs elke story? Om dit te bereiken, moesten ze testen zonder andere applicaties en minder van hun eigen teams betrekken (omlaag bewegen in het model). Om te testen zonder andere applicaties, veranderden ze hun manier van werken. Ze begonnen niet aan een story totdat andere applicaties klaar waren voor de verandering. Na de aanpassing gaven ze andere applicaties één dag om tests aan hun kant uit te voeren in een gedeelde omgeving. Dit verplaatste de verantwoordelijkheid van het testen van andere applicaties naar de teams die die andere applicaties beheerden.

Ze moesten ook minder onderdelen testen met de Multi-team mindset (naar links bewegen in het model). Dit deden ze door veel testinspanningen te verplaatsen naar de Cherry-pick mindset en de Everything mindset. Ze gebruikten de Multi-team mindset alleen wanneer een wijziging een ander team zou kunnen beïnvloeden. Alle andere tests werden in isolatie uitgevoerd.

Na al deze inspanningen en veranderingen eindigden ze met een duurzame manier van werken met de Multi-team mindset. Deze aanpak vereist ook andere testsuites die de Cherry-pick of Everything mindsets gebruiken. Na al deze veranderingen konden de teams zo vaak releasen als ze wilden.

Conclusion

De Multi-team mindset gaat over testen in kleine gedeelde omgevingen met je buren. Testen in dezelfde omgeving met meerdere teams verhoogt je onderhoudslast en is slecht voor de teststabiliteit. In de Multi-team mindset streef je naar maximale waarde met minimaal onderhoud. Maak alleen eenvoudige tests waarvan je de onderhoudslast kunt dragen.

Hoe groter de gedeelde omgeving, hoe meer je last zult hebben van slechte stabiliteit en performance. Grotere omgevingen verhogen ook de onderhoudslast exponentieel. Houd gedeelde omgevingen daarom zo klein mogelijk. In de praktijk zijn de gedeelde omgevingen vaak veel te groot. Als je twijfelt, maak je gedeelde omgevingen dan kleiner.

De Test Automation Roadmap is een model dat bestaat uit vijf verschillende mindsets:

• First steps 👣
• Cherry-pick 🍒
• Everything 🚀
• Multi-team 🤝
• Enterprise 🌍