Belangrijk

Elke test in de Enterprise-mindset moet centraal worden uitgevoerd, zonder dat de teams waarop de tests van toepassing zijn iets hoeven te doen. De teams zijn namelijk al druk bezig met het maken en onderhouden van tests in de andere mindsets.

Je tests mogen traag zijn zolang ze onzichtbaar en niet blokkerend zijn. Je wilt nooit een release pipeline blokkeren omdat een centrale test nog draait, of omdat deze is gefaald. Als het team iets moet veranderen omdat je test op enterpriseniveau is mislukt, moet dit via management worden geregeld en niet worden afgedwongen door code. Als je tests snel zijn (onder de 10 seconden), kunnen ze zichtbaar en blokkerend zijn. Het op deze manier blokkeren van releases kan heel snel vervelend worden. Bij blokkerende tests moet je altijd een manier vinden om de blokkade te omzeilen via configuratie, uitzonderingen, vrijstellingen, etc. Anders krijg je problemen met legacy applicaties, applicaties van derden en overwerkte teams.

Een groot deel van het maken van tests in deze mindset is het delen van je kennis met de teams waarop ze van toepassing zijn. Je vertelt iedereen waarom de tests bestaan, hoe ze werken en hoe ze de resultaten moeten interpreteren. Je informeert iedereen ook over wijzigingen. Vooral als deze wijzigingen ertoe kunnen leiden dat een team niet langer compliant is; teams mogen nooit verrast worden door non-compliance.

Problemen

Tests in de Enterprise-mindset zijn over het algemeen zeer technisch complex. Je hebt daarom ruime programmeerkennis nodig om deze tests te kunnen maken. Omdat de meeste testers niet zoveel programmeerkennis hebben, worden Tests in de Enterprise-mindset vaak door ontwikkelaars geschreven. Ongeacht de technische complexiteit is de menselijke kant nog complexer. Want hoe krijg je alle teams zover dat ze voldoen aan je tests? En hoe krijg je de teams zover dat ze problemen tijdig oplossen?

Vanwege de complexiteit van dit type tests, heb je een gespecialiseerd team nodig om ze te maken en alles eromheen te beheren. Echter, een gespecialiseerd team vereist een aanzienlijke investering en daar zitten organisaties vaak niet op te wachten. Toch is deze investering noodzakelijk om de tests goed uit te voren. Je kunt deze mindset niet effectief adopteren zonder focus en je kunt niets bereiken zonder mandaat.

Tools & Technieken

Vanwege vereiste geld- en tijdsinvesteringen ligt het voor de hand om te beginnen met Risk-based testing. Je wilt namelijk niet veel uitgeven aan tests die weinig waarde toevoegen. Zodra je hebt vastgesteld wat je wilt testen, communiceer je dit duidelijk en frequent. Zodat het lukt om zoveel mogelijk teams mee te krijgen. Goede communicatie blijft ook tijdens het uitvoeren van de tests cruciaal.

Enkele algemene adviezen:

• Houd elke test die je schrijft zo eenvoudig mogelijk. Dit helpt zowel met de technische kant als met de communicatie.
• Static code analysis is een uitstekende manier om code compliance te waarborgen. Code repositories zijn een goudmijn van gegevens die klaar zijn om te worden gebruikt voor security compliance checks. De performance van deze aanpak schaalt bovendien goed.
• Data analysis werkt perfect om (test)data compliance problemen te vinden. Het doorzoeken van databases kan helpen bij wettelijke compliance (bijv. GDPR). Het kan ook onvolledige data, dubbele data en nog veel meer detecteren.
• Gebruik alleen static analysis. Elk ander type testen schaalt niet goed genoeg om in deze mindset te worden gebruikt.
• Gebruik periodiek geplande pipelines. Wanneer je release-blokkerende tests gebruikt, kun je continuous integration pipelines gebruiken of je tests inbouwen in een interne applicatie (bijv. API gateway).
• Wanneer je release-blokkerende tests gebruikt, geef de teams dan de mogelijkheid om (een deel van) je tests te omzeilen zonder jouw tussenkomst. Tegelijkertijd moet de eenvoudigste manier om iets te doen de compliant manier zijn. Werp drempels op wanneer teams je tests omzeilen, maar bouw geen wegversperringen.

Positie in het model

In de Enterprise-mindset automatiseer je slechts enkele tests, maar wel op grote schaal. Je richt je op het toevoegen van maximale waarde aan zoveel mogelijk teams, terwijl je de technische- en communicatiecomplexiteit minimaal houdt. De gebogen rechterrand van de Enterprise-mindset laat ons zien dat we minder tests uitvoeren als we meer afdelingen betrekken.

Voorbeeld uit de praktijk

Er volgt een kort verhaal over hoe een team de Enterprise-mindset gebruikte in een bedrijf van ongeveer 45.000 medewerkers (volgens LinkedIn). De integratieafdeling was verantwoordelijk voor het leveren van de platforms die alle applicaties in de organisatie verbinden.

De afdeling wilde dat elke nieuwe API design-first zou zijn. Eerst schreef het team een OpenAPI Schema (voorheen bekend als Swagger). Op basis van het OpenAPI Schema implementeerden ze de API. Hierdoor wordt elke API gedocumenteerd door een OpenAPI Schema. In de praktijk negeerden veel teams deze werkwijze. Dit resulteerde in slecht ontworpen en ongedocumenteerde API’s.

De API gateway die door de organisatie werd gebruikt, werd end-of-life verklaard door de leverancier. Bij het zoeken naar een nieuwe API gateway, zocht de afdeling naar manieren om nieuwe API’s af te wijzen op basis van de resultaten van tests. Op deze manier konden ze eisen dat alle gemigreerde API’s een OpenAPI Schema hadden. Ze handhaafden echter niet de volledigheid van het schema. Hierdoor bleven sommige schema’s onvolledig.

De volgende stap voor deze afdeling is om deze tests strenger te maken. Op deze manier kunnen ze langzaam de kwaliteit van de OpenAPI Schema’s en dus de kwaliteit van hun API documentatie verhogen.

Conclusie

De Enterprise-mindset gaat over het testen van compliance op schaal. Deze tests vereisen veel technische complexiteit, maar de menselijke complexiteit is nog groter. Daarom heb je een gespecialiseerd team nodig met een expliciet mandaat dat werkt met een duidelijke scope. Dit team maakt de tests en communiceert erover naar de organisatie.

De eenvoudigste manier om iets te doen, moet de compliant manier zijn. Een team kan non-compliant zijn, maar dit mag nooit makkelijker zijn dan het werk doen om compliant te worden.

De Test Automation Roadmap is een model dat bestaat uit vijf verschillende mindsets:

• First steps 👣
• Cherry-pick 🍒
• Everything 🚀
• Multi-team 🤝
• Enterprise 🌍