"It Works."

Written by Anass R. · Sr. QA Automation Engineer · DoQALand

The most dangerous sentence in software.

Same software. Same release. Five definitions of working.

What quality culture actually looks like

Quality culture is not a checklist. It is not a process diagram on a wall. It is not a definition of done in your project management tool.

Quality culture is when every person in the chain instinctively thinks one layer beyond their own role. Not doing someone else's job. Just understanding what "it works" means to the person after them.

• The developer who asks "will this be testable?" before merging.
• The QA engineer who flags a performance risk to Ops before release.
• The support agent who reports a trend before it becomes an incident.
• The product owner who asks "what did we ship?" and actually reads the release notes.

That is not process. That is culture.

The gap between roles is where bugs live

Here is the uncomfortable truth I've seen across every team I've worked with: each role has a clear definition of "it works," and each definition stops exactly where the next role begins.

The developer ships code that passes tests. But those tests verify code behavior, not user behavior. QA tests the spec. But the spec doesn't mention what happens when two features interact in a way nobody designed for. Ops monitors uptime. But uptime doesn't mean the feature actually works the way the user expects.

Nobody is wrong. Everyone did their job.

No document fixes this

I've seen teams write beautiful definitions of done. Detailed acceptance criteria. Comprehensive test plans. Exit criteria for every stage.

And I've seen bugs reach production anyway.

Because the developer didn't read the test plan. Because QA didn't attend the architecture discussion. Because Ops wasn't looped in until the deploy. Because Support found out about the release from a customer complaint.

The documents were perfect. The communication was broken.

Quality culture is not about better documents. It is about building habits:

• The habit of asking "who is affected by this change besides me?"
• The habit of sharing context upstream and downstream, not just within your team.
• The habit of treating a release as a shared responsibility, not a relay race where you hand off and stop caring.

How you know you don't have it

You don't have quality culture when the post-mortem always reveals that someone knew about the risk but didn't say anything.

You don't have it when QA finds issues in the last hour of the sprint that were predictable from the design.

You don't have it when "it works on my machine" is still a phrase people use without irony.

You don't have it when Support builds workarounds for bugs that engineering never hears about.

You don't have it when the CEO asks "why did this break?" and the answer is "nobody tested that scenario." Nobody tested it because nobody knew it existed.

How you build it

Not with a wiki page. Not with a new tool. Not with a mandatory checklist.

You build it by making the invisible visible.

Make the developer see what QA tests. Make QA see what Ops monitors. Make Support's patterns visible to the team. Make the release a shared moment, not a handoff.

Start in the meetings: invite QA to refinement, not just to the testing phase. Let Ops weigh in on architecture decisions that will affect their on-call. Give Support a seat at the retrospective.

Start in the habits: ask every person on the team to describe what "it works" means to the person after them in the chain. If they can't answer, that's your gap.

AI is starting to help close some of these gaps, giving testers visibility into code changes, giving developers visibility into test coverage, giving everyone a shared view of what actually shipped. But the technology only works if the culture is ready for it.