Belangrijk

Met deze mindset probeer je alles wat je test te automatiseren. Het is niet haalbaar om dit alleen te doen, dus maak je testautomatisering een fundamenteel onderdeel van het teamproces. Bijvoorbeeld: het team is het erover eens dat testautomatisering deel uitmaakt van elke story. Als de testautomatisering niet klaar is, is de story niet klaar. Geen uitzonderingen.

Onderhoud wordt belangrijk vanwege het grote aantal tests dat je maakt. Je moet elk beetje onderhoud herhalen voor iedere test. Je steekt veel moeite in stories die de onderhoudbaarheid verbeteren, zodat je niet verdrinkt in onderhoudswerkzaamheden in de toekomst. Dezelfde redenering geldt voor test performance. Een snelle testsuite stelt je in staat om snelle feedback te krijgen. Het stelt je ook in staat om sneller te itereren bij het maken van nieuwe tests. Het team is het erover eens dat onderhouds- en performance stories waarde toevoegen.

Regressie door alleen testautomatisering moet voldoende zijn voor een release. Soms kun je iets handmatig testen. Maar, je test alleen handmatig in uitzonderlijke situaties.

Problemen

Het kost veel tijd om alle geautomatiseerde tests te schrijven en te onderhouden. Dit komt wederom door het aantal tests. Testautomatisering met de Everything mindset vereist een lange termijn investering.

Na een tijdje met deze mindset te hebben gewerkt, is elke nieuwe test technisch complexer dan de vorige. Je hebt steeds meer technische kennis nodig om de volgende test te maken. Je hebt al de eenvoudige tests toegevoegd. Tegelijkertijd is elke nieuwe test minder nuttig vanwege de law of diminishing returns. Let op wanneer het niet meer de moeite waard is om tests toe te voegen vanwege technische redenen zoals deze.

Tools & Technieken

Dit is de mindset waar automatiseringsnerds gedijen. In andere mindsets moet je oppassen met het gebruiken van tools en technieken die te technisch complex zijn, maar in deze mindset is complexiteit prima.

De technische kant is belangrijk, maar de Everything mindset werkt niet als je je alleen op de technische kant richt. Om dit te laten werken, moet het hele team aan boord zijn. Let goed op de teamproceskant. Het in je eentje aannemen van de Everything mindset maakt je een single point of failure.

Een paar algemene adviezen:

• Doe het samen. Voeg testautomatisering expliciet toe aan je teamprocessen.
• Houd elke test zo eenvoudig mogelijk. Beoordeel eenvoud niet op basis van jouw vaardigheden, maar op die van je team.
• Statische codeanalyse is altijd een goed idee.
• Bij het schrijven van unit tests, overweeg ook het gebruik van meer complexe aanpakken. Enkele voorbeelden:
  • Property-based testen
  • Mutatie testen
  • Snapshot testen
• Prefereer API-tests over GUI-tests omdat ze sneller zijn en gemakkelijker te onderhouden.
• Bij het schrijven van API tests, overweeg ook het gebruik van meer complexe benaderingen. Enkele voorbeelden:
  • Property-based testen
  • Snapshot testen
  • Schema-based testen, of ga een stap verder met contract-based testen.
• Bij het schrijven van GUI tests, gebruik alleen tools waar je tests schrijft in een programmeertaal.
• Bij het schrijven van GUI tests, overweeg ook het gebruik van meer complexe benaderingen. Enkele voorbeelden:
  • Snapshot testen (of screenshot testen)
  • AB testen
  • Property-gebaseerd testen. Let op, de testduur kan exponentieel toenemen als je niet voorzichtig bent.
• Gebruik zowel continuous integration (CI) als continuous deployment (CD) pipelines.
• Performance tests kunnen een goed idee zijn als je ze nodig hebt. Houd er rekening mee dat MVP performance tests vaak voldoende zijn om grote knelpunten te vinden.
• Basis security tests kunnen een goed idee zijn. Je vervangt geen security experts, maar je kunt basis dingen testen zoals dependency vulnerabilities, cross-site scripting (XSS), SQL injections, etc. Als jij de basis aanpakt, kan een security expert zich focussen op de rest.

Positie in het model

In de Everything mindset automatiseer je veel tests. Als je in het witte gebied rechtsonder in de Everything mindset terechtkomt, creëer je single points of failure. Elk teamlid is verantwoordelijk voor te veel tests. Hierdoor bereik je een limiet aan het aantal tests dat je kunt toevoegen. Als je meer tests wilt toevoegen nadat je deze limiet hebt bereikt, gebruik dan de Everything mindset met meer teamleden om de last te delen.

Hoewel de Everything mindset 100% van alle mogelijke tests kan bereiken, moet dit nooit een doel zijn. Het bereiken van 100% is geen goed idee vanwege de law of diminishing returns.

Voorbeeld uit de praktijk

Er volgt een kort verhaal over hoe een team de Everything mindset heeft gebruikt in een bedrijf met ongeveer 45.000 werknemers. Het team maakte een interne tool met een frontend en backend die complexe bedrijfslogica implementeerden. Het was belangrijk dat deze logica correct was voor het succes van de hele organisatie. Vanwege de complexe aard van de logica, gebruikten ze de Everything mindset om de applicatie te testen.

De teamleden voegden testautomatisering toe aan hun definition of done en hielden zich er aan. Een story was niet klaar als de testautomatisering niet compleet was. Ze schreven ook hun testautomatisering in dezelfde Git-branch die de ontwikkelaars gebruikten om de story te implementeren. Hierdoor werd testautomatisering een integraal onderdeel van het teamproces.

De testers in het team maakten API-tests en GUI-tests. De API-tests testten de bedrijfslogica van de backend. De GUI-tests hadden de veel kleinere scope om de integratie tussen de frontend en backend te testen. Ze gebruikten Jenkins-pipelines met pull request triggers en merge-beperkingen die afdwongen dat alle tests moesten slagen. Met andere woorden, ze gebruikten een volledige continuous integration aanpak voor testen.

Het team kampte met performance problemen veroorzaakt door het aantal tests en een gebrek aan prioriteit voor het oplossen ervan. Ze werkten om de performance problemen heen door een subset van alle tests uit te voeren in pull request. Een keer per dag voerde het team alle testen uit in een geplande pipeline.

Het grootste probleem waarmee het team te maken kreeg, was het onderhoud van de tests. Voor dit probleem vond het team nooit een goede oplossing.

Conclusie

De Everything mindset is een automatiseer-eerst mindset waarbij je alle mogelijke tests binnen je team automatiseert, tenzij het te veel moeite kost vanwege technische redenen. Met deze mindset maak je veel tests. Met een groot aantal tests ontstaan logischerwijs grote onderhouds- en performance problemen.

Deze mindset werkt het best als je het samen doet. Betrek het hele team door testautomatisering een fundamenteel onderdeel te maken van je teamprocessen.

Je test altijd in isolatie. Applicaties van andere teams vallen buiten de scope van de Everything mindset.

De Everything mindset kan controversieel zijn, maar het is vaak de moeite waard.