What Frontend Development Taught Me About Breaking Software

Rhazeb Brown — Sun, 12 Jul 2026 10:42:00 +0000

I used to write React components for a living. Now I lead a QA team. The thing that made me switch wasn’t burnout or a better salary. It was realizing that the part of me that used to annoy my dev team was actually the most useful part of me.

The habit that used to get side-eyed

When I was building features, I had this habit of not letting a ticket go once it was “done.” I’d poke at it. What happens if you tap the button twice fast? What if you’re mid-action and your wifi drops? What if you rotate the screen right when a modal pops up?

Some teammates found that mildly annoying, honestly. We were trying to ship. Nobody wants the guy asking “but what if” on a Friday afternoon standup.

Turns out that guy just hadn’t found the right job title yet.

A real example: the shuffle bug

Right now I QA a devotional app: audio player, playlists, the whole thing. We had a bug where hitting shuffle on a playlist would restart the currently playing track instead of just reshuffling the queue. Small thing on paper. Annoying in practice. You’re mid-devotion, you tap shuffle, and it yanks you back to 0:00 on the same track.

Because I’d built UIs before, I wasn’t just clicking around going “yep, broken.” I actually had a hunch about where it was coming from. Shuffle was probably re-triggering the player’s mount/load logic instead of just reordering an array in state. That’s a very “I’ve written this exact bug myself as a dev” kind of guess. I logged it with that context instead of just “shuffle restarts track,” and it got fixed and confirmed within the sprint.

That’s the part nobody tells you about coming from frontend into QA, you’re not just testing the outcome, you’re testing with a working theory of what the code is probably doing underneath. That’s a huge shortcut.

Passing doesn’t mean protecting

Here’s the lesson that actually changed how I write test cases: a test can pass and still be worthless.

I used to write things like “user enters correct email and password → logs in successfully” and call it covered. That test passes every time. It also tells you almost nothing, because that’s the one path that was never going to fail. The real bugs live at the edges — expired sessions, a role that shouldn’t see a screen but somehow can, a network call that dies halfway through.

Once I actually internalized that, my test cases got a lot less tidy and a lot more useful. Less “does it work,” more “what would this miss if something was quietly wrong.”

Where I’m at now

Day to day I’m running manual and automated testing across mobile — Appium and Maestro — plus API testing in Postman, and I’m actively building up JS/TypeScript automation with Jest, Playwright, and WebDriverIO. But the actual skill underneath all of it is still the same one that used to get me side-eyed in dev standups: not trusting that something works just because it looks fine on the surface.

If you’re a developer who can’t stop picking at your own team’s “done” tickets — that’s not a personality flaw. That’s a career waiting to happen.

DEV Community: Rhazeb Brown

What Frontend Development Taught Me About Breaking Software