Software Testing

Software testing is the dynamic execution of a program with selected inputs to detect defects and gain confidence that the software behaves as intended.

Definition

Software testing is the activity of designing and executing test cases — inputs paired with expected outcomes — to reveal discrepancies between actual and required behavior and to estimate software reliability.

Scope

This topic covers testing levels (unit, integration, system, acceptance); black-box techniques such as equivalence partitioning, boundary-value analysis, and combinatorial testing; white-box techniques driven by code coverage criteria; regression, performance, and exploratory testing; test automation; and the theory of test adequacy and coverage.

Core questions

• How are effective test cases selected from an intractably large input space?
• What coverage criteria measure the adequacy of a test suite?
• How do the levels of testing from unit to acceptance complement one another?
• How can testing be automated and integrated into the delivery pipeline?

Key theories

Black-box and white-box test design

Black-box techniques derive tests from the specification through partitioning and boundary analysis, while white-box techniques derive tests from code structure guided by coverage criteria; the two are complementary.

Coverage and test adequacy criteria

Adequacy criteria such as statement, branch, and condition coverage, and model-based criteria over control- and data-flow graphs, give measurable goals for how thoroughly a test suite exercises a program.

Clinical relevance

Testing is the most widely practiced means of assuring software behaves correctly before release; well-designed automated tests catch regressions early, support refactoring and continuous delivery, and are central to dependable software.

Evidence & guidelines

ISO/IEC/IEEE 29119 provides international standards for software testing processes, documentation, and techniques, and the SWEBOK Software Testing knowledge area gives a consensus overview.

History

Testing matured from ad hoc debugging into a discipline with Myers's systematic treatment in 1979; coverage theory, model-based testing, and test automation developed through the following decades, and test-driven development and continuous integration made automated testing a core agile practice.

Debates

How much automated testing is worthwhile

The right balance among unit, integration, and end-to-end automated tests is debated; the test pyramid favors many fast unit tests over slow end-to-end ones, but critics note that this balance depends on system type and risk.

Key figures

• Glenford Myers
• Paul Ammann
• Jeff Offutt
• Boris Beizer

Seminal works

• myers2011
• ammann2016
• swebok2014

Frequently asked questions

Why can't we test every possible input?

The space of possible inputs and execution paths is astronomically large or infinite for most programs, so exhaustive testing is infeasible; testing instead selects representative and boundary cases using systematic techniques to maximize defect detection per test.

What is the difference between testing levels?

Unit testing exercises individual components in isolation, integration testing checks their interactions, system testing evaluates the whole system against its requirements, and acceptance testing confirms it meets user needs; each level targets different kinds of defects.