Module 1 · Software & QA foundations

Why Software Testing Matters

By the Mutqan Soft QA team · · 18 min · Beginner

Software is built by people, and people make mistakes. Some mistakes leave a defect in a requirement, a design or the code, and some defects cause a failure: the running system does something it should not, or fails to do something it should. Testing matters because it finds these problems before users do and tells the team how much risk is left before a release.

For example, a shop's update applies a discount code twice when a customer goes back from payment to the cart. Nobody complains, but every such order loses money until someone spots it in the accounts weeks later. One test of the "back to cart" path would have shown the failure in minutes.

Why it matters

Failures cost a product money and trust, and in some domains people's safety or the company's legal standing. Testing is how a team learns, before release, which of these it is exposed to.

For you as a tester, this is the reason behind every choice. You can never test everything, so you test most where a failure would hurt most, and you report in the terms the team decides with: what could go wrong, for whom and how likely it is, not only how many tests passed.

What a failure can cost

The cost of a failure is everything that happens to users, the business and the team because it reached them, not only the time to fix it. The same defect can be minor in one product and serious in another: a wrong date format annoys the readers of an internal report but is a safety problem in a medication schedule.

  • Money: lost sales, refunds and compensation, wrong prices or fees, and incident work that replaces planned work.
  • Reputation: users who meet failures leave and tell others; trust is hardest to regain for payments, health and personal data.
  • Safety: when software controls medical devices, vehicles or machines, a failure can hurt people, so these domains test more formally and deeply.
  • Legal and regulatory compliance: contracts can set penalties for outages, and laws such as Saudi Arabia's Personal Data Protection Law set obligations for personal data. Testing may itself be required by a contract, a law or a regulatory standard.

Testing reduces risk and informs decisions

A risk is an event that may happen and would cause harm; ISTQB characterises it by its likelihood and its impact. Testing lowers the level of risk in two ways: it finds defects that developers then fix, and when tests of a risky area pass, the team has evidence, not only hope, that the area works under the conditions tested.

Testing also produces information, and giving stakeholders what they need for informed decisions is an ISTQB test objective. A product owner deciding whether to release on Thursday needs a picture like the one below. The decision is theirs; the tester makes the picture accurate and honest about its limits.

  • Tested: checkout, card payment and refunds; 48 tests, 46 passed, 1 failed, 1 not run.
  • Open: one major defect; the refund e-mail shows a wrong amount, although the refund itself is correct.
  • Not tested: wallet payments on iOS, because no test device was available.
  • Options: release with a note to support and fix the e-mail in 4.2.1, or delay by one day.

Try it: Risk-Based Test Generator

What testing can show, and what it cannot

The first of the seven testing principles in the ISTQB syllabus is that testing shows the presence, not the absence, of defects. A failed test, once you have checked that the test and its environment are right, shows that a defect exists; a passed test shows only that this test, with this data and environment, revealed none. Testing makes undiscovered defects less likely but cannot prove software correct, and exhaustive testing is impossible: even a small form with a few text fields has more input combinations than anyone could run.

Testing contributes to quality without creating it alone: the defects it finds are removed by debugging and fixing. And, as the lesson on verification and validation showed, software can pass every test against its specification and still miss users' needs; ISTQB calls this the absence-of-defects fallacy.

"All tests passed" therefore means that the planned tests found no failure, not that no defects remain or that untested areas work. A good report names what was not tested and the risk that remains, called residual risk.

Worked example: one defect, found at three moments

A defect found late costs more because more work has been built on it: a requirement defect turns into design, code, tests and data that all follow it. ISTQB states this as a principle: early testing saves time and money. How much more varies between projects, so explain it with concrete consequences rather than a fixed multiplier.

Requirement: "Customers can cancel an order within 24 hours for a full refund." It does not say when the 24 hours start or whether "full" includes the delivery fee, and the developer assumes they start when the order is placed. Tests written from that assumption would all pass. Follow the defect to three moments:

  • Found in a requirements review: the tester asks "24 hours from when, and is the delivery fee refunded?" The product owner answers (from payment confirmation; the fee only if the order has not been dispatched) and the sentence is rewritten. Cost: a conversation and an edit, because nothing has been built on the defect yet.
  • Found in system testing, where testers check the whole, integrated application in a test environment: a test of an order paid by bank transfer and confirmed the next day shows that it cannot be cancelled, even straight after confirmation. Cost: a defect report, a code change, a confirmation test, regression tests and perhaps a later release.
  • Found in production: customers who paid by transfer cannot cancel and complain, while others receive fee refunds the business never intended. Cost: all of the above plus an incident, a hotfix, manual refunds, corrected order data and lost trust.
One unclear 24-hour cancellation rule found at three moments: in review it costs a conversation and an edit, in system testing rework and retesting, in production also an incident, refunds and lost trust. Conceptual model

Found in a requirements reviewearliest

  1. 1Tester asks: 24 hours from when? Is the delivery fee refunded?
  2. 2Product owner answers; the sentence is rewritten
Built on the defect:
Nothing yet
Who notices:
The tester, by questioning the requirement
Cost to put it right:
A conversation and an edit

