Dit jaar publiceerde Capgemini een rapport over het heden en de toekomst van testen. Het rapport is gebaseerd op interviews met medewerkers van bedrijven uit West-Europa en Noord Amerika, uit diverse velden zoals financiën, maar ook zorg.

De vragen gingen over waar men de meeste tijd aan besteed, waar men problemen ondervindt, of men bepaalde ontwikkelingen heeft toegepast en wat dat heeft opgeleverd.

Centrale thema’s zijn testomgevingen, testautomatisering, testdata, afstemming van werk tussen teams in complexe ketens van applicaties.

Overkoepelend thema is “Continuous Testing”.

Continuous houdt verband met ontwikkelingen als “DevOps”, “Agile” en “Scrum”: dit zijn ontwikkel- en beheermethoden waarbij kleine teams in korte cycli (iteraties of sprints genoemd) aanpassingen aan de software opleveren. In Agile en Scrum is het team verantwoordelijk voor ontwikkeling, bij DevOps is hetzelfde team ook voor productie verantwoordelijk (Operations).

Het kort cyclisch ontwikkelen en aanpassen kan zo ver gaan dat dagelijks of soms zelfs meerdere keren per dag nieuwe zaken in productie worden gezet! Dit heet dan “Continuous development”, “Continuous Deployment” of “ Continuous Integration”.

Dit betekent dat elke wijziging ook steeds moet zijn getest! Testen is echter vaak de beperkende factor in “Continuous”. Dit blijkt ook uit het onderzoek van Capgemini.

De belangrijkste redenen hiervoor zijn:

• Testomgevingen: door Agile en DevOps zijn er meer kleine teams die elk testomgevingen nodig hebben. Deze testomgevingen moeten af en toe ook weer gekoppeld worden aan testomgevingen van andere teams: als wijzigingen, bijvoorbeeld een nieuwe koppeling, bij beide teams voor wijzigingen zorgen die een relatie hebben met elkaar. Dit kan betekenen dat er nieuwe servers nodig zijn (computer hardware waar de testomgevingen op draaien). Hier is dan ook weer extra beheer van nodig. Een oplossing kan “virtualisatie” zijn: het op één server kunstmatig aanmaken van omgevingen. Hiervoor is dan weer extra tooling nodig waarmee je dit mogelijk maakt.
• Testdata: door GDPR-wetgeving (General Data Protection Regulation) wordt het lastiger om productiedata te gebruiken waarin persoonsgegevens staan (dat is bijna altijd het geval). Dit moet worden geanonimiseerd of testdata moet opnieuw worden aangemaakt. Het is lastig om dit synchroon te krijgen als er sprake is van een systeemketen: als de gegevens in systeem A overeen moeten komen met die in systeem B. Hiervoor is tooling nodig maar dit moet dan tussen teams worden gecoördineerd.
• End to end testing (ketentesten): soms moeten er testen worden uitgevoerd waarin systemen worden gecombineerd. Hiervoor zijn testomgevingen nodig vanuit diverse teams die aan elkaar moeten worden gekoppeld en waarin de testdata op elkaar afgestemd is. Bovendien is voor de testen kennis nodig van alle afhankelijkheden tussen de betrokken systemen: kennis van gebruikersprocessen en technische processen. Dit zit vaak niet in de individuele teams.
• “Shift left testing”: hiermee wordt bedoeld dat requirements en ontwerpen worden gereviewed en gezamenlijk doorgelopen voordat er wordt geprogrammeerd. Dit is een effectieve manier om ontwerpfouten vroeg te vinden en daarmee te voorkomen. Bovendien krijgen tester en programmeurs hierdoor meer begrip van de gebruikers context. Testers en gebruikers moeten vrij gemaakt worden om dit vroeg in het traject uit te voeren, maar dit gebeurt niet genoeg. Dit komt doordat gebruikers vaak pas aan het eind van het traject worden ingepland en omdat testers (te) veel tijd kwijt zijn met het opzetten van testomgevingen, testautomatisering en testdata.
• Testautomatisering is niet voldoende: om alles wat je zou moeten testen in een korte periode te kunnen testen ontkom je niet aan het automatiseren van een (groot) deel van je testen. Hiervoor ontbreekt soms de kennis en vaardigheden, hoewel dit steeds minder vaak voor komt. Deze strubbelingen met testdata en testomgevingen vertalen zich met name in geautomatiseerde testsets: hier heb je een stabiele en voorspelbare testomgeving met testdata nodig.
• Gebruikerstesten: als je elke dag oplevert, moeten er (in principe) ook elke dag gebruikerstesten worden uitgevoerd: de wijziging moet immers worden geaccepteerd. Maar gebruikers zijn dagelijks ook betrokken in productie! Daarom missen in Agile en DevOps de uitgevoerde testen nog wel eens het gebruikersperspectief en kunnen er problemen in productie ontstaan omdat er niet genoeg rekening is gehouden met het echte werkproces.

Test orkestratie

Per gebied zijn verbeteringen binnen elk van de genoemde gebieden mogelijk maar er is één concept waar het rapport de meeste hoop op heeft gevestigd: “Test orkestratie” (test orchestration).

Test orkestratie betekent dat er één plek en één team is waar alle wijzigingen in de diverse teams, alle testomgevingen en gebruikte testdata wordt overzien en waarin gezamenlijke behoeftes, zoals testdata, testomgevingen en E2E-testen worden gecoördineerd. Zoals een dirigent die alle instrumentalisten in een groot orkest laat samenklinken in één symfonie. Dit is lastig in Agile en DevOps omdat daarin de autonomie van de individuele teams zo belangrijk is.

Vanuit test orkestratie kan er toe worden besloten om wijzigingen met veel gebruikersimpact te bundelen en die te koppelen aan een uitvoeriger gebruikerstest. Op deze manier kunnen ook keten gerelateerde zaken in meer samenhang worden getest of kunnen testomgevingen worden gereserveerd voor bepaalde testen.

Conclusie

De conclusie van het rapport is dat in een ingewikkelde organisatie en een ingewikkelde orkestketen je niet aan test orkestratie ontkomt, als je wilt dat testen niet een belemmering is voor Continuous Development. Alleen dan kan testen Continuous Testing worden.

Misschien is “Test dirigeren” een beter begrip dan “Test orkestreren”.

Het moeten coördineren van alle releases, wijzigingen, testomgevingen, testdata en E2E-testen speelt niet alleen in organisaties waar Agile en DevOps ver zijn doorgevoerd. Ga bij je eigen organisatie na of de genoemde zaken niet ook al (in enige mate) spelen.

Het dirigeren van alle test gerelateerde zaken loont de moeite in vrijwel elke organisatie.