BCS-O key terms

The process of evaluating a software product to detect differences between expected and actual results, and to assess the quality of the product.

Confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. It answers the question: Are we building the product right?

Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled. It answers: Are we building the right product?

A human action that produces an incorrect result. Errors can occur in any phase of software development and may lead to defects in the software.

A flaw in a component or system that can cause the component or system to fail to perform its required function. Also known as a bug.

Deviation of the component or system from its expected delivery, service, or result. A failure occurs when a defect is executed under specific conditions.

A set of preconditions, inputs, actions (where applicable), expected results, and postconditions, developed based on test conditions. It is used to verify a specific aspect of the software.

A testable aspect of a component or system identified as a basis for testing. It is a high-level idea of what to test, such as a functional requirement or a quality attribute.

A sequence of test cases in execution order, with any associated actions required to set up the initial preconditions and any wrap-up activities. It specifies how to run tests.

A commonly used term for a test procedure, especially when the tests are automated. It is a detailed set of instructions for executing a test.

A set of test cases or test procedures grouped together for execution. It is often organized by functionality, risk, or test level.

Documentation describing the test objectives to be achieved and the means and schedule for achieving them. It typically includes scope, approach, resources, and schedule.

A high-level description of the test levels to be performed and the testing within those levels for an organization or program. It provides a general framework for testing.

The implementation of the test strategy for a specific project. It includes decisions on test techniques, test levels, and entry/exit criteria.

A group of test activities that are organized and managed together. Examples include unit testing, integration testing, system testing, and acceptance testing.

Testing of individual software components or units in isolation. It focuses on verifying the smallest testable parts of the software.

Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. It verifies that components work together.

Testing the behavior of a complete system or product to verify that it meets specified requirements. It is often performed in an environment similar to production.

Formal testing with respect to user needs, requirements, and business processes conducted to determine whether a system satisfies the acceptance criteria and to enable the user to accept the system.

Testing that does not involve the execution of the software code. It includes reviews, walkthroughs, inspections, and static analysis of code or documents.

Testing that involves the execution of the software code. It includes techniques such as black-box and white-box testing to evaluate the behavior of the software.

Testing based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure. It focuses on inputs and outputs.

Testing based on an analysis of the internal structure or code of a component or system. It includes techniques such as statement coverage and branch coverage.

The degree, expressed as a percentage, to which specified test coverage items have been exercised by a test suite. It is a measure of testing thoroughness.

The percentage of executable statements in the code that have been exercised by a test suite. It is a white-box test coverage metric.

The percentage of branches (decision points) in the code that have been exercised by a test suite. It is a stronger metric than statement coverage.

The percentage of decision outcomes (true and false) that have been exercised by a test suite. It is also known as branch coverage.

A black-box test technique in which test conditions are divided into groups (partitions) that are expected to be handled the same way. One test case per partition is designed.

A black-box test technique in which test cases are designed to include values at the boundaries of equivalence partitions. It is based on the higher probability of defects at boundaries.

A black-box test technique in which test cases are designed to exercise combinations of conditions and associated actions. It is useful for complex business rules.

A black-box test technique in which test cases are designed to exercise states and transitions of a system. It is used for systems with a finite number of states.

A black-box test technique in which test cases are designed to exercise interactions between components based on their use cases. It focuses on end-to-end scenarios.

An approach to testing in which test design and execution are performed simultaneously. Testers actively learn about the system while designing and running tests.

Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas. It verifies that changes did not break existing functionality.

Testing that runs test cases that failed the last time they were run, to verify that the defects have been fixed. Also known as re-testing.

The set of conditions for officially starting a defined task, such as a test level or a test phase. It ensures that prerequisites are met before testing begins.

The set of conditions for officially completing a defined task, such as a test level or a test phase. It is used to determine when testing is sufficient.

A source to determine expected results to compare with the actual result of the software under test. It can be a specification, a user expectation, or another version of the software.

The observable behavior of the software that is predicted by the test case based on the specification or other oracle. It is compared with the actual result to determine pass/fail.

The process of recognizing, recording, classifying, investigating, fixing, and disposing of defects. It includes tracking defects from discovery to closure.

A document reporting any event that occurred during testing which requires investigation. It typically includes details such as steps to reproduce, expected and actual results.