Episode 5: Working With QA — Not Against Them

Jona Obrador • May 19, 2026

There's a quiet tension that runs through a lot of development teams. Engineers build, QA tests, bugs get thrown back, and the cycle repeats. On paper, it works. In practice, it becomes a loop: fix, test, fail, fix, test, fail.



That's not collaboration. That's a slow relay race.

Where QA Actually Fits in the Development Process

What's Already True Before a PR Is Opened

Let's connect the dots from the earlier episodes. In Episode 1: Requirements Are Incomplete, we covered how specs rarely arrive fully formed. Episode 2: Estimation Is About Risk explored the trade-offs baked into every timeline. Episode 3: Communication Makes Things Visible showed how much depends on what gets surfaced. And Episode 4: Code Reviews Are Not a Formality established how reviews improve decisions, not just code.


So where does QA fit into all of this? QA is where assumptions get challenged in reality. Not in theory, not in design — in actual behavior.

By the time a pull request lands in your queue, the first three stages of the development process have already played out. In Episode 1, we established that specs rarely arrive fully formed. Episode 2 showed how every timeline carries hidden trade-offs. And Episode 3 explored how much depends on what gets surfaced — and what doesn't.


That code is already built on assumptions. It reflects incomplete context, prioritization calls, and decisions no reviewer was present for.

Where QA Actually Fits in the Development Process

Here's the shift most teams miss: QA is not there to catch your mistakes. They're there to expose gaps in thinking.

How to Work With QA as a Thinking Partner

1. Bring QA In While Things Are Still Forming

Bring QA In While Things Are Still Forming

If QA only sees your work after you're done, it's already too late. The better move is to involve them while the work is still taking shape.


Instead of handing off a finished build, try: "This is how I'm planning to handle partial payments and reversals. Does anything look risky from a testing perspective?"


Bringing QA in early means they can:

  • Spot missing scenarios before code hardens
  • Suggest edge cases you haven't considered
  • Help shape behavior before it becomes expensive to change

Working code is the minimum bar, not the finish line. Effective code reviews push beyond syntax to the structural questions that matter long-term.


Questions worth asking during any review:

  • What happens when this runs on a high-volume account?
  • Is this logic tied too tightly to a single module?
  • Are we solving today's requirement or creating tomorrow's technical debt?

That's how teams prevent bugs — not just detect them.

2. Prevent Bugs Instead of Just Catching Them

Catching bugs is reactive. Preventing them is where strong teams operate. The difference often comes down to how early QA thinking enters the process.


QA tends to think in edge cases, failure scenarios, and "what if this breaks?" situations. Engineers tend to think in happy paths, functional flow, and "does it work?" Put those two perspectives together early, and you get systems that are more resilient and less surprising in production.

Catching bugs is reactive. Preventing them is where strong teams operate. The difference often comes down to how early QA thinking enters the process.


QA tends to think in edge cases, failure scenarios, and "what if this breaks?" situations. Engineers tend to think in happy paths, functional flow, and "does it work?" Put those two perspectives together early, and you get systems that are more resilient and less surprising in production.


Instead of waiting for QA to flag: "This breaks when the exchange rate is missing" — ask the question first: "What happens if exchange rate is null here?"



That's a completely different workflow.

Prevent Bugs Instead of Just Catching Them

Instead of waiting for QA to flag: "This breaks when the exchange rate is missing" — ask the question first: "What happens if exchange rate is null here?"


That's a completely different workflow.

3. Stop Measuring QA by Bug Count

Stop Measuring QA by Bug Count

This one is subtle but important. If success means "QA found many bugs," then a clean QA pass looks like failure — and that's backwards.



The real signal of a high-performing team is that QA has fewer bugs to report because the thinking was already solid. And when QA does raise something, it's not noise. It's a meaningful gap worth taking seriously.

This one is subtle but important. If success means "QA found many bugs," then a clean QA pass looks like failure — and that's backwards.


The real signal of a high-performing team is that QA has fewer bugs to report because the thinking was already solid. And when QA does raise something, it's not noise. It's a meaningful gap worth taking seriously.

The Uncomfortable Truth About QA

If QA feels like it's slowing you down, there's a good chance they're seeing risks you didn't — or the process brought them in too late.



In high-performing teams, QA doesn't slow engineers down. They prevent engineers from slowing themselves down later.

If QA feels like it's slowing you down, there's a good chance they're seeing risks you didn't — or the process brought them in too late.


In high-performing teams, QA doesn't slow engineers down. They prevent engineers from slowing themselves down later.

The Uncomfortable Truth About QA

Think With QA, Not Past Them

The best engineers don't aim to pass QA. They aim to think with QA, design with QA, and break the system before QA has to.


Once QA becomes a partner in thinking — not just testing — the results shift: fewer back-and-forth cycles, fewer production surprises, and stronger confidence in what ships.


At ATSOURCE, developers are built for this kind of collaboration. They come prepared to work across the full development lifecycle, not just the build phase. Let's talk about building your NetSuite development team the right way.


Next up: Episode 6: Handling Production Issues Without Panic. Because clean code is great — but real engineering starts when things break.

Jona Obrador Senior Netsuite Developer

Meet the Author

Jona has over a decade of experience in SuiteCloud Development on the NetSuite platform. She specializes in implementing advanced solutions and has led teams in creating high-quality software. Jona holds multiple certifications and has been recognized with awards like the Summit Award and Quality Champion Award.

Tags

Accelerate ERP Success with Expert Solutions

Ready to put what you've learned into practice? ATSOURCE delivers both the specialized talent and comprehensive NetSuite support you need to turn strategy into results.‍Connect with our experts today and move from planning to performance.

Purple illustration of a shield, code window, and documents on a podium, suggesting cybersecurity software

Episode 4: Code Reviews Are Not a Formality

By Jona Obrador • May 12, 2026
Code reviews are more than a checklist. Learn how NetSuite development teams use them to catch blind spots, share judgment, and build better systems.
Floating question marks and a lightbulb above white podiums, with a purple gear on the right.

Episode 3: Engineer Communication Skills: Why Knowing Isn't Enough

By Jona Obrador • May 5, 2026
Discover why engineer communication skills matter as much as code quality—and how raising risks early keeps NetSuite projects on track.
Episode 2 promo: purple slide, “NetSuite Project Estimation: Why It’s About Risk, Not Time,” with computer illustration

Episode 2: NetSuite Project Estimation: Why It's About Risk, Not Time

By Jona Obrador • April 28, 2026
NetSuite project estimation isn't a time prediction — it's a risk assessment. Learn how strong developers surface uncertainty early and make estimates teams can actually plan around.