Een korte geschiedenis les

Als er een vakgebied aan enorme ontwikkelingen onderheving is geweest, is het wel het ontwikkelen van systemen. Om te begrijpen waar de ontwikkelingen vandaan komen beginnen we bij het begin en gaan we met grote stappen door de tijd heen om te eindigen in 2017.

Versie 0.1 – Ad-hoc

Tot medio 1970 vande vorige eeuw was er eigenlijk gesprake van een gestructureerd proces er waren mensen in de bedrijfsvoering die affiniteit hadden met wiskunde en gestructureerd problemen oplossen en deze mensen waren instaat om de eerste computers van zinvolle invoer te voorzien. Zij hadden een probleem en wouden dat op een automatische manier tot een oplossing komen. Er was nog geen IT-department, Analisten, Programmeurs en Testers waren er nog niet.

Versie 1.0 – Linear

Medio de 70-er jaren van de vorige eeuw werd door Winston Royce een beschrijving LAD-1gedaan van een fabrieksmatige wijze van het realiseren van informatie verwerkende systemen. Hij deed dit in het paper: Managing the development of Large Software systems. Dit paper is geschreven in het opdracht van het DoD (Depart of Defense) in Amerika. Het jammere is dat we niet verder zijn gekomen dan het tweede plaatje in het document en dat werd de born voor een manier van werken zoals we dat nu het Waterval model noem. Een strikte scheiding tussen IT en bedrijfsvoering en een strikte scheiding tussen de afzonderlijke activiteiten. Naar mate de tijd vorderde merkten we dat deze manier van werken niet goed aansloot bij de realiteit. Veel projecten faalden en leverden vaak niet op tijd op dan wel overschreden het budget met tientallen procenten.

Kenmerkend voor deze manier van werken is dat elke fase afgesloten werd met een dik pak papier wat als input diende voor de volgende fase, er waren maar een beperkt aantal projectleden die contact hadden met de opdrachtgever, laat staan met mensen die later gebruik maken van het ontwikkelde systeem. Aan het begin worden de eisen van het systeem in een contract vastgelegd en elke verandering van de eisen wordt gevolgd door een stevige contract discussie. Pagina 3 van 7

Versie 2.0 – Iterative

Medio Jaren 90 van de vorige eeuw waren er een stel IT-goeroes die vonden dat deze manier niet meer aansloten bij de huidige tijdsgeest. En stelden een aantal regels op die we nu kennen als het Agile Manifesto. Kenmerkend voor deze manier van ontwikkelen is dat er in kleine tijdseenheden systemen worden ontwikkeld waarbij er een hoge participatie is van uit de gebruikers organisatie.

Alle eisen worden aan het begin gerangschikt op added-value en als er in de loop van tijdAgile1 extra functionaliteit gerealiseerd dient te worden of functionaliteit niet gerealiseerd hoeft te worden dan wordt dit aan de work- load toegevoegd of ervan afgehaald. Kwaliteitszorg is een integraal onderdeel van het voorbrengingsproces net als alle ander activiteiten die een bijdrage leveren aan de realisatie van het systeem. En we kiezen er voor om het technisch beste product te realiseren binnen de gegeven tijdlijnen en alleen die activiteiten te doen die bijdragen aan het doel.

We kiezen er voor om niet langer tegenover elkaar te staan maar om met elkaar samen te werken.

Versie 3.0 – Continuous

Werkten bij Versie 2.0 de business en de IT-afdeling al nauw samen toch had IT-operations nog steeds het gevoeld dat er systemen over de muur werden gekegeld en dat zij geen grip hadden op wat er precies in beheer genomen diende te worden. Door IT-operations bij het Agile project te integreren ontstond de derde versie van systeem ontwikkeling: DevOps. Nauw verweven met het DevOps verhaal zijn de principes van Continuous Delivery.

DevOps heeft een aantal drivers:DevOPs1

1. Verhoging van de kwaliteit;

2. Reductie van de totale IT-kosten;

3. Verbetering van Gebruikerservaring;

4. Reductie van de complexiteit;

Toch staat een deel van deze drivers haaks op de ervaring en uitingen die gedaan worden in de markt. Want ook al heeft DevOps als driver de kwaliteit van de systemen te verhogen, Pagina 4 van 7

maar hoe valt dat te rijmen met de uitingen van bezoekers van DevOps Conferenties dat testers overbodig zijn. Ondanks de kritische verhalen uit sommige hoeken moet ook vermeld worden dat er enorme winsten in het voortbrengingsproces te behalen zijn.

Dit wordt gestaafd door het State-of-DevOps 2017 onderzoek.

Enkele kentallen:

 Teams die meermaals een werkend systeem opleveren in een week leveren gemiddeld tot 46x vaker op;

 Bij deze teams wordt vaak binnen een uur een update van de code-base gedaan, wat hun in staat stelt om 440x sneller een oplevering te kunnen doen;

 Deze werkwijze stelt dit soort teams in staat 96x sneller te herstellen van een productie verstorend incident, door dat zij sneller een rollback kunnen doen;

 Doordat deze teams automatisering ten gunste van hun voortbrengingsproces inzetten hebben zij:

  •  33% meer grip op hun configuratie items;
  •  27% meer testen uitgevoerd;
  •  30% vaker een deployment uitgevoerd;
  •  27% vaker een change met succes doorgevoerd.

Nu zul je denken dat DevOps alleen van toepassing is op specifieke organisatie maar niets is minder waar, wanneer DevOps op een juiste wijze wordt ingezet dan worden organisaties instaat gesteld om 2x vaker hun doelen te behalen. In vergelijking met vorig jaar is er een toename van 27% in het aantal organisaties dat zich actief bezighoudt met DevOps. Pagina 5 van 7

Dit gaf mij stof tot nadenken:

1. Is er binnen een DevOps omgeving ruimte voor testen? Ja.

2. Is er binnen een DevOps omgeving ruimte voor testautomatisering? Ja.

3. Zijn er zwakke punten binnen een DevOps omgeving? Ja.

a. Aandacht voor de keten, een informatie systeem bestaat niet meer uit een silo, maar heeft connectie met meerdere systemen of services. De integratie tussen deze systemen/services en de afstemming hier tussen is iets waar testers zich kunnen onderscheiden.

b. Om testen te kunnen automatiseren moeten deze eerst handmatig uitgevoerd worden om vervolgens gescript te worden;

c. Een regressie test is een levend iets, niet een statisch iets en zal dus moeten worden onderhouden. Ook hier kan de tester van toegevoegde waarde zijn.

Map je de uitkomsten van dit onderzoek op het State of testing onderzoek dan kom je tot de volgende kruisbestuivingen:

1. Testen worden vaker geautomatiseerd;
2. Testteams van 1 a 2 personen zijn meer regel dan uitzondering;
3. De non-functionele aspecten van systemen worden belangrijker.