Blogreeks Polteq 5/6: Architectuur: niet aanraken, levensgevaarlijk! ->Beschouwing.

Op 2 oktober is de vijfde blog in de reeks van zes blogs van Polteq gepubliceerd.

Zoals eerder aangegeven, zal ik deze keer ook een analyse presenteren. Over het algemeen ben ik het eens met de geformuleerde stellingen. Ik zou echter graag een aanvullende opmerking willen maken:

Het feit dat een organisatie terughoudend is om legacy-code aan te raken, kan direct verband houden met de kwaliteit van het testproces! Hier zijn enkele essentiële overwegingen:

1. Het gebruik van adequate requirements: Is de organisatie in staat om goede requirements op te stellen en worden deze bijgehouden wanneer ze veranderen? (CRUD administratie)

2. Testdekking van de requirements: Worden alle requirements op een systematische wijze getest, zodat het duidelijk is welke (regressie)tests overeenkomen met welke acceptatiecriteria of requirements?
Bijvoorbeeld: Automatiseringstest #1: test requirement nummers 3, 15 en 416.
Het is van belang om eerlijk te zijn tegenover de organisatie over haar positie in dit opzicht. Hebben we het zo ingeregeld, of niet? Het is zwart/wit.

3. De uitdaging van legacy-code:
Stel, er is daadwerkelijke testautomatisering voor legacy-code die requirements test.
Hier kan een significant probleem ontstaan,
Voorbeeld: Requirement 416 stelt dat wanneer een 5 wordt ingevoerd in het eerste invoerveld van scherm 1 en op 'submit' wordt gedrukt, er √9 moet verschijnen.
In 2007 begreep iedereen deze vereiste en was alles duidelijk. Maar na verloop van tijd -en de groei van de monoliet- kan niemand zich meer herinneren waarom requirement 416 tot √9 moest leiden.
Dit is in het bijzonder het geval wanneer dit werd ontwikkeld in de watervalmethode, waarbij alles uitgebreid werd beschreven in technische ontwerpen (T.O.'s) en functionele ontwerpen (F.O.'s) en later is overgegaan op Agile.

Het is belangrijk op te merken dat in de Agile Scrum-methodologie vaak niet wordt gewerkt met traditionele requirements, maar eerder met User Stories en soms andere varianten zoals probleembeschrijvingen. Het kan soms een hele Sprint duren voordat een User Story volledig wordt begrepen.
(Terzijde: Zelfs als tester kun je meemaken dat iemand een Demo geeft van de opgeleverde functionaliteit en pas dan vallen er kwartjes van de (echte/volledige) werking.)
In een dergelijke situatie is het vier maanden later al vaak niet meer duidelijk welke geautomatiseerde tests welke requirements testen en/of de resultaten daarvan juist of onjuist zijn, laat staan jaren later.

Kortom, de terughoudendheid om legacy-code aan te passen is niet altijd toe te schrijven aan onwil of onvermogen, maar eerder aan de complexiteit en vaak verwarrende aard van de vereisten en tests binnen een evoluerende ontwikkelomgeving.
De programmeercode is wel leesbaar, dat is niet altijd het belangrijkste punt, maar de context van destijds is kwijt geraakt.
In veel omgevingen is er zogezegd al niet een test dat "requirement 416 verifieert"
en/of als deze er al wel is en NA de code aanpassing rolt ⚅ er een ANDERE waarde uit...

​-> "Geen idee of deze binnen de marges valt, maar √9 is de uitkomst niet meer!".
Het effect is nog meer reden voor: niemand durft het nog te wijzigen!

---