Wat is observability en waarom is het belangrijk voor testers?
Testers in moderne agile-/devopsteams zijn niet meer het laatste vinkje dat gezet moet worden voordat een feature “done” is. Ze zijn de eigenaren van kwaliteit in de breedste zin van het woord. Steeds minder is dit alleen testen, steeds meer is dit het bijdragen aan code reviews, CI/CD pipelines, teststrategieën, enzovoorts. Maar er is één veld dat hierin vaak nog buiten het domein van de tester, of zelfs van het hele team valt: observability.
Wat is observability precies? En waarom is het belangrijk voor testers om hier iets van af te weten? Deze vragen bespreken we in deze eerste blogpost, in een serie van drie. Het tweede deel zal gaan over concrete technieken om observability in te zetten bij het testen. In het laatste deel omschrijven we onze favoriete observability stack(s), en omschrijven we hoe je kunt beginnen observability in te zetten in jouw team.
Wat is observability?
Observability is het vermogen om te zien en vooral *begrijpen* hoe een systeem zich in productie gedraagt. Het is een term die veel wordt gebruikt in de infrastructuurwereld en die populair is geworden in de context van DevOps. Wij houden de volgende definitie aan.
Observability is het vermogen om, op basis van output (logs, metrics, traces), te verklaren wat er intern in het systeem gebeurt.
Teams hebben het vaak over observability als het gaat om metrics (statistieken) van het besturingssysteem: CPU-gebruik, geheugengebruik, opslag en netwerkverkeer. Testers denken hierbij misschien aan zogenaamde *non-functionals*. Ze weten misschien hoe ze deze moeten testen, maar zijn vaak niet betrokken bij de dagelijkse praktijk ervan. Dit is vaak het domein van gespecialiseerde Site Reliability Engineers (SRE’s), die meestal geen deel uitmaken van het agile team.
Observability is echter een bredere term, die slaat op het gebruiken van metrics, logs en traces om niet alleen te constateren dat er iets gebeurt, maar ook te begrijpen wat er gebeurt en waarom.
Monitoring: alerts instellen die afgaan wanneer je product tijdelijk niet beschikbaar is
Versus
Observability:
– metrics die een alert afvuren wanneer het geheugen van je server snel volloopt
– logs die aangeven dat dit zou kunnen gaan om onbedoeld gebruik van je applicatie
– traces die je vertellen hoe de keten van requests, logmeldingen en backend-operaties eruit ziet
Observability gaat dus juist wel om de “functionals”!
Later in deze serie gaan we in op onze favoriete observability stack(s), maar een aantal voorbeelden van bekende observability-tools zijn: Grafana, Datadog, (Amazon) Cloudwatch, Dynatrace, AppDynamics.
Waarom observability belangrijk is voor testers
Om te verduidelijken waarom observability belangrijk is voor testers, is het belangrijk om even stil te staan bij wat wij als testers doen en waarom. Hier zijn oneindig veel definities van, maar in mijn ervaring kan bijna elke tester zich vinden in de volgende:
Kwaliteit is waarde voor (de juiste) personen.
Testen is de activiteit(en) waarmee we kunnen aantonen wat de kwaliteit van een testobject is.
Deze definitie is gebaseerd op het werk van Michael Bolton.
Ik in deze definitie de nadruk gelegd op kunnen, want we weten helaas al te goed dat niet al het testen dit ook doet. De perfecte functionele test kan belangrijke performanceproblemen missen. Automatisering kan vaak niet alle mogelijke interacties in een applicatie dekken. Ervaren testers weten dat het ontwerpen van de juiste test aanzienlijk belangrijker (en moeilijker) is dan het uitvoeren. In de keuze voor de juiste techniek spelen veel factoren mee. Een aantal voorbeelden:
– business requirements
– bugreports
– gebruikersfeedback
– gebruikersinterviews
– intuïtie (door praktijkervaring met de codebase, organisatie en gebruikers)
Dit is zeker geen complete lijst, en bovendien heeft iedere informatiebron zijn voor- en nadelen. Business requirements worden vaak aangereikt, maar vertellen ons weinig over de echte gebruiker. Gebruikersinterviews daarentegen, vertellen ons veel over de echte gebruiker, maar zijn tijds- en werkintensief. Bugreports en gebruikersfeedback komen alleen binnen als gebruikers al betrokken (of gefrustreerd) genoeg zijn om iets te melden.
Wat als er een manier was om te begrijpen hoe de interactie van onze gebruikers met onze applicaties eruit ziet? Zonder hun participatie, nu en in het verleden? Dit is wat observability ons kan bieden.
Welke rollen observability kan spelen
In DevOps is testen een continu, iteratief proces. We denken vaak dat dit automatisering betekent. Maar een testscenario op zich is niet anders geautomatiseerd dan “handmatig.” Als we willen dat ons ontwikkelproces iteratief is, is het belangrijkste dat elke iteratie de volgende iteratie beïnvloedt. Dit is waarom DevOps, en elke andere agile ontwikkelfilosofie, uitgelegd wordt met een herhalend patroon, zoals een lus of cirkel.
Voor testen betekent dit dat het gebruik van de applicatie in productie (operate- en monitor-fases), continu ons testen (plan-, build- en integration-fases) moet beïnvloeden.
Als een story done is (en done betekent live) moeten we observeren of de applicatie zich op de verwachte, veranderde manier gedraagt. We moeten observeren hoe onze gebruikers ermee interacteren. Site Reliability Engineers doen dit al, maar zij kijken naar de machines. Als testers geven we juist om de gebruiker (de juiste personen), moeten wij dit ook doen.
Conclusie
Observability is het vermogen om, op basis van output (logs, metrics, traces), te verklaren wat er intern in het systeem gebeurt. Dit vertelt ons van alles over de ervaring van de het dagelijkse, echte gebruik van onze applicatie. Voor testers is dit een enorme bron van informatie, die in veel gevallen onaangeboord blijft.
Dit is in het AI-tijdperk alleen nog maar meer van belang, lees daarover vooral onze eerdere blogpost: Vibe coded applicaties – minder testen, meer observeren.
In het volgende deel van deze serie laten we zien hoe je concreet observability kunt inzetten in de DevOps-cyclus van jouw team. Ook laten we voorbeelden zien van hoe observability-tools een krachtige aanvulling kunnen zijn in de gereedschapskist van een tester.
