Als je kijkt naar een teststrategie of soortgelijke documenten, loop je tegen een standaard Agile probleem aan. Een veel gehoorde Agile klacht is: "We werken nu Agile, maar we worden nog steeds nergens bij betrokken". En een andere veel gehoorde Agile klacht is: "We hebben sinds de invoering van Agile veel te veel meetings. Ik wil meer tijd om gewoon mijn werk te doen." Beiden komen regelmatig uit dezelfde monden. Hoe ga je hiermee om bij een onderwerp als de teststrategie? Mensen zijn vaak nauwelijks bereid hier veel tijd in te steken, maar zeer bereid om te laten weten, dat zij het anders wilden.
Om dit te bespreken, moet ik eerst een misverstand uit de weg helpen. Ik heb bijna geen invoering van Agile of Scrum meegemaakt, zonder dat mensen gingen klagen over het aantal meetings. En de meest getrokken conclusie naar aanleiding van die klachten, is dat mensen niet betrokken willen zijn. Die conclusie is in de meeste gevallen te snel. Vaak willen mensen wel degelijk betrokken zijn. Maar niet bij alles. Ze willen niet gedwongen worden om tijd te besteden aan zaken waar ze geen kennis van hebben en geen interesse in hebben. Meetings, waar ze vooral luisterend tijd doorbrengen. Als ze het al de moeite vinden om te luisteren. Wanneer je het voor elkaar krijgt een meeting te organiseren op het gebied van hun kennis of hun interesse, zal je niet snel horen klagen over "te veel meetings". Dat in het achterhoofd houdend, is het zeer goed mogelijk om tot een Agile teststrategie te komen.
Maar er is nog een probleem. Een teststrategie kan niet 100% democratisch bepaald worden. Er is namelijk een langere termijn opgelegd doel. Dit kan zijn opgelegd door hoger management, maar dit kan ook een doel zijn, dat je zelf wil bereiken. Dit doel kan niet zomaar aan de kant worden geschoven, al zou het hele team tegen zijn. Er zijn dus grenzen. En die grenzen moeten, hoe Agile de aanpak ook is, wel bewaakt worden.
Alternatieven
Een van de meest logische wijze om inspraak te geven, is om mensen de mogelijkheid geven met een alternatief plan te komen. Juist door het bovenstaand beschreven probleem rond het lange termijn doel, lijkt dit geen handige aanpak. Maar ongeacht of je dit officieel vraagt of niet, juist als je echt Agile wil samenwerken, moet je altijd open staan voor een ander idee. Juist binnen een teststrategie kan er sprake zijn van experts op een bepaald gebied, zoals testautomatisering en performance. Maar ook een testspecialist in een bepaalde applicatie kan inzichten hebben, die jij niet hebt. Bijvoorbeeld waar de grootste kwaliteitsrisico's liggen.
Meestal zullen de geboden alternatieven afgewezen worden. Ze bereiken namelijk niet het doel, dat je voor ogen hebt. Niet zo vreemd, want het alternatief is namelijk niet bedoeld om jouw doel te bereiken. Het is bedoeld om het doel van de indiener te bereiken. Juist daarom kunnen afwijzingen van een alternatief zo'n groot effect hebben. Voor je het weet, is de indiener ervan overtuigd, dat zijn of haar probleem voor jou dus niet belangrijk is. Ongeacht of dit waar is of niet.
Om de samenwerking en de betrokkenheid goed te houden, zijn goede alternatieven van de mensen om je heen van groot belang. Door hun specialisaties, die doorklinkt in hun alternatieven, wordt jouw strategie al snel beter, als je dit weet te gebruiken. Maar om bovenstaande situatie te voorkomen, is het wel jouw taak anderen een eerlijke kans te geven met hun alternatief. En dat doe je door niet alleen de oplossing te vertellen, maar ook het probleem.
Zorg dat alle betrokkenen op de hoogte zijn van de doelen, die jij dit jaar met je teststrategie wil bereiken. En vermeldt hierin welke problemen je hiermee hoopt op te lossen of te verminderen. Vooral het laatste is ook van groot belang. Het kan je doel zijn om meer de facturatie te testen. Maar als je hier niet bij vermeldt, dat je het aantal door de klanten gevonden fouten in de factuurbedragen wil terugbrengen? Dan hebben anderen veel sneller niet genoeg informatie om tot een goed alternatief te komen. Want "Meer facturatie testen" kan bijvoorbeeld ook om een performance probleem gaan. Of om layout problemen.
Je mag dan wel verwachten dat mensen, die een alternatief aanbieden, hierbij aansluiten bij de genoemde doelen en ook de genoemde problemen willen oplossen. Maar daarnaast zullen ze ook hun eigen problemen tot een oplossing willen brengen. Dit maakt het alternatief niet opeens standaard bruikbaar. Maar zelfs bij een afwijzing, is het makkelijker om het probleem van de ander te verwerken in het eindresultaat. Omdat beide voorstellen al dichter bij elkaar liggen.
Overleggen
Samenwerken is overleggen, daar is niets aan te veranderen. De meest logische Agile aanpak voor een teststrategie, is dan ook een meeting beleggen met alle betrokkenen. En omdat er veel te bespreken valt, een lange meeting beleggen. Zo een, waar veel mensen al door de lengte geen zin in zullen hebben.
Samenwerken door overleggen kan echter ook op andere manieren. Je kan thema overleggen doen, bijvoorbeeld een losse meeting voor de testautomatisering, een losse meeting voor testtools, enz. En bij deze meetings alleen de direct betrokken van deze onderwerpen uitnodigen.
Daarnaast kan je ervoor zorgen, dat alleen de mensen die willen aanwezig zijn. Dit lijkt misschien niet netjes en verstandig. Maar mensen, die verplicht zijn te komen en er niet willen zijn, zullen meestal geen bijdrage leveren aan de meeting. Dus ze de gelegenheid geven niet te komen, heeft voor beide partijen alleen maar voordelen.
Let wel op, dat het niet komen hun keuze is. Dit doel kan heel eenvoudig bereikt worden door mensen voor een vergadering optioneel uit te nodigen. Maar je kan er ook voor kiezen, dit van tevoren mondeling te bespreken. Het tweede is natuurlijk meer tijdrovend, maar geeft wel de optie om de ander ervan te overtuigen dat zijn of haar kennis in de meeting zeer waardevol zal zijn.
Daarnaast hoeft overleggen niet in een groep. Een op een meetings kosten in basis meer tijd, maar de waardering voor zo'n meeting van de ander is vaak groter. Juist door de een op een aandacht, zal de ander zich niet snel niet serieus genomen voelen. Het is makkelijker om de onderwerpen op de ander af te stemmen. En de ander zal ook sneller zijn of haar mening geven. Zeker in een omgeving waar het vertrouwen in Agile of de organisatie laag is en er in meetings weinig input is, kan juist een meeting een op een de doorbraak geven. Maar houdt wel een belangrijk nadeel in je achterhoofd: er is geen wisselwerking tussen de verschillende betrokkenen qua ideeën. Daardoor kan de kwaliteit lager zijn.
Als het vertrouwen in Agile en in de organisatie wel aanwezig is, kan je er ook voor kiezen om geen echt overleg te hebben, maar te overleggen per e-mail. Dit kan door een concreet voorstel te sturen of door vragen rond te sturen. Waarbij mensen de kans krijgen via e-mail, al dan niet aan een hele groep, te reageren. Een goed alternatief, als men wel wil overleggen, maar geen tijd heeft. Maar hierbij moet je wel iets zeker weten: iedereen aan wie je de e-mail stuurt, moet in staat zijn om het met je oneens te zijn, En wel openlijk. Als iemand nooit tegen jou heeft gezegd, dat je iets verkeerd hebt gedaan. Of dat je iets beter had kunnen doen, is dit niet de persoon om via e-mail mee te overleggen. Ongeacht de situatie, zal je eerst mondeling de samenwerking moeten verbeteren.
Het eind- of tussenresultaat
Het belangrijkste voor een goede Agile aanpak, is dat mensen zich vrij blijven voelen opmerkingen en ideeën in te brengen. En daarvoor is het van belang, dat mensen het gevoel hebben serieus genomen te worden. Maar een teststrategie is keuzes maken. Je kan niet alle problemen nu oplossen. En je kan je tijd maar 1 keer besteden. Dus regelmatig zal niet iedereen blij zijn met je voorstel of je eindproduct, hoe vaak je ook overlegd. Of nog erger, juist door de overleggen, omdat je verwachtingen hebt geschept, enkel door naar hun problemen te luisteren. De verwachting, dat je iets met hun input gaat doen. Hoe onbelangrijk het misschien ook lijkt voor een teststrategie, juist hier moet je ook aandacht aan besteden.
De belangrijkste wijze is een goed begin van je document. Beschrijf nogmaals de doelen van de teststrategie en de problemen die je hiermee wil oplossen. Als je bepaalde problemen van anderen hebt overgenomen, benoem deze dan ook. Laat al aan het begin van het document merken, dat je die problemen ook belangrijk hebt gevonden.
Besteed daarnaast aandacht aan de langere termijn. Als je teststrategie voor een jaar is, beschrijf dan ook de teststrategie voor een flink aantal jaren meer. Dit mag natuurlijk op hoofdlijnen. Niet alleen geef je hiermee belangrijke informatie aan de lezer. Je kan dit ook gebruiken om onderwerpen, waar je nu geen tijd voor hebt, alsnog te benoemen. Te laten merken dat je ze wel degelijk belangrijk vindt. Probeer ook uit te leggen waarom je dit jaar niet hebt gekozen voor deze onderwerpen, dat maakt de kans op acceptatie groter.
Pas hierbij wel op, dat je geen verwachtingen schept, die je niet waar kan maken. Iemands probleem schriftelijk erkennen is een goede stap, zelfs als je niets oplost. Maar jaar na jaar na jaar schriftelijk laten weten dat er belangrijkere problemen zijn, kan vertrouwen juist om zeep helpen.
De Agile aanpak samengevat
Er is dus een manier om op een Agile wijze tot een teststrategie te komen.
- Laat duidelijk weten wat je doelen zijn en welke problemen je op wil lossen, zodat andere makkelijker waardevolle input kunnen geven
- Plan overleggen met personen, die echt willen. Als de situatie dit toestaat of zelfs aanraad, kan dit met een op een meetings of via e-mail
- Laat in je uiteindelijke teststrategie of een voorstel hiervoor duidelijk de problemen van de ander terugkomen, als je deze inderdaad wil oplossen. Een middel hiervoor is een beschrijving van de doelen, die gaat over een langere periode dan de periode van de teststrategie.
