Building a QA culture means shifting a company from ad hoc, deadline-driven testing toward a shared understanding of quality across all roles: developers, product owners, stakeholders, and testers alike. It requires mapping what each group means by quality, translating those views into a visible strategy, and introducing process changes gradually so teams can adapt without resistance or burnout.
Key Takeaways
- QA professionals are feedback givers for all development teams, not just testers, and that broader role is what makes quality improvement possible across an entire organization.
- Introducing too many changes at once creates team fatigue and resistance; one significant change per quarter, fully measured before the next begins, keeps adoption stable.
- Framing quality failures as financial cost, by calculating what a late-stage defect costs to fix, is the argument that moves business stakeholders from skepticism to willingness to invest.
- Consulting everyone affected by a change before rolling it out, and letting them shape parts of it, turns potential resisters into partial owners who advocate for the new approach.
- Visibility of QA work, through regular reports and status updates that use tables and clear metrics, closes the gap between what testers do and what management and stakeholders actually see.
QA is feedback, not just testing
Quality assurance is the function that gives feedback to every development team, not a step that only runs tests at the end. That distinction shapes everything about how a quality culture gets built inside a company.
Filip Leszek Barszcz works in the finance industry across FX, fintech, mobile, and web systems, and he picks companies that struggle with their QA approach on purpose. The pattern he sees outside the testing community is the same one again and again: people assume QA means testing, full stop. They often don’t even separate a tester from a QA engineer in their heads.
The job is broader than that. A QA delivers feedback, and not always the good kind. Bad news is part of the work. The useful frame is a double position: the last line of defense for the company, and the first line of defense for the customer. Hold both at once and the role stops being about clicking through screens.
This has shifted over the past decade. Ten years ago the work was manual testing and reporting issues, and that was it. Now there are more duties and a wider reach, which means a QA can improve not only their own processes but the processes of other teams.
What a company without a QA culture actually looks like
A company with no QA culture runs on ad hoc testing under deadline pressure. Something needs to ship in three days, so people throw whatever resources they have at it. The work comes in short, intense bursts.
That intensity has a cost. Hyper-focus crammed into a few days can push QA specialists toward burnout, because the workload spikes far above what is sustainable.
The technical picture underneath varies, and Filip has seen both extremes. One company had strong unit and integration tests but weak end-to-end coverage and weak manual discovery testing. Another had only unit tests, no integration or E2E layer, with almost all the quality weight dumped onto manual testers.
Because the gaps differ, there is no single fix. Each company carries something unique, and the entry point is finding where a good practice can take hold for that specific product.
Why everyone in the company means something different by “quality”
The first obstacle to a quality culture is that the word “quality” means a different thing to each role. Stakeholders, component owners, product owners, and technical leaders each hold their own view, and they rarely notice the others hold a different one.
Stakeholders in one company cared about uptime. They wanted to know how long the system stayed open for earning money, and they looked at the window of opportunity rather than at an individual client’s problem.
Business owners one level down cared about the customer experience. They wanted the product smooth, intuitive, friendly to use. Performance came up sometimes, but their attention sat on how the customer felt moving through the product.
So the starting work is mapping these views. Talk to people across positions, write down how each group understands quality, and build a table: developers think about it this way, product owners differently, stakeholders differently again. Then translate every group’s hopes into QA language. What comes out of that translation is a roadmap of what people actually expect.
How to build the case before you change anything
Getting management to fund QA work starts with comparison, not theory. Competitors often advertise their quality maturity, including formal TMMi levels, and they don’t hide it. Set your product, your earnings, and your maturity next to theirs, and the business side starts paying attention.
Cost makes the second argument. Show how much money goes into fixing defects late in development. Filip presents an estimated calculation drawn from public salary data, then puts a number on a single issue, for example 15,000 euros to fix. The reaction is predictable: how, and why. The questions open the conversation.
From there you show the saving. Move testing earlier, from a late environment to one before it, and the business starts counting the money it keeps. Once there is money saved, there is money to invest.
A proof of concept turns the argument into evidence. In Filip’s current company, a POC ran with one team alongside developers and component owners. The results were strong enough to roll the solution out to all teams, and management then committed more budget because they could see the product moving to a higher level. Fewer rollbacks and fewer customer problems freed people to focus on real work.
Stakeholders fund what they can see
Visibility is what turns a skeptical business into a willing investor. Where QA culture is missing, the business doesn’t see QA work at all, so it won’t pay for it.
Reporting closes that gap, and the format matters more than QA people expect. Stakeholders and business leaders respond to tables with color. A weekly or monthly report built that way, showing how things look from their perspective, makes them eager to invest.
After seven months of steady reporting in his current company, the business was willing to fund quality because the purpose and the value were finally in front of them.
Visibility cuts the other way too. Use it to credit the developers and other contributors, not only the QA team. Praising the effort that came from outside QA builds the team spirit inside the unit, and that matters as much as any metric.
Start with the cleanup in your own yard
The first changes should sit entirely inside QA’s own control, because those are the quick wins. Observe and analyze your own QA work, then fix what you can fix alone.
A few concrete moves carry most of the early value:
- Narrow the number of priorities so they stay clear, and define what each priority means from the business side.
- Announce the testing state out loud: when an environment is fragile and important, ask people not to deploy and disrupt the work.
- Add a regression status and a scope checklist to the release notes, so the information stops getting lost.
Most of this is sharing information that was previously stuck. Where a stream of information is blocked, unblocking it helps QA and every department downstream.
The cost is small against the return. Two to four hours a week moving information from one place to another, plus a short call to explain the current state, saves real effort across many people and lets them focus elsewhere.
These small improvements also create roles. One tester owns the regression status, another owns the checklist, developers own part of the checklist. The model is 1 percent better per day. Compound that across a year and the change is large.
How to roll out a large change without breaking the team
A large change needs an adaptation window, not a launch date. Filip set three months for the major workflow change he is running now, and he consulted everyone the change would touch before it went live.
Consultation is how you turn resistance into ownership. Product owners added a meeting to extend the bug triage. DevOps added a step to the checklist. Component owners asked for additional environments. The core idea stayed the same, but every affected group shaped a piece of it, so each of them became a partial owner.
Resistance usually comes from not knowing. People push back against what is unknown to them, so the new workflow has to be presented and shared before anyone is asked to sign on to it. The flow moved through approval top down: the technical tribe leader first, then the level below, then the level below that.
Volunteering accelerates adoption. One proactive team agreed to test the new workflow early, and after a month the outcome was strong enough to report. A second team then asked to start before the planned 2026 date, because they didn’t want to fall behind the team they compete with.
The instinct to do it all in one week is the wrong one here. Shock therapy works for small things; a workflow change at this scale would be too much to handle in that part of the year. For small changes, it is easier to ask forgiveness than permission, so test those yourself. Large changes need the slower path.
Don’t stack changes faster than people can absorb them
Too many changes at once produces a tired, unstable team that starts resisting everything. Filip has made that mistake, and the lesson stuck.
His rule now is one significant change per quarter, where “significant” still does not mean enormous. Introduce one change that improves something, measure its impact, then prepare the next. If the first change isn’t bedded in properly, the next one waits.
“If we introduce too many changes, you just make a tired team. There was a lack of stability for that, and people just start resisting the changes.” Filip Leszek Barszcz
Stability after a change is the signal that you can move again. Without that pause to let things settle, each new change lands on an unsteady base.
When is the quality work “done”?
There is no fixed finish line, because the right level of quality depends on the customer and the context. What fits one company is waste in another.
CI/CD shows the trap. In one team a CI/CD approach made sense. In a different company, heavy legal obligations made full CI/CD a goal they wanted, but from a QA cost perspective it would have burned resources for little return.
The decision tool is a cost-versus-effort view: how much time goes in, and what comes back. That is why so much time goes into analysis and discussion with business and technical leaders, to understand whether a practice is even applicable from the dev and DevOps side and what business outcome it produces.
The same standard applies everywhere, even though the answer changes. A company in one market cannot be compared to one in finance: different outcomes, different mentality, different weight of work. In the end the business pays to ship a product, and every quality decision has to earn value for that product.
