ISTQB Foundation key terms

The process of evaluating a work product by running it or examining it to find defects, gain information about its quality, and give stakeholders evidence on which to base decisions.

The activity developers perform after a test reveals a problem: locating the place in the code that causes it, fixing it, and checking that the fix works.

A human mistake or wrong decision, such as a mistyped value or a misunderstood requirement, that puts incorrect information into a work product and may later lead to a defect.

A flaw or imperfection in a work product such as code, a design document or a requirements specification, which can cause the product to fail to do what it should.

The visible event in which a running system produces a wrong result, crashes or behaves in a way that does not match its specification or the user's reasonable expectation.

The underlying reason, often a process or organisational weakness, why a defect was introduced and then not caught; removing it prevents similar defects from coming back.

Checking that a work product was built according to its specification and agreed standards, answering the question of whether the product was built right, often without executing it.

Checking that the product does what its users actually need in their real situation, answering whether the right product was built, and usually involving users or business representatives.

A group of testing activities organised around a stage of development, such as component, integration, system and acceptance testing, each with its own objectives, test basis and typical defects.

Re-running tests on a changed system to check that the change has not broken parts that used to work, often using a growing set of automated tests repeated at every build.

Retesting the specific defect that was reported, using the steps that exposed it, to confirm that the fix really works before the incident is closed.

Doing testing-related activities such as reviews and early test design as early as possible in the lifecycle, because defects found early are cheaper and easier to remove.

A development approach in which a developer first writes a failing automated unit test, then writes just enough code to pass it, and finally cleans up the code before moving on.

A team approach that writes tests as readable examples of desired behaviour in business language, so developers, testers and business people agree on what the system should do before coding starts.

Testing a live system when it is changed, migrated or about to be retired, including checking the change itself and running regression tests on the parts that might be affected.

Examining work products such as requirements, designs and code without executing them, by performing reviews or automated static analysis, in order to find defects early in the lifecycle.

A structured review that follows defined roles, entry and exit criteria and a documented process, of which the most rigorous type is an inspection.

An informal review in which the author leads colleagues through a work product to gather feedback, often used to explain a document and find problems quickly.

A review by technically qualified peers who examine a work product against its specification and technical standards, aiming to reach a decision or consensus on technical questions.

The most formal review type: reviewers follow defined rules, check the product against criteria and collect metrics, typically led by a trained moderator who plans the review and follows up.

Using tools to examine source code or models for suspicious patterns such as unused variables, unreachable code, security weaknesses or breaches of coding standards, without running the program.

Deriving and choosing tests from the internal structure of the code or design, such as statements, branches and paths, rather than from the stated requirements.

Dividing the possible inputs or outputs into groups that the system should treat the same way, then testing one value from each group to reduce the number of cases.

Testing values at the edges of each equivalence partition, such as the minimum, minimum plus one, maximum and maximum minus one, where developers most often make mistakes.

A technique for combinations of conditions in which the table lists conditions, actions and rules, and each rule becomes at least one test case, revealing gaps other techniques miss.

Modelling a system as states, events and transitions, then designing tests that cover valid transitions, invalid transitions and sequences of events that change the state.

A white-box measure and technique: the percentage of executable statements exercised by a set of tests, achieved by designing tests so that every statement runs at least once.

A white-box measure and technique: the percentage of decision outcomes, such as each branch of an if statement, exercised by tests, which is stronger than statement coverage.

An experience-based approach in which the tester designs, runs and evaluates tests at the same time, learning about the product as they go and following up on what they discover.

A document that describes the objectives, scope, approach, resources, schedule and risks of the testing effort, and which is updated as the project progresses.

Choosing how much and what to test based on the likelihood and impact of potential problems, so that limited effort goes to the areas that matter most to the business.

The chance that the delivered system has a quality problem, such as poor reliability, slow response or a missing feature, which testing tries to reduce by finding related defects.

Conditions that must be met before a test activity can reasonably start, such as approved requirements, available test data and a working test environment.

Conditions agreed in advance for declaring a test activity finished, such as reaching a coverage target or having no open critical defects.

The degree of impact a defect has on the system's operation or on stakeholders, rated by the tester, independently of how quickly anyone wants it fixed.

Using software tools to run tests, compare actual with expected results and report outcomes, so that repetitive checks can be executed quickly and consistently.

A tool that runs test scripts or test cases against the system under test, records the results and compares them with the expected values.

A tool that generates simulated load, such as many virtual users, against a system and measures response times and resource use to support performance and load testing.

A practice supported by tools in which developers merge their changes frequently and every merge triggers an automated build and test run, so integration problems surface quickly.

An automation approach in which test steps are written as business keywords in a spreadsheet and a tool translates them into scripts, letting non-programmers create tests.