/f/151162/1200x1200/49e17d60f3/storyboard-what-10-years-of-entrepreneurship-have-taught-me.png)
[ENG]
Ten years ago, I believed software quality was primarily about processes, tools, and technology.
Today, I know better.
After hundreds of projects, countless conversations with CIOs, CTOs, QA leaders, and engineering teams, I've come to a simple conclusion:
Software problems are rarely software problems … they're people problems.
That may sound surprising coming from a company specializing in test automation, TestOps, performance testing, quality audits, and QA engineering services.
But it's the one lesson I've seen proven over and over again throughout ten years of building b.ignited.
When we started b.ignited, I assumed that organizations struggled with software quality because they lacked expertise, tooling, or methodology.
Sometimes that's true.
More often, it isn't.
The real issue usually isn't the test strategy. It's not the automation framework. t's not the CI/CD pipeline.
It's people who don't collaborate.
Teams chasing conflicting objectives. Departments operating in silos. Leaders who say quality matters, right up until a release deadline starts slipping.
Everyone claims quality is a priority.
Until it competes with speed.
That's when you discover what the real priorities are.
A question we hear time and again is:
"Why can't we get quality under control?"
Most organizations expect a technical answer, a new automation platform, a better testing tool, more test coverage, more dashboards, …
But after a decade of audits, quality improvement programs, and TestOps implementations, we've learned that the root cause is often not technical.
Development operates separately from testing. Testing is treated as a final checkpoint instead of a shared responsibility. Quality metrics exist, but nobody uses them to make decisions.
Teams are rewarded for delivering faster while simultaneously being asked to improve quality.
That's a conflict no tool can solve.
Organizations want higher velocity and better quality, but often create incentives that drive the exact opposite behavior.
And that's where one of the biggest lessons our customers have taught us begins.
Perhaps the biggest lesson our customers have taught us is that sustainable quality doesn't start with automation.
It starts with mindset.
The most mature organizations aren't necessarily the ones with the largest automation suites or the most automated tests.
They're the ones that have embedded quality into the way they operate.
Quality is discussed before development starts. Defects are treated as learning opportunities.Business, development, operations, and testing teams share ownership.
Quality is everyone's responsibility.
Automation amplifies that culture. It doesn't replace it.
That's the difference between organizations that automate and organizations that genuinely improve.
After ten years of building and growing a company, a few convictions have become stronger than ever.
Test automation is not a goal in itself.
More tools do not automatically create better quality.
The most expensive defects are usually caused outside the codebase.
Performance issues are often discovered exactly when they become most painful.
Maturity is not created by documenting processes. It's created by changing behavior.
And perhaps the most important lesson of all:
Quality is not the responsibility of the QA team.
It's the responsibility of the entire organization.
As long as companies continue to delegate quality to a department, they will continue to struggle with it.
Looking back on ten years of b.ignited, I'm grateful for everything our customers have taught us.
We've helped organizations implement test automation. We've built TestOps capabilities. We've executed performance testing programs. We've conducted quality audits. We've provided highly specialized QA teams.
But the most successful engagements were never just about technology.
They were about trust. Collaboration. Leadership.
And people willing to challenge the status quo.
The greatest improvements didn't happen because of a new tool.
They happened because organizations changed the way they thought about quality.
I would start the conversation about culture much earlier and spend less time talking about tools.
I would push organizations sooner to define measurable quality objectives.
I would be more vocal about the fact that test automation is not a cost-saving initiative.
It's a business acceleration strategy.
And I would reinforce one message from day one:
Quality is not a department. It's a way of working.
Too many organizations invest in technology first and hope behavior will follow.
After ten years, I've learned it almost always works the other way around.
Our industry loves technology.
New frameworks. New platforms. New AI solutions. New testing tools.
And rightly so.
Innovation creates enormous opportunities.
But after ten years in business, I'm convinced that the single biggest driver of software quality is still not technical.
It's human.
It's the people who choose to care about quality.
The people who take ownership.
The people who have difficult conversations before issues become production incidents.
The people who understand that quality isn't a gate at the end of delivery, but a decision made every single day.
That may be less exciting than the latest technology hype.
But it's the truth I've learned after ten years of entrepreneurship.
Building software is about technology.
Building quality software is about people.
And that's where organizations still have the greatest opportunity to differentiate themselves.
Quality doesn't start with technology. It starts with people.
[NL]
Tien jaar geleden geloofde ik dat softwarekwaliteit vooral draaide om processen, tools en technologie. Vandaag weet ik beter.
Na honderden projecten en ontelbare gesprekken met CIO's, CTO's, QA-leiders en engineeringteams ben ik tot een eenvoudige conclusie gekomen:
Softwareproblemen zijn zelden echte softwareproblemen. Het zijn mensenproblemen.
Dat klinkt misschien verrassend voor iemand die een bedrijf leidt dat gespecialiseerd is in testautomatisering, TestOps, performancetesten, kwaliteitsaudits en QA-engineeringdiensten. Maar het is de les die zich gedurende tien jaar bouwen aan b.ignited telkens opnieuw heeft bewezen.
Toen we b.ignited oprichtten, ging ik ervan uit dat organisaties worstelden met softwarekwaliteit omdat ze onvoldoende expertise, tooling of methodologie hadden.
Soms klopt dat. Maar meestal niet.
Het echte probleem is doorgaans niet de teststrategie. Het is niet het automatiseringsframework. Het is niet de CI/CD-pijplijn.
Het zijn mensen die niet samenwerken.
Teams die verschillende doelstellingen nastreven. Afdelingen die in silo's werken. Leiders die zeggen dat kwaliteit belangrijk is, tot het moment waarop een releaseplanning onder druk komt te staan.
Iedereen beweert dat kwaliteit een prioriteit is. Tot snelheid ermee begint te concurreren.
Dan ontdek je wat de échte prioriteiten zijn.
Een vraag die we keer op keer horen, is:
"Waarom krijgen we onze kwaliteit niet onder controle?"
De meeste organisaties verwachten een technisch antwoord: een nieuw automatiseringsplatform, een betere testtool, meer testdekking, meer dashboards, ...
Maar na tien jaar audits, kwaliteitsverbeterprogramma's en TestOps-implementaties hebben we geleerd dat de onderliggende oorzaak vaak niet technisch is.
Ontwikkeling en testing werken los van elkaar. Testing wordt behandeld als een laatste controlepunt in plaats van een gedeelde verantwoordelijkheid. Kwaliteitsmetingen bestaan wel, maar worden niet gebruikt om beslissingen te nemen.
Teams worden beloond om sneller op te leveren, terwijl ze tegelijkertijd geacht worden de kwaliteit te verhogen. Dat is een conflict dat geen enkele tool kan oplossen.
Organisaties willen meer snelheid én betere kwaliteit, maar creëren vaak stimulansen die precies het tegenovergestelde gedrag uitlokken.
En precies daar ligt een van de belangrijkste lessen die onze klanten ons hebben geleerd.
Misschien wel de belangrijkste les die onze klanten ons hebben geleerd, is dat duurzame kwaliteit niet begint bij automatisering.
Ze begint bij een mindset.
De meest volwassen organisaties zijn niet noodzakelijk degene met de grootste automatiseringsplatformen of de meeste geautomatiseerde testen.
Het zijn de organisaties die kwaliteit hebben ingebed in hun manier van werken.
Kwaliteit wordt besproken voordat de ontwikkeling start. Defecten worden beschouwd als leermomenten. Business-, ontwikkelings-, operations- en testingteams dragen samen verantwoordelijkheid.
Kwaliteit is ieders verantwoordelijkheid.
Automatisering versterkt die cultuur. Ze vervangt haar niet.
Dat is het verschil tussen organisaties die automatiseren en organisaties die écht verbeteren.
Na tien jaar bouwen en groeien met een onderneming zijn enkele overtuigingen sterker dan ooit geworden.
Testautomatisering is geen doel op zich.
Meer tools leiden niet automatisch tot betere kwaliteit.
De duurste defecten ontstaan meestal buiten de code.
Performantieproblemen worden vaak ontdekt op het moment dat ze het meeste pijn veroorzaken.
Volwassenheid ontstaat niet door processen te documenteren. Ze ontstaat door gedrag te veranderen.
En misschien wel de belangrijkste les van allemaal:
Kwaliteit is niet de verantwoordelijkheid van het QA-team.
Ze is de verantwoordelijkheid van de volledige organisatie.
Zolang bedrijven kwaliteit blijven delegeren aan één afdeling, zullen ze ermee blijven worstelen.
Wanneer ik terugkijk op tien jaar b.ignited, ben ik vooral dankbaar voor alles wat onze klanten ons hebben geleerd.
We hebben organisaties geholpen bij het implementeren van testautomatisering. We hebben TestOps-capaciteiten opgebouwd. We hebben performancetestprogramma's uitgevoerd. We hebben kwaliteitsaudits gedaan. We hebben hooggespecialiseerde QA-teams geleverd.
Maar de meest succesvolle samenwerkingen draaiden nooit uitsluitend om technologie.
Ze draaiden om vertrouwen. Om samenwerking. Om leiderschap.
En om mensen die bereid waren de status quo in vraag te stellen.
De grootste verbeteringen kwamen niet voort uit een nieuwe tool.
Ze ontstonden omdat organisaties hun manier van denken over kwaliteit veranderden.
Ik zou veel vroeger het gesprek aangaan over cultuur en minder tijd besteden aan tools.
Ik zou organisaties sneller uitdagen om meetbare kwaliteitsdoelstellingen te definiëren.
Ik zou veel duidelijker communiceren dat testautomatisering geen kostenbesparingsinitiatief is.
Het is een strategie om de business te versnellen.
En ik zou vanaf dag één één boodschap blijven herhalen:
Kwaliteit is geen afdeling. Het is een manier van werken.
Te veel organisaties investeren eerst in technologie en hopen vervolgens dat het gedrag vanzelf volgt.
Na tien jaar heb ik geleerd dat het bijna altijd precies andersom werkt.
Onze sector houdt van technologie.
Nieuwe frameworks. Nieuwe platformen. Nieuwe AI-oplossingen. Nieuwe testtools.
En terecht.
Innovatie creëert enorme kansen.
Maar na tien jaar ondernemen ben ik ervan overtuigd dat de belangrijkste drijfveer achter softwarekwaliteit nog steeds niet technisch is.
Ze is menselijk.
Het zijn de mensen die ervoor kiezen om kwaliteit belangrijk te vinden.
De mensen die verantwoordelijkheid nemen.
De mensen die moeilijke gesprekken voeren voordat problemen uitgroeien tot incidenten in productie.
De mensen die begrijpen dat kwaliteit geen poort aan het einde van een opleveringstraject is, maar een beslissing die elke dag opnieuw wordt genomen.
Dat is misschien minder spectaculair dan de nieuwste technologische hype.
Maar het is wel de waarheid die ik heb geleerd na tien jaar ondernemerschap.
Software bouwen draait om technologie.
Kwaliteitsvolle software bouwen draait om mensen.
En precies daar ligt voor organisaties nog steeds de grootste kans om zich te onderscheiden.
Kwaliteit begint niet bij technologie. Ze begint bij mensen.