OTAP, Teststrategie voor het ontwikkelen van applicaties

De OTAP Teststrategie is een kwaliteitssysteem dat al jaren gemeengoed is voor het ontwikkelen van applicaties. Het mooie van OTAP is dat het inpasbaar is in alle ontwikkelmethodes zoals waterval, Agile/Scrum of DevOps. Als het gaat om het ontwikkelen van software voor mini’s, mainframes, pc’s of het web, is de structuur van IT omgevingen de afgelopen 30 jaar niet radicaal veranderd. OTAP is algemeen toepasbaar.

Bij het dit kwaliteitssysteem zijn er vier primaire systemen die we geïsoleerd moeten opzetten. Deze vier systemen hebben allemaal betrekking op dezelfde applicatie, die dus vier keer geïnstalleerd is. De systemen beschrijven we met het acroniem OTAP – zijnde de Ontwikkel-, Test-, Acceptatie- en Productie-omgeving. Met elkaar vormen ze een kwaliteitssysteem en ondersteunen ze een vaak gebruikte en beproefde teststrategie. Bij organisaties als de Rabobank, ING-bank, Unilever of KPN gebruikt men niets anders als deze OTAP strategie. Iets dat in loop van tijd is veranderd, is dat deze systemen niet langer op aparte hardware hoeft te draaien. Het is mogelijk om één of meer van deze systemen op te zetten met behulp van virtuele servers. In de meeste gevallen is het belangrijkste aspect de onderlinge isolatie en niet de prestaties van de systemen. Daarom is de inzet van virtualisatie (virtuele servers of virtuele machines op dezelfde hardware) geen probleem.

OTAP – Ontwikkelomgeving

In de meeste moderne systemen vindt ontwikkeling plaats op de laptop of de desktop van de individuele ontwikkelaar. Zolang de juiste versies van de besturingssystemen geïnstalleerd zijn is dat geen probleem. Ontwikkelaars moeten een complete omgeving tot hun beschikking hebben. Alle onderdelen van het systeem moeten op hun systeem aanwezig zijn. Voor het opzetten van een website met een webgebaseerde applicatie betekent dit dat ontwikkelaars tenminste het volgende nodig hebben:

• Dezelfde webserver als we in productie gebruiken.
• De zelfde database als die we in de productie gebruiken. Een versie met een beperkte functie- of grootte in verband met het gebruik van hulpbronnen is aanvaardbaar. Alle functies die we in het systeem gebruiken moeten wel beschikbaar zijn.
• De zelfde programeertaal als we in de productie omgeving gebruiken. (vaak is dat WordPress of Joomla). De ontwikkelaar test zelf de module die hij geprogrammeerd heeft op werking en testbaarheid. Hierbij kijken we nog niet naar de samenhang met de andere programmamodules.
• De ontwikkelingsserver zal vaak ook de repository voor de broncode zijn. Alle versies van de programmatuur bewaren we daarop. Als dat het geval is moet men er bij het testen zeker van zijn dat de juiste versie wordt gebruikt.
• Omdat de ontwikkeling vooruit loopt op de productie, zullen we nieuwe ontwikkelingen eerder in de ontwikkelingomgeving installeren. Aangezien de ontwikkeling van modules over meerdere machines verdeeld is, moeten we bewaken of we alle ontwikkelingen op dezelfde versies van alle tools uitvoeren. Ontwikkelaars mogen hun systeem niet zomaar updaten naar een nieuwe toolversie. Ze moeten wachten tot de hele ontwikkelingsgroep klaar is voor een nieuwe update.

OTAP – Testomgeving

Zodra de programmacode de moduletest heeft doorstaan, is het de testserver waar integratie testen plaatsvinden. Volgens een vooraf bepaald schema moet onze testserver – hopelijk automatisch – alle code ophalen. De database wordt vernieuwd en een testscript wordt uitgevoerd. Alle module tests voeren we eerst uit waarna we de integratie- en regressietesten uitvoeren. Deze test waarborgt dat alle stukken bij elkaar passen en dat er onderbrekingen in de werkprocessen zitten.

OTAP – Acceptatie omgeving

