At a marketing services SaaS provider, QA is involved before development starts and immediately after development finishes.
That timing is intentional. QA participates in refinement, adds testing details, challenges vague acceptance criteria, and makes sure the work can actually be validated. Then, after development, QA checks whether the requirements were met and whether the change introduced regressions while the story is still fresh in the developer’s head.
That is not ceremony. That is a tight feedback loop.
Quality problems are not all created equal. A defect caught in planning pays dividends. A defect caught at the keyboard costs almost nothing. A defect found in production costs real money in developer time and lost customer confidence.
That cost curve exists because feedback latency matters. The longer the system waits to learn, the more expensive the lesson becomes.
This is why QA belongs in the loop: not as a final inspection step, not as a clerical gate at the end of development, and not as the person who gets handed a pile of work after everyone else has already decided what the software is supposed to do. QA belongs in the loop because QA helps the team orient around what correct actually means.
QA Is an Orientation Function
In The Loop Is the Easy Part, I wrote that the loop itself is not the hard part. Observe, Orient, Decide, Act sounds simple until you realize the whole thing depends on orientation. If the team is oriented poorly, faster loops just help it make the wrong decision more efficiently.
QA is one of the most important orientation functions in a software delivery system. Good QA does more than find bugs. Good QA helps the team understand what correct means. It catches ambiguity, missing acceptance criteria, regression risk, edge cases, permissions issues, data states, workflow assumptions, and implied expectations.
A developer may implement exactly what the ticket says and still miss what the workflow requires. A product owner may describe the happy path clearly and still miss the awkward state the customer hits every Thursday afternoon. A designer may define the screen and still miss the way real data breaks the layout.
QA lives in those gaps. That is the value. QA sees the space between “the ticket was implemented” and “the user can successfully complete the workflow.” That space is where a lot of real software quality lives.
QA in Refinement Catches Defects Before They Exist
Across multiple organizations I have worked with, the best teams involved QA in refinement. QA added testing details. They challenged vague acceptance criteria. They made sure each requirement could actually be validated.
That matters because untestable requirements are unfinished requirements.
If the acceptance criteria say the screen should be “easy to use,” QA can force the conversation before development starts. Easy for whom? What task are they completing? What states matter? What should happen when the data is missing, stale, invalid, or incomplete? What should not change? What permissions apply? What legacy behavior must be preserved?
Those questions are not overhead. They are defect prevention.
A requirement that cannot be tested is a requirement the team does not fully understand. If the expected behavior is ambiguous, the team will discover the ambiguity later. If the edge cases are unknown, the team is choosing to discover them later. If the regression risk is unnamed, the team is choosing to learn about it after the work is already in motion.
QA in refinement pulls that learning forward. That is the best kind of quality work because no code has been written yet. Nothing has to be rolled back. No developer has to context-switch back into a half-forgotten implementation. No customer has to explain why a broken workflow damaged their trust.
The team simply learns earlier.
QA Immediately After Development Is Still a Tight Loop
At a marketing services SaaS provider, QA is a step that happens immediately after development. QA validates that the requirements were met and that the change did not create regressions. If something is wrong, the work item goes back to development while the implementation is still fresh.
That timing matters. The developer still remembers the code. The story is still loaded in their head. The branch is still recent. The assumptions are still visible. The feedback has not become archaeology.
Sometimes this creates back-and-forth. That can feel inefficient, especially when the same work item moves between development and QA more than once. Even then, the loop can be doing useful work.
QA may be helping the developer achieve the proper orientation. The developer believed the change was correct. QA is showing the gap between that belief and the requirement, workflow, data state, edge case, or user behavior the software actually has to support.
That is not automatically failure. The failure is when the loop teaches nothing.
If the same class of issue comes back repeatedly, the team should not blame QA for catching it repeatedly. The team should ask why the developer, story, acceptance criteria, test data, code standard, or review process did not improve after the first pass.
The point of a feedback loop is not merely to reject bad work. The point is to teach the system.
QA During Development Shortens the Distance Even More
QA does not have to wait until a work item is formally complete.
Sometimes the best quality move is a five-minute conversation during implementation. A developer can ask QA to look at a risky workflow before the whole feature is wired together. QA can validate an interpretation, point out an edge case, confirm the test data, or catch a mismatch between the ticket and the way a user will actually use the feature.
That is not QA hovering over development. That is the loop tightening.
The classic failure pattern is familiar. A developer says, “It meets the ticket.” QA says, “Yes, but it does not work the way the user will use it.” The developer is technically correct in the narrow sense, and QA is correct in the system sense.
That argument is expensive at the end. It is cheap in the middle.
If QA can help the developer orient while the code is still forming, the team avoids the formal handoff defect. The work does not need to bounce. The story does not need to reopen. The developer does not need to unwind a completed implementation.
The learning happens while the work is still soft.
QA Is Not UAT
This is where many organizations muddy the language.
QA and UAT are not the same thing. QA asks whether the thing was built correctly. UAT asks whether the correct thing was built.
Those questions overlap, but they are not identical. QA is part of the delivery feedback system. UAT sits closer to the business acceptance boundary. QA validates requirements, regressions, edge cases, and functional correctness. UAT validates business fit, workflow acceptance, user confidence, and whether the delivered behavior actually supports the intended outcome.
When organizations confuse those loops, both get worse. QA becomes a late paperwork step. UAT becomes business-user bug hunting. Product owners get surprised. Developers get frustrated. Business users lose confidence because the first time they touch the work, they are finding issues the delivery team should have already caught.
By the time UAT starts, the team should know the work is functionally correct. That does not mean UAT will find nothing. It means UAT should be answering a higher-value question than “does the button work?”
If UAT is the first serious test pass, the delivery loop leaked.
The Goal Is Earlier Learning
The goal is not to make QA catch more bugs. The goal is to make the system learn earlier.
If QA is always overloaded at the end, the process is telling you something. If QA keeps finding the same kinds of defects, the process is telling you something. If UAT regularly becomes regression testing, the process is telling you something. If production keeps revealing cases everyone says “nobody could have known,” the process is telling you something.
The answer is not always more testing. Often, the answer is earlier, and more focused, orientation.
Bring QA into refinement. Make acceptance criteria testable. Ask about edge cases before development starts. Give developers fast access to QA during implementation. Keep the post-development QA loop close enough that the developer still has the work in mind. Treat repeated defects as system feedback, not just individual misses.
That is how the loop gets better. QA at the end can tell you what broke. QA in the loop helps the team understand what correct means before the mistake becomes expensive.
That is the difference between inspection and feedback.
Receipts
- Marketing services SaaS provider: QA is involved in refinement and often adds testing details before development begins.
- Post-development gate: QA validates requirements and regression risk immediately after development, which keeps the feedback close enough that the developer still has the implementation in mind.
- Back-and-forth signal: When a work item bounces between development and QA, the team treats that as orientation feedback instead of merely blaming QA for finding problems.
- QA versus UAT: QA validates functional correctness before business users see the work. UAT should test business fit, workflow acceptance, and user confidence, not serve as the first serious quality pass.