Software Testing is the systematic evaluation of software through planned activities intended to discover defects, provide evidence about behaviour and assess whether a system satisfies specified requirements or other relevant expectations. Testing can involve executing software with selected inputs and observing outputs, but the broader testing discipline also encompasses planning, test design, environment preparation, result analysis, defect reporting, maintenance and risk assessment. A test can examine functional behaviour, performance, security, compatibility, usability, reliability or other properties depending on its purpose.
Testing does not mathematically prove that software contains no defects; it provides evidence about behaviour under the conditions that have actually been examined. This distinction is fundamental because software normally has an enormous or effectively unbounded input space, making exhaustive testing impractical for most non-trivial systems. Effective Software Testing therefore involves selecting tests that provide useful information about important risks, requirements and failure modes rather than simply executing as many cases as possible.
The history of Software Testing developed alongside the increasing complexity of software systems and changing approaches to software engineering. Early programming work often relied heavily on debugging and informal execution, while later methodologies introduced more explicit testing stages and quality-assurance processes. The growth of structured programming, formal requirements, object-oriented development, automated build systems and iterative methodologies encouraged testing to occur throughout development rather than solely immediately before release.
Agile and DevOps practices further emphasised rapid automated feedback, while Continuous Integration and Continuous Deployment made reliable automated testing increasingly important because software changes can move rapidly through delivery pipelines. Modern testing includes static techniques that inspect artefacts without executing them and dynamic techniques that execute software under controlled conditions. Property-based testing, mutation testing, fuzzing, model-based testing and automated security testing have expanded the range of methods available beyond traditional manually authored example-based test cases.
Software Testing can be organised along several dimensions, including test level, test type, execution method and testing objective. Unit Testing examines relatively small software components, Integration Testing examines interactions between components or systems, System Testing evaluates the assembled system, Acceptance Testing examines whether software meets acceptance expectations, and Regression Testing examines whether existing behaviour remains correct following changes. These categories describe different purposes and scopes and are not necessarily mutually exclusive in implementation.
Testing can also be functional or non-functional, manual or automated, scripted or exploratory, deterministic or probabilistic. Static analysis and code review can identify defects without executing the software, while dynamic tests require execution. Black-box testing focuses primarily on observable behaviour without requiring knowledge of internal implementation, whereas white-box approaches use information about internal structure. Grey-box testing occupies an intermediate position in which testers have some knowledge of implementation or architecture.
Test design is a central technical discipline because the usefulness of testing depends strongly on which cases are selected. Equivalence partitioning divides inputs into classes expected to behave similarly, reducing redundant tests while retaining representative coverage. Boundary-value analysis focuses on values at or near important limits because defects frequently occur at boundaries. Decision-table testing can systematically examine combinations of conditions and resulting actions, while state-transition testing examines behaviour as a system moves between defined states.
Pairwise and other combinatorial techniques can reduce the number of combinations tested when many parameters interact. Negative testing deliberately supplies invalid, unexpected or hostile inputs to determine whether the software handles them appropriately. Risk-based testing prioritises tests according to the consequences and likelihood of potential failures. These techniques are complementary and can be combined with domain knowledge, requirements analysis, production incident history and architectural understanding to create more informative test suites.
Test environments and test data substantially affect the validity of results. A test that passes in an isolated development environment may fail in production because of different operating-system versions, databases, network conditions, configuration, concurrency, external services or data volumes. Tests therefore need controlled dependencies where isolation is required and realistic dependencies where integration behaviour itself is being evaluated.
Test doubles such as mocks, stubs and fakes can replace external components, but excessive use can cause tests to validate assumptions about simulated behaviour rather than actual integration behaviour. Test data must also avoid inappropriate exposure of personal or confidential information and should represent important production characteristics where necessary. Deterministic tests are generally easier to diagnose, while tests involving timing, concurrency, randomness or external systems may produce intermittent results. Reproducibility is consequently an important property of a well-engineered testing process.
Software Testing has limitations that must be understood when interpreting test results. A passing test demonstrates that the tested conditions produced the expected result; it does not demonstrate that all untested conditions are correct. High code coverage can reveal portions of a codebase that are not executed by tests, but coverage percentage alone does not measure the quality of assertions or whether important behaviours have been tested.
Mutation testing can provide additional evidence by deliberately introducing small changes and determining whether the test suite detects them. Flaky tests are especially problematic because their results are not reliably associated with software changes, reducing trust in automation. False positives can cause unnecessary investigation, while false negatives allow defects to escape detection. Testing is therefore one component of quality engineering alongside good requirements, architecture, implementation, review, monitoring, security controls and operational practices.
Automated Software Testing is particularly valuable when feedback needs to be frequent, repeatable and inexpensive enough to execute regularly. Automated tests can run after commits, before merges, during builds and after deployments. Fast tests are useful early in a pipeline because they provide rapid feedback, while slower environment-dependent tests may be executed later. Parallel execution can reduce elapsed time but may introduce resource contention or nondeterministic behaviour if tests share mutable state.
Test suites also require maintenance because software requirements, interfaces and architecture change. A neglected suite can become slow, brittle or misleading. Manual testing remains useful for exploratory investigation, unusual workflows, visual assessment and situations where human judgement is central, but manual execution of repetitive deterministic checks is generally less scalable than reliable automation. Effective organisations therefore combine different testing techniques according to risk rather than treating automation and manual testing as mutually exclusive alternatives.
Software Testing has direct practical significance because defects can produce financial loss, security incidents, service outages, incorrect decisions, regulatory consequences and damage to user trust. Testing priorities should therefore reflect the consequences of failure rather than simply the number of lines of code involved. Safety-critical and security-sensitive systems may require specialised standards, formal analysis, independent assessment or evidence beyond ordinary functional tests.
A useful testing process maintains traceability between important requirements, risks, test cases and observed results where such traceability is necessary. Defects discovered through production incidents can feed back into test design so that equivalent failures become less likely to recur. Testing thus forms a feedback mechanism throughout the software lifecycle: requirements determine expected behaviour, implementation creates a concrete system, tests compare observed behaviour with expectations, failures provide information about defects or assumptions, and corrected software is tested again.
