Het testen van software bij DSO-LV

Om de uitvoering van de Omgevingswet mogelijk te maken is het Digitaal Stelsel Omgevingswet (DSO) ontwikkeld. Dit stelsel bevat een centrale ‘kern’, de landelijke voorziening (DSO-LV) met daarop aangesloten de bevoegde gezagen, burgers en bedrijven. Het geheel noemen we het DSO, de landelijke voorziening het DSO-LV. Gezagen zijn aangesloten middels software van commerciële partijen, de software leveranciers of kortweg leveranciers. Deze leveranciers zijn er in een aantal smaken, voor plansoftware, voor Toepasbare regels en voor VTH software (Vergunning Toezicht en Handhaving) en andere partijen op basis van het ‘open stelsel’. Het DSO-LV is dus het gedeelte van het stelsel zonder de commerciële leveranciers. Het DSO-LV kan direct worden geraadpleegd middels een loketfunctie.  Via het Loket kunnen burgers informatie over omgevingsplannen en regels opvragen, een vergunningscheck doen en vergunningen aanvragen.
Het DSO-LV biedt ook een aantal API’s (Advanced Programming Interfaces) waarmee leveranciers zelf applicaties kunnen maken die met het DSO-LV communiceren. Deze partijen hebben handige toepassingen gemaakt voor eigen en commercieel gebruik voor zowel bevoegd gezagen, burgers en bedrijven,

Voortbrenging DSO-LV
Het voortbrengingsproces staat elders beschreven, in deze notitie wordt ingegaan op hoe de kwaliteit van de software en componenten geborgd is. De kwaliteit wordt aangetoond door middel van testen waarbij de nadruk ligt op de DSO-LV, maar waarbij ook rekening gehouden wordt met het hele DSO als stelsel. Uitgangspunt is dat je ervan mag uitgaan dat er werkende software wordt opgeleverd, vergelijkbaar met een webwinkel en andere overheidssites. Mocht er onverhoopt iets niet werken dan kan er een melding bij het IPLO gedaan worden.
Bij de voortbrenging wordt gewerkt middels de Agile/SAFE methodiek. Binnen het DSO-LV wordt de software beheerd, gemaakt en getest door de Operatio­neel Beheer Organisaties (OBO’s) onder regie van de Tactisch Beheer Organisatie (TBO). Maken, testen en uitrollen van software gebeurt continue elke sprint (elke twee weken) voor één of meerdere componenten.

Open

Testen DSO-LV
 Om de kwaliteit te borgen en aan te tonen wordt er gedurende het realiseren in verschillende stadia getest. Dit wordt gedaan in overeenstemming met het testbeleid, dat als uitgans­punt heeft dat de OBO’s werkende software opleveren van voldoende kwaliteit. Voldoende kwaliteit is dat de afgespro­ken diensten (blijven) werken volgens afspraak. De teams zijn er zelf verantwoordelijk voor dat hun software goed samenwerkt met de software die andere teams opleveren.
Naast dat er getest wordt of de nieuwe functionaliteiten goed werken wordt ook getest of wat er al was blijft werken en nog steeds werkt zoals bedoeld (regressietesten). Ook worden testen gedaan om aan te tonen dat de software aan bepaalde eisen voldoet zoals veiligheid, performance, robuustheid, gebruikersvriendelijkheid, programmacode etc. Met andere woorden, of het ‘compliant’ is. Deze testen worden uitgevoerd door externe onafhankelijke organisaties en door de OBO’s zelf.

De OBO’s hebben een eigen verantwoordelijkheid bij het testen van de onderdelen van het DSO-LV.  Zij voeren zelf testen[1] uit in hun eigen (test)omgevingen. Binnen het DSO-LV is een omgeving die representatief is voor de productieomgeving en waar de laatste stap van de vervaardiging is dat alle componenten in samenhang getest worden over de gehele keten van interacties en samenwerkingen. Dat zijn de zogenaamde ketentesten.
Ook bij de testen gericht op veiligheid, performance, robuustheid, etc werken de OBO’s samen en voeren ze samen testen uit. Zoals een PEN-test als het gaat om security, een performance test als het gaat of de deelketens goed werken bij een bepaalde belasting in hoeveelheid gebruikers. Maar ook een backup & restore test als het gaat om robuustheid en betrouwbaarheid.

