L0Core5 min read

What quality means when code is cheap

Writing code stopped being the bottleneck, so shipping more of it stopped being the win. Quality is now about whether the thing does what someone actually needed — a judgement no generator makes for you. Start here; it reframes everything below.

Software quality is how well a product serves the need it was built for, under the conditions it will really meet. Not how much code was written, and not how many tests passed.

Two halves sit inside that. Functional quality is whether it does the thing it was asked to do. Non-functional quality is whether it does it fast enough, safely enough and for everyone who needs it.

Here is why the definition had to change.

A team I heard about built a feature in two days that would have taken three weeks a year earlier.

Clean code. Tests passing. Reviewed and merged. Everybody pleased.

Four months later somebody checked the usage numbers. Eleven people had opened it. Two came back a second time. The feature answered a question no customer had actually asked, and it was built beautifully.

Nothing in that story is a coding failure. Every part of it is a quality failure, and that gap is what software quality means now.

The terms you will hear

Quality. Fitness for the purpose somebody actually had. The formal phrase is "fitness for purpose".
Defect. Any behaviour that differs from what was agreed or needed. A bug is the same thing in ordinary speech.
Defect escape. A defect that reached production without being caught. The number teams track most.
Quality gate. A condition that must pass before work moves on, such as a green pipeline or a review.
Definition of done. The checklist a team agrees before a story counts as finished.

The old definition and why it slipped

For a long time quality meant "does it match the specification". That was reasonable, because building anything was slow and expensive. If code took three weeks to write, the specification had been argued over for a month first.

Now a competent engineer with a coding assistant produces a working feature in an afternoon. The expensive part moved. It is no longer the typing. It is deciding what to build, knowing whether it worked, and finding out what it broke.

Picture a builder who can now build a wall in one hour instead of two days. Speed helps nobody if the wall is in the wrong place, and it makes the wrong wall arrive sooner.

What quality means instead

Four questions, in the order they bite.

Did it solve the actual problem? Not the ticket. The problem the ticket was trying to describe.
Does it work, including on the paths nobody planned? The empty state, the slow network, the customer with 400 orders.
What did it cost? Latency, money, complexity, the next person's time.
How would we know if it broke? If nothing would tell you, the feature is untested no matter how many tests it has.

Notice how few of those a test suite answers. That is not an argument against tests. It is the reason a tester is more than a person who runs them.

How you use this on Monday

Ask what problem this solves, out loud, in refinement. If three people give three answers, you have found the most valuable defect of the sprint before any code exists.
Ask how we will know it worked. A number, an event, a support metric. "People will like it" is not a way of knowing.
Test the paths a real person takes, not only the path the story describes. Say the story covers adding one item to a basket. Real customers add six, remove two, then leave for an hour. Session-based exploratory testing is how you do that on purpose.
Report cost as well as correctness. "It works and it adds two seconds to checkout" is a quality finding.
Say what you did not check. Silence is read as coverage, which is the quietest way quality information gets lost.
Keep a record of what was tested. Six months later, "did anybody check this" needs an answer, which is what a defensible release record is for.

Working software is a coding question. Useful software is a quality question. Only one of the two shows up green in a pipeline.

A worked example

Here is the same story told as a one-page review, which is how you turn a vague worry into something a team can act on.

quality-review-saved-filters.txt

FEATURE   saved filters on the orders page
BUILT     2 days. shipped 14 April.

WHAT THE TICKET SAID
  "Users want to save their filter settings."

WHAT WE NEVER ASKED
  which users? the support team asked for this, in one meeting, in
  February. no customer asked.
  how would we know it worked? nobody wrote a number down.

WHAT WORKING MEANT
  8 unit tests, 2 browser tests, all green. code reviewed. no defects
  reported in four months.

WHAT ACTUALLY HAPPENED
  11 people opened it. 2 returned. support still exports to CSV, because
  the filter they wanted saved is a date range and the feature saves
  everything except the date range.

WHAT A TESTER COULD HAVE ASKED IN REFINEMENT
  1  who asked for this, and what were they doing when they asked?
  2  which filter do they save most often today?      <-- would have found it
  3  how will we know in a month whether it helped?

COST OF ASKING     about four minutes
COST OF NOT ASKING two days of build, four months of maintenance, and a
                   support team still exporting CSVs

The third question is the whole discipline. Nobody needed a testing qualification to ask it, and asking it in February would have changed what got built.

How to show you know it

A refinement question that changed the scope. One example, told in two sentences, is worth more in an interview than a list of tools.
A cost finding. "It works, and it added 1.4 seconds to page load." It proves you report quality rather than only correctness.
A stated gap. Writing down what you did not test is a mark of seniority, not an admission.
A usage number you went and looked up. Very few testers close the loop after release. The ones who do get listened to.

Questions

Is this not the product manager's job?

They own the decision. You own asking the question early enough for the decision to be cheap. In practice the tester is often the only person in refinement whose job is to be sceptical, which makes it your question by default.

Does this mean tests matter less?

No, it means tests answer a narrower question than people think. They tell you the code does what somebody said. They cannot tell you whether that was worth doing, and both facts matter on the same day.

My team just wants me to find bugs. How do I start?

Keep finding bugs, and add one habit. In every refinement, ask what problem the story solves and how we would know it worked. It costs a minute and it will change what people think testing is for.

How do I measure quality then?

Not with one number. Pair a correctness signal with an outcome signal, such as escape rate alongside whether usage moved. The four metrics worth reporting is a reasonable starting set.