Het V-model, Back to the future

Samen met Egbert Bouman en Jan Jaap Cannegieter heb ik een thema avond voor Testnet verzorgd met betrekking tot het V-model.  Ieder presenteerde zijn eigen variant op het V-model. De centrale vraag was of het V-model nog wel van toepassing kan zijn in deze moderne, snel wijzigende markt. Mijn conclusie is dat het V-model nog steeds springlevend is en met wat creatief denkvermogen in veel situaties nog goed van toepassing kan zijn.

Zelf heb ik een variant gepresenteerd op het V-model om het moment van de aanwezigheid van documentatie en resources inzichtelijk te maken. Deze variant is niet nieuw. Zo’n 15 jaar geleden heb ik deze variant bedacht om problemen in een project op te lossen. In dit project liepen de emoties nogal hoog op. Een deel van het project had de eis neergelegd dat alle documenten vanaf de start van het project beschikbaar moesten zijn. Natuurlijk is dat niet reëel te noemen maar overtuig de mensen maar dat het ook anders kan!  Ik heb lang nagedacht hoe je de betrokkenen duidelijk kon maken dat dit niet nodig was. Aan de hand van het double V-model van Paul Gerrard kreeg ik het idee van een tripple V. Wat houdt deze tripple V nu eigenlijk in? Het double V-model zet naast iedere ontwikkelstap een mogelijke teststap. Dat kan een review zijn maar ook bijv. een systeemtest. De derde V die ik er naast had geplaatst was, wanneer je bepaalde documenten nodig had in het project.  Op deze wijze werd al snel duidelijk dat je bijv. geen werkinstructies nodig hebt op het moment dat je nog aan het nadenken bent over de requirements.

Op dezelfde wijze kun je snel aangeven wanneer je bepaalde resources nodig hebt. Daarbij blijkt dat  je in de opstartfase van een project  juist heel veel verschillende type resources nodig hebt.  De aard van de betrokkenheid verandert in de loop van het project.

Onderstaande figuur geeft een overzicht van de tripple V-variant:

Door op deze wijze de benodigde zaken inzichtelijk te maken kon ik de discussie indertijd snel en effectief beëindigen.  De vraag is natuurlijk, is een dergelijke toepassing in de hedendaagse ontwikkelmethodieken nog toepasbaar. Ik kan daar een volmondig” JA” op geven. In een agile omgeving zet je de juiste mensen bij elkaar en bepaal je gezamenlijk welke documentatie noodzakelijk is om de release/project tot een succesvol einde te brengen. 15 jaar geleden heb ik dat gedaan met het V-model als kapstok.  Je kunt je afvragen wat er daadwerkelijk nieuw is onder de zon? Dat brengt voor mij mee dat het V-model nog steeds springlevend is en goed toepasbaar in diverse situaties. Kortom, back to the future!

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!