Onderstaand plaatje geeft een impressie van hoe het testen van ontwikkelde software door de keten van ontwikkeling loopt.

Testen DSO
Als de software van voldoende kwalitatief niveau bevonden wordt, wordt de software uitgerold (gedeployed) naar de productie en externe (test) omgevingen. Externe (test) omgevingen zijn omgevingen die qua software versies gelijk zijn aan productie en die een bepaald doel hebben zoals testen van aansluitingen door leveranciers en oefenen met content door de bevoegd gezagen.

De informatie die via de koppelvlakken wordt uitgewisseld is volgens bepaalde afspraken opgebouwd. Die afspraken noemen we standaarden. Als er wijzigingen nodig zijn in die standaarden dan wijzigt er meestal ook iets aan de koppelvlakken. In deze gevallen zal de DSO-LV bij de ontwikkeling samen optrekken met, in elk geval, een aantal partijen dat gebruik maakt van die koppelvlakken en de mogelijkheid geven de informatie uitwisseling eerst te testen in een externe testomgeving alvorens dit in productie wordt geïmplementeerd.

In de LeveranciersTestOmgeving (LTO) kunnen leveranciers hun testen doen om te kijken hoe het geheel samen met DSO-LV werkt.

Het Interbestuurlijk Keten Testen (IKT) helpt de bevoegd gezagen om de (werk-)pro­ces­sen te testen en zijn dus onderdeel van het testen van DSO waarbij indirect ook de software van de leveranciers getest wordt. Deze gebruikerstesten worden uitgevoerd in de pre-productieomgeving (PRE).

In uitzonderlijke gevallen, bijvoorbeeld zoals bij de hierboven genoemde koppelvlakwijziging, zal na goed overleg de nieuwe software eerst uitgerold worden in de LTO en/of de PRE zodat leveranciers en/of bevoegd gezagen eerst kunnen testen en toetsen of de gewijzigde software van DSO-LV in het DSO goed functioneert. In onderstaand plaatje is dan ook te zien dat de OBO (links) al bezig is met de nieuwe versie N+2, dat leveranciers en bevoegd gezagen (gebruikers) testen met versie N+1 terwijl in productie nog de “oude” versie N staat.

Open

Echter in de meeste gevallen is de software backwards-compatible, dat wil zeggen dat de leveranciers en bevoegd gezag nog een tijdje de oude versie kunnen blijven gebruiken alvorens over te stappen op de nieuwe versie.

Mochten er bevindingen zijn in één van de omgevingen dan worden deze vastgelegd en gezien als productieverstoringen. Het verhelpen hiervan komt als werk op de backlog (werkvoorraad). De hoogste prioriteit wordt gegeven aan de bevindingen uit de productieomgeving.

Continue Verbetering
Een belangrijk onderdeel van SAFE/Agile is dat je tijd steekt in het continu verbeteren van je proces. Dat geldt ook voor testen. Hiertoe zijn meerder testgildes actief. Een belangrijk onderdeel is, om de testen zoveel als mogelijk geautomatiseerd uit te voeren. Een ander onderdeel is het up-to-date houden van de regressietest met het aanvullen van testen van nieuwe functionaliteiten maar ook het opruimen van delen die niet meer ondersteund worden.

[1] Bij testen in verschillende stadia van ontwikkeling kan gedacht worden aan: functies en componenten door de teams en dien­sten waarbij teams samenwerken, dit kan OBO overstijgend zijn. De diensten staan beschreven in de dienstencatalogus.