NCT Tester Competence Assessment key terms

A human action that produces an incorrect result, such as a mistake in reasoning, typing, or interpretation while building or testing software. Errors are the root cause from which defects originate.

A flaw or imperfection in a work product, such as a requirement, design, or code, that can cause the product to fail to meet its intended purpose. Also called a bug.

The observable incorrect behavior of a component or system during execution, produced when a defect is reached under particular conditions. A failure is a symptom rather than the underlying cause.

The fundamental underlying reason a defect was introduced, such as a missing review step or an unclear requirement. Identifying it lets teams fix the process rather than only the symptom.

The activity of checking that a work product meets its specified requirements and was built correctly according to its design. It answers whether the product was built right.

The activity of checking that a work product fulfills its intended use and stakeholder needs in its operational context. It answers whether the right product was built.

A source of information, such as a specification, reference implementation, or expected result, used to decide whether an observed test outcome is correct or incorrect.

A set of preconditions, inputs, actions, expected results, and postconditions developed to verify a particular requirement or behavior. It is the basic reusable unit of test design.

The observable outcome or behavior a test case predicts when the system is exercised with defined inputs and preconditions. It is compared against the actual result to determine pass or fail.

The behavior or output observed when a test is executed, recorded exactly as it occurred. Comparing it with the expected result determines whether the test passes or reveals a defect.

A group of test activities organized and managed together at a particular stage of development, such as component, integration, system, or acceptance testing. Each level has distinct objectives and entry criteria.

Testing individual units or modules of software in isolation from the rest of the system, often using stubs and drivers. It focuses on internal logic and is frequently performed by developers.

Testing performed to expose defects in the interfaces and interactions between combined components or systems. It verifies that separately developed parts work together as intended.

Testing conducted to determine whether a system satisfies agreed business or user needs and is ready for deployment. It is often the final level before release and may be user-driven.

Testing performed after changes to verify that previously working functionality still behaves correctly and that new defects were not introduced. It typically reuses an existing test suite.

Re-testing a specific defect after a fix to verify that the reported problem is genuinely resolved. It targets the changed area rather than broad surrounding functionality.

Testing that examines work products such as requirements, designs, and code without executing them. It includes reviews and static analysis and can find defects early and cheaply.

Testing that involves executing the software with selected inputs and observing its behavior. It contrasts with static testing, which examines artifacts without running them.

A systematic examination of a work product by one or more people to find defects, ambiguities, and improvement opportunities. Reviews range from informal to highly formal processes.

The most formal review type, following a defined process with roles, entry and exit criteria, and documented findings. It is typically led by a trained moderator and uses checklists or rules.

A review in which the author leads participants through a work product to gather feedback and build shared understanding. It is less formal than an inspection and often serves a learning purpose.

The person who plans and leads a formal review, ensuring the process is followed, keeping discussion focused, and mediating disagreements. The role is central to effective inspections.

Automated examination of source code or models for structural problems such as unreachable code, inconsistent declarations, or violations of coding rules, without executing the software.

A black-box technique that divides input or output data into classes expected to be processed the same way, then selects one representative value from each class to reduce redundant tests.

A black-box technique that selects test values at the edges of equivalence partitions, where defects are statistically most likely. It tests minimum, maximum, and just-outside values.

A black-box technique that models combinations of conditions and the actions they trigger in a table, ensuring each relevant rule combination is exercised by at least one test.

A black-box technique that models a system as states, events, and transitions, then designs tests to cover valid and invalid transitions. It suits systems with distinct behavioral states.

A test approach based on specifications and observable behavior rather than internal code structure. Testers derive cases from requirements and interfaces without seeing the implementation.

A test approach that derives test cases from the internal structure of the code, such as statements, branches, and paths. It measures how thoroughly the implementation is exercised.

A white-box coverage measure equal to the percentage of executable statements exercised by a test suite. It is the weakest common structural coverage criterion.

A white-box coverage measure requiring each possible outcome of every decision point to be exercised at least once. It is stronger than statement coverage and subsumes it.

A document describing the scope, objectives, approach, resources, schedule, risks, and deliverables of testing for a project or release. It guides and constrains test activities.

The conditions that must be satisfied before a test activity or level can officially begin, such as approved requirements or a stable build. They reduce the risk of wasted effort.

The conditions agreed for declaring a test activity or level complete, such as coverage thresholds, defect closure rates, or passed smoke tests. They support release decisions.

The process of predicting the effort, duration, and resources needed for test activities, using techniques such as expert judgment, analogy, or metrics from past projects.

The ongoing comparison of actual test progress and results against the plan, using metrics such as test execution rates, defect trends, and coverage. It feeds status reporting and control.

The sequence of states a defect passes through from reporting to closure, such as new, assigned, fixed, retested, and closed. It provides traceability and accountability for fixes.

A classification of how seriously a defect impacts the system's operation or business, independent of how quickly it must be fixed. It is usually assigned by the tester.

A classification of how urgently a defect should be fixed relative to others, typically set by the business or product owner. It reflects scheduling rather than technical impact.

An approach that allocates test effort in proportion to the likelihood and impact of potential failures, focusing deepest testing on the highest-risk areas of the product.

The use of software tools to execute tests, compare actual and expected results, and report outcomes with minimal manual intervention. It suits stable, repeatable, high-volume checks.

A collection of tools, stubs, drivers, and scripts that supports automated test execution and result comparison. It provides the infrastructure a test suite needs to run.

A simplified replacement for a component that a module under test calls, returning controlled responses. Stubs support isolated component and integration testing where real parts are unavailable.

The hardware, software, network, data, and configuration in which tests are executed. It must be representative of the target environment and controlled to keep results reliable.

The inputs and supporting records prepared for test execution, including valid, invalid, and boundary values. It must be realistic, controlled, and handled with privacy in mind.

A high-level description of the general approach to testing across an organization or program, including levels, types, and standards. It is more general than a project test plan.

The degree to which a test suite exercises specified elements of a system or work product, such as requirements, statements, or branches. It is expressed as a percentage of the defined total.

A set of related test cases grouped for execution, often by feature, level, or risk. Suites are typically maintained together and run repeatedly, especially for regression.

The activity of running test cases against the system under test, recording actual results, and comparing them with expected results to determine pass or fail status.