Als QA engineer werk ik dagelijks met teams die software bouwen in een Agile omgeving. Maar wat betekent het eigenlijk om “Agile”
te testen? Het Agile Testing Manifesto geeft daar een helder antwoord op — en het verandert fundamenteel hoe we naar kwaliteit
kijken.
Wat is het Agile Testing Manifesto?
Het Agile Testing Manifesto is geïnspireerd door het originele Agile Manifesto en vertaalt dezelfde principes naar de wereld van
software testing. De kern bestaat uit vijf waarden:
- Testing throughout over testing at the end
Testen is geen fase die begint als de ontwikkelaar “klaar” is. In een Agile team test je continu: tijdens refinement, tijdens
ontwikkeling, en na oplevering. Hoe eerder je een probleem vindt, hoe goedkoper het is om het op te lossen. In de praktijk betekent dit dat ik als QA engineer al betrokken ben bij user story refinement. Ik stel vragen, identificeer
risico’s en denk mee over acceptatiecriteria — nog voordat er één regel code geschreven is. - Preventing bugs over finding bugs
Dit is misschien wel de belangrijkste verschuiving. Traditioneel was een tester iemand die bugs vond. In Agile draait het om het
voorkómen van bugs. Door goede teststrategieën, duidelijke acceptatiecriteria en vroege feedback loops zorgen we ervoor dat bugs
niet eens ontstaan. Test automation speelt hier een cruciale rol. Met geautomatiseerde regressietests in je CI/CD pipeline vang je fouten op voordat ze
de gebruiker bereiken. - Testing understanding over checking functionality
Testen gaat niet alleen over “werkt de knop?”. Het gaat over begrijpen wat de gebruiker nodig heeft en of de software daaraan
voldoet. Dit vereist een dieper begrip van het domein, de gebruiker en de business value. Als ik een nieuwe feature test, vraag ik mezelf altijd af: lost dit het probleem van de gebruiker op? Niet alleen: voldoet het aan
de specificatie? - Building the best system over breaking the system
De oude mentaliteit van “ik ga het systeem breken” maakt plaats voor een constructieve aanpak. Als tester draag je bij aan het
bouwen van het beste mogelijke systeem. Je bent geen poortwachter, maar een teamspeler die kwaliteit toevoegt. Dit betekent ook dat je meedenkt over architectuur, performance en gebruikerservaring — niet alleen over functionele correctheid. - Team responsibility for quality over tester responsibility
Kwaliteit is niet de verantwoordelijkheid van de tester alleen. Het hele team is verantwoordelijk. Developers schrijven unit tests,
product owners definiëren duidelijke acceptatiecriteria, en testers zorgen voor de overkoepelende teststrategie. In de beste teams die ik heb meegemaakt, voelt iedereen zich eigenaar van de kwaliteit. De tester is de facilitator, niet de enige
bewaker. Hoe pas ik dit toe? In mijn werk als freelance QA engineer breng ik deze principes in de praktijk:
- Vroege betrokkenheid bij refinement en planning
- Test automation in de CI/CD pipeline voor continue feedback
- AI-driven testing om slimmer en efficiënter te testen
- Kennisdeling zodat het hele team verantwoordelijkheid neemt voor kwaliteit Het Agile Testing Manifesto is geen checklist — het is een mindset. En die mindset maakt het verschil tussen software die “werkt”
en software waar je op kunt vertrouwen.
Geef een reactie