Definitions and pro-tips for the CTFL-v4.0 certification.
2-Value Boundary Value Analysis is an approach where two values are tested for each boundary: the boundary value itself and the closest value immediately adjacent to the boundary in the neighboring partition.
The Absence-of-Errors Fallacy is the incorrect belief that finding and fixing a large number of defects will ensure the success of a system. Even if software is 100% defect-free, it may still fail if it does not meet the users' needs and expectations.
Acceptance Testing is formal testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer or user to decide whether to accept the system. It focuses on validating that the software meets business needs and is ready for deployment.
An Action is the expected output or behavior triggered by a specific combination of conditions in a decision table. Actions are listed in the bottom half of the table and dictate what the system must do when a rule is met.
Agile Software Development is a group of iterative and incremental methodologies focused on flexibility, continuous improvement, and rapid delivery of working software. It relies on cross-functional teams, close collaboration with stakeholders, and adaptability to changing requirements.
Any condition that deviates from expectation based on requirements specifications, design documents, user documents, standards, or from someone's perception or experience.
Black-Box Testing is a testing technique based on an analysis of the specification of a component or system. It focuses on the inputs and outputs without reference to the internal code or structure.
A Boundary Value is a minimum or maximum value of an ordered equivalence partition. These edge cases are where behaviors are most likely to change, making them prime targets for off-by-one errors and defects.
Boundary Value Analysis (BVA) is a black-box test technique where test cases are designed based on the boundary values of equivalence partitions. It focuses on the edges of partitions where defects are most likely to hide.
The percentage of branches of control flow (such as true and false outcomes of an IF statement) that have been exercised by a test suite. It is calculated by dividing the number of executed branches by the total number of branches.
A white-box test technique in which test cases are designed to exercise specific branches in the control flow of a component. The objective is to evaluate branch coverage.
A review technique where reviewers use a list of predefined questions or criteria to systematically guide their evaluation of a work product.
An experience-based test technique in which the experienced tester uses a high-level list of items to be noted, checked, or remembered, or a set of rules or criteria against which a product has to be verified.
Component Testing, also known as unit testing, focuses on individual software modules or components that are independently testable. It primarily aims to verify functional behavior, performance, and robustness at the lowest level.
A Condition in a decision table represents an input or a specific state of the software that affects its behavior. Conditions are typically listed in the top half of the table and evaluated as True or False.
Configuration Management ensures the integrity of the testware and software under test by controlling changes and maintaining versions. It allows testers to know exactly which version of the software is being tested with which version of test scripts.
Confirmation bias is the psychological tendency to search for, interpret, favor, and recall information in a way that confirms one's preexisting beliefs or hypotheses. In testing, developers may subconsciously test their code only to show it works, rather than trying to break it.
Confirmation Testing, or re-testing, is performed after a defect has been fixed to ensure the original issue is resolved. It executes the test cases that previously failed due to the defect.
Continuous Integration is a development practice where code changes are automatically built, integrated, and tested frequently. CI tools orchestrate these pipelines to provide immediate feedback on code quality and integration issues.
A visual representation of all paths that might be traversed through a program during its execution. Nodes represent statements or blocks of statements, and edges represent the control flow.
Data-Driven Testing is a scripting technique that stores test inputs and expected results in an external data source, such as a spreadsheet or database. A single test script iterates through this data to execute the same scenario with multiple values.
Debugging is the process of finding, analyzing, and removing the causes of failures in software. Unlike testing, which focuses on showing that failures exist, debugging is performed by developers to fix the underlying defects.
Decision Table Testing is a black-box test technique used to test systems with complex business rules. It involves creating a table that captures all possible combinations of conditions and their corresponding expected actions.
A defect is an imperfection or deficiency in a work product where it does not meet its requirements or specifications. If executed, a defect may cause a failure in the system.
An imperfection or deficiency in a work product where it does not meet its requirements or specifications. A defect, if executed, may cause a failure.
Defect clustering is the principle that a small number of modules usually contain most of the defects discovered during pre-release testing, or are responsible for the majority of operational failures. This is an application of the Pareto principle (80/20 rule) to software testing.
Defect Density is a metric calculated by dividing the total number of defects by the size of the software component or system. It is used to identify unreliable components and guide targeted testing.
Defect Management is the systematic process of recognizing, recording, classifying, investigating, and resolving defects. It ensures that identified issues are tracked from discovery to closure.
A Defect Management Tool tracks the lifecycle of anomalies or bugs from discovery to resolution. It facilitates workflow routing, status reporting, and communication between developers and testers.
A Defect Report is a formal document detailing a discovered flaw, designed to provide developers with enough information to reproduce and fix the issue. It includes steps to reproduce, expected results, and actual results.
Defect Triage is the process of reviewing, prioritizing, and assigning newly reported defects. A triage committee evaluates the severity and impact of defects to decide which ones should be fixed and when.
Dynamic Testing is the process of evaluating a component or system by executing its software code. It requires the software to be compiled and run to observe its behavior and compare it against expected results.
Entry Criteria are the set of conditions for officially starting a defined task. They ensure that testing does not begin before the necessary prerequisites, such as a stable test environment and available test data, are met.
Equivalence Partitioning (EP) is a black-box test technique that divides input data into classes expected to be treated similarly by the software. Test cases are designed to execute at least one representative value from each partition.
A human action that produces an incorrect result. Errors often occur due to time pressure, complex code, misunderstanding of requirements, or fatigue.
A test technique in which tests are derived on the basis of the tester's knowledge of past failures, or general knowledge of software failure modes. Testers anticipate errors, defects, and failures based on their experience.
An Event is an occurrence that causes a system to evaluate a transition and potentially change its state. Events are the inputs or triggers in state transition models.
Exhaustive testing is a testing approach in which all possible combinations of inputs and preconditions are tested. According to the principles of testing, exhaustive testing is impossible except for trivial cases.
Exit Criteria are the set of conditions for officially completing a defined task. In testing, they determine when to stop testing activities, such as when a certain level of coverage is achieved or all critical defects are resolved.
A test technique where the tester's knowledge, skills, and intuition play a central role in designing and executing tests. It often complements black-box and white-box techniques.
An approach to testing where the tester dynamically designs and executes tests based on their knowledge, exploration of the test item, and the results of previous tests. Test design, execution, and learning happen simultaneously.
An event in which a component or system does not perform its required function within specified limits. Failures are the visible manifestation of a defect during execution.
A Formal Review is a structured review process characterized by documented procedures, specific roles, and formal entry and exit criteria. Examples include inspections and technical reviews.
Functional Testing is a type of testing that evaluates the functions a system should perform. It focuses on 'what' the system does, verifying that its behavior aligns with specified functional requirements.
A Guard Condition is a boolean expression that must evaluate to true for a state transition to occur when an event happens. If the event occurs but the guard is false, the transition is blocked.
Impact Analysis is the process of evaluating changes to identify the parts of a system that could be unintentionally affected. It helps determine the appropriate scope of regression testing required after a modification.
An Incremental Development Model is a lifecycle approach where the software is built and delivered in distinct, usable pieces called increments. Each increment adds new functionality to the system, allowing for partial deployment of the product before it is entirely finished.
A widely used type of review that is not based on a formal procedure. It typically does not require a documented review process or formal roles.
The most formal type of review, characterized by documented procedures, strict roles, metrics collection, and a formal entry and exit criteria. It is led by a trained moderator.
Integration Testing evaluates the interactions and interfaces between integrated components or systems. It is divided into component integration testing and system integration testing.
An Invalid Equivalence Class is a partition containing values that should be rejected by the component or system. Testing these ensures the software handles errors gracefully and prevents malformed data processing.
An Invalid Transition is an attempted state change triggered by an event that is not allowed or not defined from the current state. Testing invalid transitions helps ensure the system handles unexpected inputs gracefully.
An Iterative Development Model is an approach where the software is developed in a series of repeated cycles or iterations. Each iteration involves a complete development loop, resulting in a refined and expanded version of the software until the final product is achieved.
Keyword-Driven Testing separates the test design from the execution by using action words (keywords) to represent test steps. Testers can write test cases using domain-specific keywords, which the underlying framework translates into executable code.
Maintenance Testing is performed on an existing operational system following modifications, migrations, or retirements. It evaluates both the changes made and the unchanged parts of the system to ensure continued reliability.
A Model-Based Testing Tool automatically generates test cases based on models that describe the expected behavior of the system under test. These tools translate state machines or business process models into executable test scenarios.
The person responsible for leading the review process, including planning, running the meetings, and ensuring follow-up actions are completed. Also known as the facilitator.
Non-functional Testing assesses the quality characteristics of a system, such as performance, usability, reliability, and security. It evaluates 'how well' the system behaves under specific conditions rather than what it does.
A review technique where reviewers evaluate the work product from the viewpoint of a specific stakeholder role, such as an end-user, system administrator, or tester.
The Pesticide Paradox is a testing principle stating that if the same tests are repeated over and over again, eventually they will no longer find any new defects. To detect new defects, test cases and test data must be regularly reviewed and updated.
The Probe Effect is an unintended change in a system's behavior caused by measuring or observing it. In testing, this often occurs when using performance monitoring tools or debuggers that alter the timing or resource usage of the application.
A Product Risk is a risk impacting the quality of a product, such as software failing to perform its intended functions. Examples include security vulnerabilities, poor performance, or incorrect calculations.
A Project Risk is a risk that impacts project success, such as delays, budget overruns, or resource shortages. These risks threaten the organization's capability to deliver the project on time and within budget.
A Proof of Concept in tool selection is a small-scale trial to verify that a proposed test tool functions effectively within the organization's specific infrastructure and meets its objectives. It helps identify potential integration or usage issues before committing to a full purchase.
Quality Assurance refers to activities focused on providing confidence that quality requirements will be fulfilled. It involves the proper execution of processes and standards, rather than the direct detection of defects.
A reactive process consisting of activities to evaluate a work product to determine if it meets quality requirements. Testing is a major part of Quality Control.
Regression Testing verifies that a recent code modification, such as a defect fix or new feature, has not adversely affected existing, unmodified functionality. It is typically automated due to the high volume of repeated tests.
A Reviewer is a participant in a review process who identifies and describes defects in the work product. They may have different backgrounds (testers, developers, business analysts) to provide diverse perspectives.
Risk Analysis is the process of assessing identified risks to estimate their level of risk, typically based on the likelihood of occurrence and the impact of the risk. It helps prioritize testing efforts towards the most critical areas.
A root cause is the fundamental reason for the occurrence of a defect or failure. Identifying and fixing root causes through root cause analysis helps prevent similar defects from occurring in the future.
A Rule is a single column in a decision table that maps a unique combination of conditions to their corresponding expected actions. Each rule represents a potential test case for the system.
A participant in a formal review who is responsible for recording anomalies, open points, and decisions made during the meeting. Also known as a recorder.
A Sequential Development Model is an SDLC approach where each phase of the development process must be completed before the next one begins. The V-model and Waterfall model are classic examples, characterized by their linear progression and distinct, non-overlapping stages.
The Software Development Lifecycle (SDLC) is a conceptual framework describing all activities in a software development project from initial planning to retirement. It provides structure to the development process by defining phases such as requirements analysis, design, coding, testing, and deployment.
A State is a recognizable condition or mode that a system, component, or object remains in while waiting for an event to occur. The system's response to an event depends heavily on its current state.
State Transition Testing is a black-box test technique based on a state machine model. It verifies that a system correctly transitions from one state to another when triggered by specific events and guard conditions.
The percentage of executable statements in the source code that have been exercised by a test suite. It is calculated by dividing the number of executed statements by the total number of executable statements.
A white-box test technique in which test cases are designed to execute specific statements in the source code. The goal is typically to increase statement coverage.
A Static Analysis Tool evaluates source code or models without executing the software. It identifies defects such as syntax violations, security vulnerabilities, and non-conformance to coding standards early in the development lifecycle.
Testing of a software work product without executing the code. This typically involves manual reviews or automated static analysis to find defects early in the software development lifecycle.
System Testing evaluates the behavior and capabilities of a complete, integrated system against its specified requirements. It takes an end-to-end perspective, simulating real-world scenarios and environments.
A peer review led by a trained moderator or technical expert to evaluate a product against technical specifications. The primary goal is achieving consensus on the technical approach.
The Test Basis is the body of knowledge or documentation used as the foundation for test analysis and design. It includes any information, such as requirements specifications, architecture diagrams, or user stories, from which test cases and test conditions are derived.
Test Control involves taking corrective actions when test monitoring indicates that testing is deviating from the test plan. This can include reprioritizing tests, adjusting schedules, or adding resources.
Test Estimation is the calculated approximation of a result related to various aspects of testing, such as effort, time, and cost. It involves predicting the resources required to execute a test plan based on metrics or expert judgment.
A Test Execution Tool executes test scripts automatically, comparing actual results against expected results. These tools often utilize capture/playback features, though programmatic scripting is preferred for maintainability.
A Test Management Tool provides support to the test management and control part of a test process. It often encompasses testware management, scheduling, defect tracking, and reporting capabilities.
A Test Metric is a quantitative measurement used to assess the efficiency, effectiveness, or progress of testing activities. Examples include test case execution rate, defect discovery rate, and test coverage.
Test Monitoring is the continuous activity of gathering and evaluating test metrics to track progress against the test plan. It provides visibility into testing activities and enables informed decision-making.
The reason or purpose for designing and executing a test. Objectives vary based on the context, such as finding defects, building confidence, or providing information for decision-making.
A Test Plan is documentation describing the test objectives to be achieved and the means and schedule for achieving them. It guides testing activities and communicates the scope, approach, resources, and schedule of intended test activities.
A Test Progress Report is generated at regular intervals during testing to communicate current status, metrics, and deviations from the plan. It helps stakeholders understand the ongoing health of the test effort.
A Test Strategy is a generalized description of the test process, usually at the organizational or program level. It defines how testing is performed and sets the standards for test processes across multiple projects.
A Test Summary Report is created at the end of a test level or project to evaluate whether exit criteria were met. It summarizes the testing activities, defect data, and lessons learned.
Testing is the process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation, and evaluation of a component or system. Its goal is to determine that the software satisfies specified requirements, demonstrate that it is fit for purpose, and detect defects.
A Transition is a change from one state to another (or back to the same state) triggered by an event. It defines the allowed paths a system can take through its lifecycle.
Use Case Testing is a black-box test technique in which test cases are designed to execute scenarios derived from use cases. It helps identify tests based on user interactions, focusing on the actor and the system's behavior.
A Valid Equivalence Class is a partition containing values that should be accepted by the component or system. Testing these values verifies that the software functions correctly under normal, expected conditions.
Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled. It asks, "Are we building the right system?"
Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled. It asks, "Are we building the system right?"
A review led by the author of the work product, with the goal of gathering feedback, educating participants, and establishing consensus. It can range from informal to formal.
White-box Testing is a test type based on the system's internal structure or implementation, such as code, architecture, or workflows. It requires understanding of the software's internal workings to design test cases.
A test technique based on an analysis of the internal structure of the component or system. It focuses on the internal control flow, data flow, or architecture, rather than the external behavior.
We're adding new exams every week. Let us know what you're studying for, and we'll bump it up our priority list! (Typical turnaround: 2-3 days)
Your feedback has been submitted successfully. We appreciate your help in making Cert Sensei better!