When Bugs Multiply in Mysterious Ways

At first, I thought this was good. I was wrong. Haha.

I recently found myself in a situation that felt like a lesson in patience, humility, and the strange dynamics of QA ownership. You know the type: the B.A./UX-UX person who “just wants to help,” jumps into QA, and suddenly it’s their feature. I want to unpack why, even with good intentions, this setup is a recipe for extra revisions, confusion, and minor-but-relentless changes that never end.

Let’s start with the facts. This person-let’s call him the QA enthusiast-wasn’t even asked to QA. He volunteered. He saw the QA process happening, and thought, “I can help.” Fair enough. He finds legit bugs, I won’t deny that. But the aftermath is a cascade of revisions, padding tweaks, copy adjustments, and layout changes that are far removed from the first handover.

A prime example:

1. “Let’s move the Viewing 1-50 Invoices of 164 Invoices beside Previous button.”
2. “Change the copy. Instead of SKU, change it to Invoices so it aligns with the page context.”

I was given this text in the first test results… and then asked to change it again. Minor? Maybe. Repetitive? Absolutely.

Here’s the thing: this person tends to gaslight, subtly and unintentionally-or maybe intentionally. Things like:

1. “I didn’t tell you to do that.”
2. Changing the Figma design unknowingly, leaving me scrambling to reconcile differences.

And it’s not just copy or padding. Look at the latest feedback (March 16):

1. Columns adjust oddly when hovered; spacing is unbalanced.
2. Sorting icons are misaligned relative to the column text.
3. Filter buttons show when they shouldn’t.
4. Dropdowns reopen unnecessarily.
5. Saved view renames create new views unexpectedly.
6. Pagination layout and copy require tweaks.

Some of these were legit bugs I had already addressed, some are minor tweaks, and some are a result of unclear browser behaviors like cache vs. cookies. The pattern? Many revisions come from differences in perspective rather than actual software defects.

Now, imagine being a developer tasked with implementing a feature. You hand it over. The QA enthusiast jumps in, points out valid issues, but then also makes subjective adjustments that aren’t agreed upon in the original scope. The first handover becomes a moving target. Every revision opens a new window of adjustments-sometimes contradicting the previous feedback.

The most frustrating part? Some of these changes originated from him. The very same person who now tells me, “Let’s change it,” was the one who first suggested the original text/layout. So I end up chasing my own tail: implementing his first suggestion, then modifying it based on his second, third, fourth round of notes.

I’ll be honest: this isn’t about being difficult or dismissing QA. QA is critical. Legit bugs are caught. But QA done by a B.A./UX-UX person who owns the feature in their mind is different from structured QA. You get:

1. Multiple subjective revisions
2. Copy tweaks with no clear scope
3. Layout tweaks that weren’t originally requested
4. A moving target for developers

It’s the perfect storm for inefficiency-and, let’s admit it, mild developer frustration.

So why shouldn’t the B.A./UX-UX person do the QA?

1. Perspective overlap creates conflict – They designed or suggested parts of the feature. Their “QA” is filtered through design preferences.
2. Minor adjustments escalate – Padding, copy, alignment-these small changes accumulate, delaying final delivery.
3. Original handover gets lost – The feature’s first state drifts further from the design spec and initial dev implementation.
4. Gaslighting potential – “I didn’t tell you to do that” or “Figma changed on its own” leaves devs questioning what’s intended vs. what’s personal preference.

In short: while intentions are good, the outcome is a QA process that feels like running in circles. And no, this isn’t a slight on the person-they’re talented, detail-oriented, and genuinely care. But one person wearing multiple hats-designer, UX consultant, and QA owner-creates noise in the feedback loop.

If I were writing a manifesto for efficient QA:

1. QA should be independent from the original design handover.
2. Feedback should be structured and scoped: bugs vs. suggestions.
3. Design suggestions belong in a design review, not QA rounds.
4. Developers need a stable target to implement.
5. Beware the well-meaning designer who, subconsciously improving the Figma, flags design refinements as “bugs”, intention is good, but it blurs the line between feature and personal polish.

So, devs, PMs, and designers: love your B.A./UX-UX colleagues, adore their eagle eyes-but maybe don’t let them run QA. Features survive, bugs get caught, and devs keep their sanity.

And to my QA enthusiast: thanks for the enthusiasm, but next time… let some bugs roam free. The official QA team is still hiring, you know. 😂