Weerstand

In een serie blogs wil ik een aantal situaties met betrekking tot ketenregie en/of kwaliteitsmonitoring de revue laten passeren. Deels zijn deze gebaseerd op ervaringen opgedaan in projecten. Voor een ander deel zal het een bespiegeling zijn op actuele situaties die je in het dagelijkse nieuws ziet langskomen.

Is het volgende beeld voor jou herkenbaar?

Je werkt met zijn allen aan een project om bijvoorbeeld business processen die binnen een unit worden uitgevoerd te analyseren en daar waar nodig te optimaliseren. Je pakt dit op een Agile manier aan met multidisciplinaire teams en iedereen die een rol heeft in het businessproces heb je betrokken.

Tijdens het werk merk je continu dat er geen sfeer van openheid aanwezig is. Informatie wordt niet volledig gebracht, mensen maken zaken niet concreet, er wordt om de materie heen gedraaid of op het allerlaatste moment wordt er informatie gedeeld die het maakt dat een groot deel van het gedane werk teniet wordt gedaan.
De consequentie van dit alles kan zijn dat er onnodig veel tijd en energie verloren gaat en dat een deel van de deelnemers zal gaan afhaken. Ik kom dat helaas (regelmatig) tegen.

Het is een vorm van weerstand die mensen uiten omdat er kennelijk (ergens) een gevoel van bedreiging is. Mensen worden uit de comfort zone gehaald. Zien hun werkwijze veranderen of wellicht het werk verdwijnen. Worden uitgedaagd om daadwerkelijk hun kennis en kunde te etaleren waaruit mogelijk kan blijken dat de kennis niet echt op orde is.
Constateren is een maar wat kun je daar aan doen? Een paar ideeën.

Zorg voor een sfeer van geborgdheid. Een veilige haven waar alles op tafel gelegd kan worden. Check of de juiste mensen aan boord zijn. Vraag aan de deelnemers op welke plaats in het proces zij de werkzaamheden uitvoeren. Neem zaken niet te snel voor waar aan. Controleer iedere stap in het proces met controle vragen of het beeld / plaatje compleet is. Voer een simulatiesessie uit om daadwerkelijk het proces na te spelen en vast te stellen of er nog witte vlekken in het proces zitten.

Een aantal suggesties om met boven geschetste situatie om te gaan. Mochten er aanvullingen zijn of herkennen mensen zich in bovengenoemde situatie dan hou ik me aanbevolen voor extra ideeën.

Pakketten en testen; een vertragende factor?!

Pakketten en testen. Is dat een logische combinatie? Is het inderdaad een vertragende factor of kan het elkaar juist versterken.

Pakketten kies je om bepaalde redenen. Het gebruik maken van generieke oplossingen of standaarden vanuit de markt, onvoldoende capaciteit om zelf te kunnen ontwikkelen etc. Zo zijn vele redenen te bedenken om te werken met (standaard) pakketten. Een pakket staat niet op zich maar is geïntegreerd in het totale landschap binnen een organisatie. Het pakket vult een onderdeel van de keten in. Daarbij is het natuurlijk van belang dat de keten goed functioneert en er voor zorgt dat de klanten tevreden zijn en blijven.

Zoals bij maatwerk systemen het geval is krijg je ook bij pakketten te maken met updates t.a.v. het pakket of bijvoorbeeld andere wensen t.a.v. de inrichting door bijvoorbeeld veranderende business omstandigheden. Deze wijzigingen moeten gevalideerd worden om te voorkomen dat er allerlei ongewenste neveneffecten gaan ontstaan. De benodigde inspanning kan flink oplopen en heeft wellicht ook een repeterend karakter bij meerdere releases per jaar. Vooral als er (nog) handmatig getest wordt. De benodigde inspanning wordt mede bepaald door de omvang van een regressietest. Uiteraard is deze omvang afhankelijk van de aard van de wijzigingen.

Handmatig testen heeft een grote waarde maar is niet toereikend meer gezien de hoeveelheid updates die beschikbaar zijn, de snelheid waarmee deze geïmplementeerd moeten worden en de tijd die nodig is voor de testuitvoering.

Dan is het toepassen van geautomatiseerd testen een absolute must om het ontwikkeltempo bij te kunnen houden. Zeker gezien als je richting een DevOps situatie gaat bewegen.

Echter, bij de introductie van testautomatisering worden nieuwe uitdagingen geïntroduceerd. Testautomatisering moet herhaalbaar, herbruikbaar en overdraagbaar zijn. Het opvoeren van een bijvoorbeeld een pensioen polis met ingangsdatum vandaag is mooi en de gedefinieerde testgevallen kun je vandaag perfect uitvoeren. Alleen morgen is vandaag niet meer en dan werken je gedefinieerde testgevallen niet meer. Kortom, je testgevallen zijn niet herbruikbaar en herhaalbaar.

Wat kun je er aan doen? De oplossing is voorhanden. Zoals je een informatiesysteem bouwt op basis van een architectuur moet je testautomatisering ook opzetten onder architectuur. We noemen dat testautomatiserings-architectuur waarmee je o.a. herbruikbaarheid en herhaalbaarheid van je geautomatiseerde testen bereikt.

Door deze aanpak kun je snel en gedegen een wijziging, fix, release etc. valideren waarmee de doorlooptijd van de test en daardoor de doorlooptijd van een release aanzienlijk kunt verkorten. Je bereikt dan de situatie dat testen geen vertragende factor meer is maar een katalysator om wijzigingen snel in productie te kunnen zetten.

Wil je meer weten over het opzetten van een toekomstvaste testautomatiserings-architectuur? Kijk dan in het boek: testautomatisering wendbaar organiseren of de website https://mailchi.mp/a6bc6ba0b694/testautomatisering.

Heb je naar aanleiding van dit artikel vragen?

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Martijn. Hij denkt graag met je mee!