What Is Software Testing?

Why it matters

How a team defines testing decides when it starts and what it delivers. If testing means only executing the software, it starts when a build is ready and misses the defects that are cheapest to remove, those in requirements, designs and code. If testing and debugging are blurred, fixes get closed without anyone checking that they work.

For you as a tester, the definition draws the edges of the job. The test objectives tell you why a test exists and what your report must answer. The line between testing and debugging tells you where your work hands over to a developer, and which tests you owe the team when the fix comes back.

Test objectives: why a test exists

A test objective is the reason for testing. The ISTQB Foundation syllabus (CTFL v4.0) lists the typical objectives below. Which ones matter depends on the context: the work product, the test level (such as testing single components or the whole system), the risks, the development lifecycle and business factors such as time to market. For example, in component (unit) testing, where developers test one part of the code on its own, triggering failures and finding defects early usually comes first; in acceptance testing, building confidence and informing the release decision.

• Evaluating work products such as requirements, user stories, designs and code.
• Triggering failures and finding defects.
• Ensuring the required coverage of a test object, for example at least one test for every acceptance criterion.
• Reducing the level of risk of inadequate software quality.
• Verifying whether specified requirements have been fulfilled.
• Verifying that the test object complies with contractual, legal and regulatory requirements.
• Providing information to stakeholders so that they can make informed decisions.
• Building confidence in the quality of the test object.
• Validating whether the test object is complete and works as stakeholders expect.

Try it: Requirements → Test Cases

Static and dynamic testing

You met both forms in the lesson on verification and validation. Dynamic testing executes the software. Static testing examines a work product without executing it, through reviews, where people read and discuss it, or static analysis, where tools check it against rules. ISTQB counts both as testing.

What differs is what each one finds. Dynamic testing triggers failures, which must then be traced back to their defects. Static testing finds the defect itself, often with its exact location, and can examine work products that never run, such as requirements and test plans. Neither replaces the other: a review cannot measure how fast a page loads, and an ambiguous requirement is far easier to spot by reading it than by running tests.

• Review: reading the story "Approved expenses appear in the monthly report" and asking "approved by whom, and which date decides the month: submission or approval?" before any code exists.
• Static analysis: a tool flags an SQL statement with an unbalanced parenthesis before anyone runs it.
• Dynamic test: running the monthly report with known data and comparing its total with the expected one.

Try it: SQL Query Validator Try it: JSON Validator

Testing is not debugging

Testing and debugging are separate activities. Testing shows that something is wrong; debugging finds the cause and removes it. When a dynamic test fails, debugging usually takes three steps: reproduce the failure, diagnose its cause and fix it. When static testing finds a defect, there is nothing to reproduce or diagnose, because the defect is already in view, so debugging is just the fix.

After the fix, testing takes over again. Confirmation testing, also called re-testing, checks that the fix solved the original problem, usually by running the failed test again with the same data; the syllabus prefers that the person who ran the original test does it. Regression testing then checks that the change has not caused failures elsewhere.

Worked example: a wrong total in an expense report

Requirement: "The monthly report shows the total of all expenses approved in that month." Huda, a tester, runs test case TC-REP-014 on build 2.7 with three expenses approved in September 2026. The expected total is 235.75 SAR; the report shows 195.75. That difference is a failure.

Huda reports it with the build, the data and both totals; she does not need to know which line of code is wrong. Omar, the developer, does the debugging: he reproduces the failure, finds a date filter that ends at the start of 30 September and so leaves out the last day of the month, and fixes it.

• Confirmation test: TC-REP-014 on build 2.8 with the same data gives 235.75, so the defect can be closed.
• Regression tests: the quarterly report and the CSV export, which use the same filter, and a 31-day month all give correct totals.
• The static route: a reviewer reading the query before it ever ran could have spotted the end date directly, with no reproduction and no diagnosis.

TC-REP-014  Monthly report total equals the sum of approved expenses
Build 2.7   Expenses approved in September 2026:
            12 Sep  120.50  |  21 Sep  75.25  |  30 Sep 16:40  40.00
Expected    Total 235.75
Actual      Total 195.75                                     FAILED

Debugging (Omar, developer)
  Reproduce   Same data on build 2.7: total 195.75
  Diagnose    Filter: approved_at < '2026-09-30'  (30 Sep is left out)
  Fix         Filter: approved_at < '2026-10-01'  -> build 2.8

Confirmation  TC-REP-014 on build 2.8, same data: total 235.75    PASSED
Regression    Quarterly report, CSV export, 31-day month           PASSED

Try it: Regression Scenario Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022The international software-testing standard: concepts, processes, documentation and techniques.