Testverbetering als 1 organisatie

Stel je werkt voor een bedrijf met meer dan 1 ontwikkelteam. En elk team test anders. Andere tools, andere processen. Je organisatie wil dat veranderen. Allemaal dezelfde tools, allemaal een zelfde manier van werken. En jij krijgt de opdracht dit voor het testen als geheel of voor een testonderwerp te regelen. Hoe pak je dit aan? Maar vooral: hoe pak je dit niet aan? Om dit goed aan te pakken, wil ik eerst een vooroordeel de wereld uit helpen. Bedrijven willen vaak gezien worden als 1 organisatie en niet als een organisatie, bestaande uit verschillende teams. De veel gevolgde manier om dit te bereiken is gelijktrekken van tools, processen en taalgebruik. Er is niets mis met gelijktrekken van tools, processen en taalgebruik. Dit kan zorgen voor betere samenwerking tussen teams, meer vrijheid in het indelen van teams, kostenbesparing en een algehele verbetering in efficiëntie, effectiviteit en kwaliteit. Maar wat het niet doet, is losse teams omvormen tot 1 organisatie. Helaas is dit wel een voorwaarde om het gelijktrekken te bereiken. Je kan iemand dwingen een proces te volgen en zolang je dat tot in detail controleert, zullen ze het volhouden. Maar als ze er zelf niet achterstaan, zelf niet in geloven, dan zal dit veranderen zodra jij deze tijd niet meer kan vrijmaken. Bij het eerste de beste obstakel zal gezegd worden "We zeiden het toch: Dit werkt niet bij ons". 1 organisatie is niet een organisatie, die hetzelfde werkt. 1 organisatie is een organisatie, die hetzelfde wil werken. Hoe bereik je dit? Om dit duidelijk te maken, zal ik gebruik maken van een onderwerp waar ik zelf veel kennis van heb, vooral van het invoeren: testautomatisering. Stel je organisatie heeft 10 teams. Nu heb jij de opdracht om testautomatisering in alle teams in te voeren. Een veel gevolgde aanpak: pak het probleem per team aan. Doe eerst team 1, dan team 2, dan team 3. Deze aanpak verkleint je kans op slagen enorm, als dit ook inhoudt dat alle andere teams geen enkele betrokkenheid hebben bij de testautomatisering, totdat zij aan de beurt zijn. Ik weet niet of jij ooit iemand heb gesproken, die jou precies verteld hoe je moet gaan werken en wat je moet veranderen, terwijl die persoon nog nooit eerder enige interesse in jou of je team heeft getoond. In de meeste gevallen is dan de eerste reactie: "Wie denk je wel niet dat je bent?". Wat zich later vertaalt in "Dit gaat voor ons niet werken, want wij zijn anders.". Het is belangrijk dat elk team vanaf het begin betrokken wordt bij de verbetering. Daarom is het in de "ontwerp" fase van belang dat elk team zijn input kan geven en dat deze input ook zichtbaar is in het eindresultaat. De "ontwerp" fase is de fase waar bepaalt wordt in welke stappen de verbetering ingevoerd wordt, maar ook met welke tools gebruikt gaan worden en welke processen gaan veranderen. Zorg ervoor dat elk team de gelegenheid heeft de volgende vraag te beantwoorden "Gaat dit werken voor mijn team?". En als het antwoord is: "Nee, want...", neem die problemen serieus. Neem die problemen op in je plan. Noem ze minimaal als risico. Maar als het mogelijk is: geef aan hoe je het probleem op wil lossen. Dan komt het invoeren. Hoewel de neiging groot zal zijn om je te richten op 1 team, is dit niet verstandig. De verbetering wordt voor de andere teams dan "een verhaal van een andere wereld". Tegen de tijd dat een ander team aan de beurt is, ben je de bij de "ontwerp" fase gecreëerde betrokkenheid en draagvlak alweer kwijt. Het is zeker niet erg om 1 team de meeste tijd te geven, maar vergeet de andere teams niet. Zorg ervoor dat er bij elk team gewerkt wordt aan een obstakel, dat de verbetering in de weg staat. Dit zal ik aan de hand van de testautomatisering wat duidelijker maken. Testautomatisering is meer dan starten met het maken van automatische testen. Maar dit is vaak wel de grootste klus, waar mensen veel hulp en ondersteuning bij nodig hebben. Maar er moet ook een goede, stabiele testomgeving zijn. Men moet in staat zijn goede regressietesten te schrijven. De testdata moet op orde zijn. Gevonden bugs moeten snel opgelost worden. Bevindingen moeten goed en snel worden geanalyseerd en beschreven worden.Enz. Enz. Enz. Veel van deze verbeteringen zijn ook verbeteringen, die handmatig testen ten goede komen. Maar ze vragen zeker niet allemaal evenveel tijd en begeleiding. Zorg ervoor dat elk team bezig is met een verbetering, die nodig is voor een goede testautomatisering. Om ervoor te zorgen, dat dit je niet veel tijd kost, kan je de teams zelf laten kiezen welke verbetering voor hun het belangrijkste is. Als zij mogen werken aan de verbetering, waarin zij de meeste resultaten zien, zal er nauwelijks controle nodig zijn. De motivatie om door te zetten zal bijna automatisch aanwezig zijn. Je hoeft er alleen voor te zorgen, dat je beschikbaar bent voor problemen, waar de teams zelf niet uitkomen. Bijvoorbeeld omdat ze de kennis nog niet hebben of omdat ze geld, tijd of mensen nodig hebben. En als laatste de communicatie. Goede communicatie over verbeteringen is belangrijk. Als je meetings houdt of informatie rond stuurt, houdt je dan altijd aan de volgende regels: * Zorg ervoor dat je van elk team een succes noemt * Zorg ervoor dat je voor elk team de veranderingen op korte termijn voor dat betreffende team noemt Dit geeft het laatste steuntje in de rug. Je laat merken, dat je niet alleen met mensen praat, maar dat je ook echt naar ze luistert. Dat wat zij vinden belangrijk voor je is. En dat wat er met ze gebeurt belangrijk voor je is. Dat jij ze deel vindt van die ene organisatie. Testverbetering door verschillende teams heen bereik je door alle teams bij de testverbetering te betrekken. Door ze te betrekken bij het opstellen van het plan over de testverbetering. Door ze in een vroeg stadium te laten meewerken in de testverbetering. En door te laten merken, dat ze belangrijk voor je zijn. Hun kennis telt, hun mening telt en zij tellen zelf zeker ook!