Found in system testing

  1. 1Test: order paid by bank transfer, confirmed the next day
  2. 2Cancellation is refused, even straight after confirmationFail
  3. 3Defect report, code change, confirmation and regression tests
Built on the defect:
Design, code and tests
Who notices:
The tester, through a failed test
Cost to put it right:
Rework, retesting and perhaps a later release

Found in productionlatest

  1. 1Customers who paid by transfer cannot cancel; others get fee refunds nobody intended
  2. 2Complaints reach support
  3. 3Incident, hotfix, manual refunds, corrected order data
Built on the defect:
Design, code, tests and live orders
Who notices:
Customers and support
Cost to put it right:
All of that plus an incident, manual refunds, data correction and lost trust

The cost grows with the work built on the defect; how much it grows differs between projects, so no fixed multiplier is shown.

Try it: Acceptance Criteria Generator Try it: AI Requirement Ambiguity Detector

Common mistakes

  • Promising, or letting others assume, that tested software has no defects.
  • Testing every feature to the same depth instead of testing most where a failure would cost most.
  • Reporting only counts such as "120 tests passed", without what was not tested and what is still open.
  • Waiting for a finished build and skipping requirement reviews, where defects are cheapest to remove.
  • Quoting a fixed multiplier for the cost of late defects as a fact instead of your product's concrete consequences.
  • Acting as the gatekeeper of a release: testers inform the decision; the stakeholders who own the risk make it.

The QA perspective

On a real team, ask of every new feature, during refinement: "what would happen if this failed in production, and to whom?" Ask the product owner, the developers and, where relevant, support, security or compliance colleagues. The answers show where to test deeply, where a quick check is enough and which questions to raise while they are still cheap.

Record what you tested, what you found, what you could not test and the risk that remains. When asked "is it ready?", answer with that information rather than a bare yes or no. After a production incident, ask at which earlier moment the defect could have been found, and add that check next time.

Practice exercise

Decide where testing matters most in a release

Your task

A shopping app's next release contains the four changes below, and you have time to test only two of them in depth. Choose the two, justify the choice by what a failure would cost, and write a short note to the product owner.

Material
Release 3.8 — changes

1. The "Contact us" button on the help page gets a new colour.
2. New: customers can save a card for future payments.
3. Changed: VAT is rounded on each invoice line instead of on the total.
4. New: each store page shows its opening hours.
Steps
  1. For each change, write one realistic way it could fail in production.
  2. Name who would be affected and the kind of cost: money, reputation, safety, or legal and regulatory.
  3. Rank the changes by how much testing they deserve.
  4. Write a note of three or four lines: what gets deep testing, what gets a quick check and what risk remains.
Show the model answer
Model answer

Saved cards, highest risk: a card could be charged without consent, shown to another account or kept after removal. It affects every customer who saves a card and costs money, trust and legal exposure, because personal data is protected by law and card data by strict payment-industry rules. Test declined cards, removal and two accounts on one device.

VAT rounding, high risk: on many orders the totals could differ by a halala from the correct amount or from the accounting records. It affects customers and the finance team and costs money and legal exposure, because tax invoices are regulated. Test one-line and many-line invoices and amounts where rounding changes the result.

Opening hours, lower risk: wrong hours or a wrong time zone send customers to a closed store, which costs them time and the shop some reputation. Button colour, lowest risk: the main danger is contrast too low for users with low vision to read, which a quick check covers.

Note: "Saved cards and VAT rounding get deep testing; opening hours and the button get a quick check. Remaining risk: opening hours are checked in one time zone only, and passing tests reduce, but do not remove, the chance of defects in saved cards."

Frequently asked questions

If testing cannot prove there are no defects, why do it?

Because it reduces risk and replaces guesses with evidence. Every failure found before release is one the team can fix, or at least decide about, before users meet it, and every area tested tells the team how much risk is left. Without testing, a team releases knowing neither.

Does a bug found in production really cost 100 times more to fix?

There is no single number. Multipliers like that are widely quoted, but the real difference depends on the project, the defect and how the team works. What holds, and what the ISTQB syllabus states as a principle, is the direction: the later a defect is found, the more work has been built on it and the more it costs. Explain it with your own product's consequences.

Who decides whether software is ready to release?

The stakeholders who own the risk: usually the product owner or a business owner, sometimes a release board, and in regulated domains whoever the rules name. Testers provide the information for that decision (results, open defects, untested areas and remaining risk) and a recommendation when asked.

Does more testing always mean better quality?

No. Testing finds defects and evaluates quality; quality improves only when defects are fixed and their causes addressed. Extra tests in low-risk areas add little, while the same time spent on a high-risk area or an early review can prevent serious failures.

References

Tools

Practise with Mutqan tools

Risk-Based Test Generator

Score features by likelihood and impact, then generate a prioritised risk-based test plan.

Test Design

AI Requirement Ambiguity Detector

Detect ambiguous, vague or contradictory statements in requirements and get clarifying questions from Mutqan AI.

Requirement Analysis AI

Go deeper

Your progress on this topic

Part of the QA Roadmap