Skip to content

Blog

Hoe bepaal je de teststrategie voor cloud applicaties?

  • Home
  • Blog
  • Hoe bepaal je de teststrategie voor cloud applicaties?

 

 

Hoe bepaal je de teststrategie voor cloud applicaties?

In mijn vorige blog schreef ik hoe de rol van tester de afgelopen 10 jaar getransformeerd is naar Quality Engineer. In deze blog geef ik antwoord op de vraag of de definitie van testsoorten en testmethoden niet ook moet  worden aangescherpt?  Want voldoet de definitie voor het testen van monoliete systemen ook voor cloud-applicaties? Of moeten de testen op een andere manier worden ingedeeld bij het testen van microservices en microsites? Wanneer is er voldoende getest en heeft het team vertrouwen om te releasen naar productie? Je vind de antwoorden hieronder in mijn blog. 

Van ijshoorn naar pyramide

Laten we bij het begin beginnen. Er zijn meerdere concepten om de verschillende soorten geautomatiseerde testen te categoriseren. Dit helpt het team om te komen tot een gebalanceerde set aan testen waarmee vertrouwen wordt gecreëerd dat er op het juiste niveau het juiste wordt getest.

Één van de eerste test concepten is de testing-cone. Bij dit concept worden de meeste testen handmatig worden uitgevoerd. Geautomatiseerde tests zullen grotendeels op UI / end-to-end-testniveau zijn. In een agile omgeving, met frequente releases, kun je niet snel reageren wanneer er beperkt aantal geautomatiseerde regressie testen zijn. De balans tussen snelheid van opleveren en de doorlooptijd van testen is zoek. Hierdoor wordt de 'testing-cone' als anti-pattern aangeduid.

Als antwoord hierop heeft Martin Fowler de ‘testing pyramid’ bedacht.  Bij dit concept is de ‘testing cone' als het ware omgekeerd. Deze gaat uit van zoveel mogelijk unit testen uitvoeren omdat deze soort het snelst uit te voeren zijn. De gedachte hierachter is om snel feedback over de applicatie te krijgen. Doordat de testen op het laagste niveau worden uitgevoerd en er een beperkte set integratie en E2E testen geeft dit minder vertrouwen in de kwaliteit van de applicatie.

 

Testing trophy

 

Steeds vaker wordt 'testing trophy'  van Kent C. Dodds gebruikt om de testen te categoriseren.

 

 

Dit concept  beschrijft een teststrategie op vier niveaus: 

Statische analyse. Dit omvat tools zoals Prettier, ESLint en zelfs TypeScript, deze concentreren zich op de kwaliteit van de code. Daarnaast zijn unit testen en integratie (API) testen. Deze API-testen staan centraal in het concept. API-niveau testen geven snel feedback en vertrouwen in de kwaliteit van in de applicatie. Als laatste soort zijn er de end-to-end testen die het gedrag simuleren hoe gebruikers door de applicatie heen navigeren.

Zijn deze concepten nog steeds toepasbaar?

De definitie van een unit-test is het kleinste stukje code dat geïsoleerd getest kan worden. Bijvoorbeeld een functie, een subroutine of een methode. Is het niet beter om een microsite of een microservice als unit te zien? 

Integratietesten worden gedefinieerd als een type test waarbij losstaande componenten logisch integreren en getest worden als een geheel. In een gedistribueerd systeem kennen alle componenten onderlinge integraties. Het is ondoenlijk om een gedistribueerd landschap in z'n geheel te testen.  Wat wordt dan de scope van een integratietest? 

De meest voorkomende concepten zoals hierboven benoemd zijn zeker toepasbaar voor het testen van gedistribueerde systemen. Echter de definitie van de verschillende soorten testen is erg belangrijk. Mijn advies: besluit samen met het team wat de definitie is van bijvoorbeeld een unit test. Is dit nog steeds het kleinste stukje code of gaat het verder dan dat? Hetzelfde geldt voor integratie-testen. Wat moet een integratietest afdekken en en waarin verschilt het van unit- of end-to-end testen? Zo wordt overlap voorkomen en ontstaat er balans tussen de snelheid van testen en het vertrouwen op basis van de feedback van de testen. 

 

Vertrouw jij op jouw testen?

Testen voor gedistribueerde systemen in de Cloud kunnen niet zo makkelijk in hokjes worden geplaatst als testen voor een monoliet systeem.  Dit landschap kenmerkt zich door meerdere microservices en meerdere microsites met integraties op meerdere vlakken. Dit staat haaks op een monoliet systeem met 1 front-end en een gekoppelde back-end.

Mijn advies: gebruik de bestaande testmodellen als handvatten maar laat de vorm los. Definieer samen met het team welke testsoorten uitgevoerd moeten worden en wat hierin wel en wat niet wordt getest.

De huidige test frameworks bieden ook mogelijkheden om meerdere testsoorten in één test te vatten. Bijvoorbeeld een test welke zowel de user interface als de onderliggende API afdekt. Daarnaast zijn de moderne test framework, zoals Cypress, vele malen sneller, dan 10 jaar geleden in het uitvoeren van 'langzame' E2E/integratie testen. Juist deze testen geven veel vertrouwen in het systeem. Zeker iets wat moet worden meegenomen in het besluit wat op welk niveau getest gaat worden. 

In mijn ogen heeft het team pas vertrouwen in de testen als er op vrijdagmiddag een productie-release wordt gedaan en aansluitend weekend gaan vieren. De 'testing trophy' is een prima basis om een teststrategie voor een cloud applicatie op te baseren. Scherp hierbij de definitie en de de scope van de verschillende testsoorten aan.

Zo wordt voorkomen dat er niet te weinig testen worden geschreven, maar zeker ook niet teveel!