Problemen

Onderhoud is waarschijnlijk je grootste probleem. Je denkt aan onderhoud bij het kiezen van tools en het initieel opzetten van je testsuite en je erkent ook welk onderhoud je moet doen. Om die reden schrijf je onderhoud-stories. Deze stories staan echter onderaan de backlog en krijgen nooit prioriteit. Hierdoor kan het op lange termijn moeilijk zijn om tests te laten slagen.

Je hebt een vergelijkbaar probleem met performance. Je schrijft stories om je tests sneller te maken, maar ze belanden onderaan de backlog, naast de onderhoud stories. Hierdoor kan het uitvoeren van je testsuite uren duren.

Je geautomatiseerde testsuite is niet voldoende voor geautomatiseerde regressie voor een release. Het is een goed startpunt, dus voer eerst de geautomatiseerde regressie uit. Na de geautomatiseerde tests moet je ook nog handmatig testen voordat je kunt releasen.

Tools & Technieken

Een goede plek om te beginnen, is Risk-based Testen. Beoordeel je risico’s en schrijf je tests op basis van de risico-tot-moeite verhouding. Elke test die je automatiseert, moet een hoge risico-tot-moeite verhouding hebben.

Houd bij het kiezen van tools je onderhoud in gedachten. Kies geen tools die veel onderhoud vereisen. Gebruik bijvoorbeeld geen record & playback tools. Vermijd ook snapshot-testing wanneer je applicatie regelmatig verandert.

In de Cherry-pick mindset werk je nooit buiten de grenzen van je team. Elke test die op een gedeelde testomgeving draait (e.g. end-to-end), valt niet binnen de scope. Gebruik bij testen op gedeelde testomgevingen de Multi-team mindset.

Een paar algemene adviezen:

• Houd elke test die je schrijft zo eenvoudig mogelijk. Meerdere kleine tests zijn gemakkelijker te onderhouden dan één grote test.
• Vermijd ketentests en end-to-end-tests. In deze mindset test je altijd je applicatie in isolatie. Vraag aan je lokale ontwikkelaar hoe je jouw applicatie geïsoleerd kunt draaien.
• Wanneer je statische codeanalyse gebruikt, gebruik dan een open-source- of bedrijfsregelset. Het is ook mogelijk om een eigen regelset te maken, maar dit levert vrijwel altijd veel discussie op.
• Wanneer je unit tests of component tests schrijft, doe dan niet te ingewikkeld. Er zijn geavanceerde strategieën zoals mutatietesten of op property-based testen, maar dit is het niet waard in deze denkwijze.
• Prefereer API-tests over GUI-tests omdat ze minder complex zijn.
• Houd je bij het schrijven van API-tests aan tools in een van de volgende categorieën:
  • Je schrijft tests in een programmeertaal
  • Je maakt tests in een applicatie (e.g. Postman, ReadyAPI)
  • Een tool genereert tests voor je
• Gebruik bij het schrijven van GUI-tests alleen tools waarbij je tests schrijft in een programmeertaal.
• Pipelines zijn super om je tests periodiek uit te voeren. Als je daar zin in hebt, ga dan voor een volledige continu-integratie setup.

Positie in het model

In de Cherry-pick mindset automatiseer je niet heel veel tests. Je richt je alleen op tests die veel waarde toevoegen. De gebogen rechtergrens van de Cherry-pick mindset laat ons zien dat als we meer willen testen, we dat samen moeten doen. Je kunt veel alleen testen, maar uiteindelijk loop je tegen een limiet aan van hoeveel tests je in je eentje kunt maken in deze mindset. Als je meer tests wilt toevoegen na het bereiken van deze limiet, gebruik dan de Alles mindset of gebruik de Cherry-pick mindset samen.

Voorbeeld uit de praktijk

Hoe gebruikt een team de Cherry-pick denkwijze? Dit illustreer ik aan de hand van een voorbeeld van een bedrijf met ongeveer 2000 medewerkers. In dit team testten ze bijna niets. Ze erkenden dat dit een probleem was en huurden ervaring in, namelijk een externe tester. Ze gaven de tester de taak om testprocessen op te zetten en teams ervaring te laten opdoen met testen. De nieuwe tester introduceerde een strategie waarin testautomatisering met de Cherry-pick mindset een onderdeel was. De tester sloeg de First steps mindset over met een autoriteitsargument. De organisatie begon in snel tempo met het opzetten testautomatisering met behulp van Playwright en Specflow. Ze kozen er expliciet voor om niet alle tests te automatiseren, maar zich te richten op functies die het belangrijkst zijn of het makkelijkst te automatiseren. Tests die de moeite waard waren, maar niet de moeite waard om te automatiseren, werden toegevoegd aan de nieuwe handmatige testsuite.

De organisatie gebruikte Specflow om meer mensen bij het testproces te betrekken. Specflow was nuttig vanwege het gebrek aan ervaring in de organisatie en het gebrek aan goede documentatie. Door de focus op participatie en documentatie, werd onderhoud grotendeels genegeerd. Als ze de Cherry-pick mindset blijven gebruiken, wordt performance waarschijnlijk een probleem in de toekomst. Ondanks dat er enige aandacht voor testonderhoud was tijdens de tooling setup, lopen ze waarschijnlijk over een paar jaar tegen onderhoudsproblemen aan.

Conclusie

Testautomatisering met de Cherry-pick mindset draait om alleen automatiseren als het de moeite waard is. Waarde wordt bepaald aan de hand van een risicoanalyse en het gemak van automatisering. In de Cherry-pick denkwijze streef je naar maximale waarde met minimale inspanning. Vanwege deze focus kun je last hebben van slechte onderhoudbaarheid en performance, vooral in oudere testsuites.

Applicaties van andere teams vallen buiten de scope van de Cherry-pick mindset. Je test daarom altijd in isolatie.

Ondanks de beperkingen is de Cherry-pick mindset een zeer natuurlijke test mindset. Velen beschouwen het als een good practice.