In de acceptatietest-omgeving testen de eindgebruikers of de programmamodules doen zoals zij dat verwachten. De eindgebruiker legt de module tegen de Acceptatie Criteria die hij eerder heeft vastgesteld. De server voor het acceptatietesten moet altijd een kopie van de productieserver zijn, zowel de programmeertaalversie als de databaseversie. Als er sprake is van een exacte kopie kan de productie-omgeving nooit afwijken van wat de testers eerder geaccepteerd hebbe. Als de code klaar is voor release, controleren we deze altijd in de Acceptatie – omgeving. Sommige teams herhalen op dit moment als laatste gezondheidscheck ook de integratie / regressie tests voordat de gebruiker met het programma aan de slag kan. De acceptatietest voor webgebaseerde applicaties moet ook op internet of intranet plaatsvinden. Alleen op die manier is de werking van applicatie vast te stellen.

In de Acceptatie – omgeving testen we ook de versie-migratie scripts.

OTAP – Productie omgeving

De laatste fase van het ontwikkelingsproces is het plaatsen van de code in productie. Als alles goed gaat, moet dit een volledig geautomatiseerd proces zijn, of in ieder geval een zeer geautomatiseerde operatie.

OTAP Aandachtspunten

Datasets

Over de omvang en de inhoud van de datasets in de verschillende omgevingen moeten we goed nadenken. Urenlange verwerkingen in de testomgevingen hebben geen zin maar er moet voldoende massa zijn voor een representatieve test. Daarnaast speelt privacy een rol. Het een op een overnemen van data kan tot vervelende privacy issues leiden. Daarom is het anonimiseren van de data beter. Al was het maar om testoutput niet te verwarren met productie-output. We zullen maar een test-aanmaning ontvangen.

Versie beheer

Bij het gebruik van meerdere omgevingen is een consequent versie beheer van groot belang. Weten welke versie in welke omgeving staat. Het kan zijn dat een programmeur al met de volgende aanpassing van een module is begonnen terwijl de vorige nog in acceptatie staat. Stel dat we in acceptatie een fout vinden.. Het herstel wordt dan niet meegenomen in de versie bij die bewuste programmeur. Als we hier niet een goeie bewaking op zetten komen we in de problemen.

Backup alle omgevingen

Het is verstandig om dagelijks een backup van alle omgevingen te maken zodat we altijd terug kunnen naar een goed werkende omgeving. Tijdens intensieve testperiodes worden vaker backups gemaakt van de testomgevingen. Op die manier zijn regressie testen mogelijk. Telkens als een module is aangepast zetten we de oude dataset weer terug zodat we de resultaten tussen de verschillende testen kunnen vergelijken.

Infrastructuurwijzigingen en Migraties

Infrastructuurwijzigingen en het migreren van het besturingssysteem, de database of de ontwikkelomgeving naar een hogere versie verdienen speciale aandacht. Als we dit eerst in de ontwikkelomgeving doen en daarna naar de testomgevingen kunnen we tussentijds geen modules opleveren. Zulke acties moeten we dus goed plannen want we willen een migratie wel eerst goed testen voordat we hem in productie doorvoeren. Bij migraties is er ook nog een issue met de oude back-ups. Deze zijn namelijk niet meer in te lezen in de nieuwe omgeving. Het is dus nodig om de oude omgeving tijdelijk in stand te houden zodat de oude data ingelezen kan worden. Voor het verwerken van de oude data in de nieuwe omgeving zijn dan speciale scripts nodig.

Overdracht van modules

Het overdragen van modules gebeurt vrijwel nooit op een simpele wijze. Meestal moeten we ze in een bepaalde volgorde installeren waarbij tussendoor scriptsdraaien die de database aanpassen. Om te voorkomen dat daarbij tussentijds data corrupt raakt vinden deze overdrachten vaak in de avonduren of in de weekenden plaats.

Conclusies t.a.v. OTAP

Uit een oogpunt van informatiebeveiliging en risico beperking is de teststrategie volgens OTAP een bewezen oplossing. Het is zeer belangrijk om onze omgeving goed op te zetten en ervoor te zorgen dat al onze tools goed samenwerken voordat we beginnen met ontwikkelen. Als we dit nog moeten doen als het project al loopt is dat een garantie voor vertragingen en gefrustreerde ontwikkelaars.

De testmethodes zoals Tmap gaan dieper in op omgevingen en testgevallen.

Discussieer mee op LinkedIn.