The assembly line problem

There's a model of software development that feels intuitive but quietly causes damage. A Product Manager defines a feature. A Designer shapes it. An Engineer builds it. Then it gets handed to a QA team, who are expected to find every flaw, catch every edge case, and certify the thing ready for the world.

‍

It feels clean. It has clear handoffs. It doesn't work.

‍

Software isn't a car on a factory floor. You can't inspect quality into it at the end. By the time code reaches a QA specialist in that model, decisions have already been made, patterns have already been set, and the cost of fixing anything real is several times higher than it would have been a week earlier.

‍

You end up with a team of very capable people firefighting problems that should never have existed.

‍

We've moved away from that model at Kora, and this post explains how we think about quality instead.

‍

Shifting left

"Shifting left" is engineering shorthand for catching problems earlier in the process. The name comes from imagining a timeline left to right, where production is on the right.

‍

Shifting left means moving quality thinking as far toward the start as possible. In practice, this looks different for each role.

‍

Product Managers write requirements that are specific enough to be testable. Not "the user should be able to make a payment" but "the user should receive a confirmation within 3 seconds, see an error state if the request times out, and be prevented from submitting twice."

‍

Clear requirements don't just help QA. They prevent the kind of scope ambiguity that costs weeks mid-sprint.

‍

Designers map edge cases and error states before designs are finalised. What does the empty state look like? What happens on a slow network? What does a partially completed form look like if the user navigates away? These questions are cheap to answer in Figma. They're expensive to answer in code.

‍

Engineers write unit tests and clean, testable code before a PR is opened for review. Not as a box-ticking exercise, but because code that's hard to test is usually code that's doing too much. The test-writing process surfaces design problems before they become integration problems.

‍

None of this replaces dedicated QA work. It changes what dedicated QA work is spent on.

‍

The Swiss Cheese model

In risk management, there's a useful framework called the Swiss Cheese Model. Each layer of a system has gaps. A single slice of cheese has holes. Stack enough slices and the holes stop aligning.

‍

A QA team as the sole quality gate is one slice. Issues align with the holes and reach users. When every discipline adds its own layer of scrutiny, the holes get covered. What a developer misses in their own code, a peer reviewer catches.

‍

What slips through review, an automated test catches. What slips through automation, an exploratory QA session catches. No single layer is expected to be perfect. The system as a whole becomes resilient.

‍

This is how we try to operate at Kora. Not because any individual on the team is fallible, but because everyone is, and building in overlapping layers of care is more honest than pretending otherwise.

‍

What this means for QA engineers

When quality becomes a shared responsibility, the role of a dedicated QA engineer changes. The job stops being about catching what everyone else missed and starts being about raising the floor for the whole team.

‍

That looks like building automated test infrastructure that other engineers can contribute to. It looks like running sessions that help product and engineering think through edge cases earlier. It looks like being the person in the room who consistently asks "what happens when this goes wrong?" before anyone has written a line of code.

‍

The dynamic shifts from "look what you broke" to "look at what we caught before it ever reached a user." That's a better job, honestly. It's also a more effective one.

‍

Empathy as a specification

A bug isn't just a broken line of code. For the merchant trying to reconcile their transactions at the end of the month, it's a frustrating hour. For the business owner waiting on a settlement to make payroll, it's worse than that.

‍

When you hold that in mind while building, the definition of "done" changes. A feature isn't done because it compiles and passes tests. It's done when you'd be comfortable watching someone who depends on Kora use it for the first time.

‍

That's the standard we hold ourselves to. It's harder than a checklist. It's also harder to argue with.

‍

What we hold ourselves to

These aren't aspirations. They're the things we try to do consistently:

‍

- Own your slice. Regardless of role, the question is always: how am I protecting the user experience right now, in this specific piece of work?

‍

- Bring quality in early. QA, engineering, design, and product in the same room before code is written, not after it's merged.

‍

- Treat a caught flaw as a win. Finding a problem during the process is exactly what the process is for. It's not a delay. It's the system working.

‍

Quality built this way is quieter than quality bolted on at the end. Users don't notice it, which is exactly the point.