Gevoeligheden

Veranderen is een uitdaging waarbij vele aspecten een rol spelen. Het is af en toe dansen op het slappe koord. Je moet mee bewegen om niet te vallen maar wel koers houden om voortgang te boeken. Kortom, laveren door de omstandigheden heen.

Een punt waar je zeker mee te maken krijgt zijn de gevoeligheden die leven. Vaak volstrekt onbekend voor je maar zeker voelbaar in sessies, workshops etc.

Gevoeligheden tussen mensen. Vaak door zaken uit het verleden veroorzaakt. Gevoelige processen. Oh als je daar aan komt dan…… Ooit een keer door iemand bedacht, waarschijnlijk met veel (informele) invloed in de organisatie. Wordt dan als een heilig huisje beschouwd. Of onderwerpen waar bijvoorbeeld een maatschappelijk debat moeilijk is over te voeren. Denk aan de hypotheek aftrek. Bij iedere kabinetsformatie een onderwerp van discussie.

Betekent dit dat dergelijke situaties niet bespreekbaar meer zijn. Dat zou een lock in betekenen met als consequentie dat verandering (bijna) onmogelijk wordt gemaakt.

Ook hier doemt de vraag op wat kun je er aan doen? Hangt er vanaf hoe groot je cirkel van invloed is. Direct of indirect.

Gevoeligheden tussen mensen kun je bespreekbaar maken en uit de wereld helpen. Werkt het helemaal niet dan kun je de bezetting van je team wijzigen. Je moet de koers niet laten beïnvloeden door gevoeligheden tussen mensen. Dan ben je niet meer in staat de verandering door te voeren. Uiteraard wel goed luisteren en de signalen serieus nemen.

Krijg je met heilige huisjes te maken dan komt er iets meer bij kijken. Het is zaak dit te herkennen en steun te zoeken bij sponsors, de opdrachtgever en niet op de laatste plaats de persoon in kwestie zelf. Maak objectief inzichtelijk wat het punt is en waarom het huisje verbouwd moet worden. Zet het in het grote geheel en bovenal laat de persoon in kwestie in zijn waarde. Toon respect voor wat er neergezet is maar kies bijvoorbeeld de insteek dat de basis verbreed moet worden om te kunnen anticiperen op de toekomst.

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!