CTFL — Certified Tester Foundation Level (v4.0)

CTFL — Certified Tester Foundation Level (v4.0) glossary

233 terms the exam expects you to know, defined in plain language.

#

0-switch coverage(0-switch): A coverage criterion that requires testing every individual state transition, including invalid ones.
1-switch coverage(1-switch): A coverage criterion that requires testing every pair of consecutive transitions.

A

Acceptance Criteria(acceptance criteria): Conditions that a feature or user story must satisfy to be accepted by stakeholders.
Acceptance Test-driven Development(atdd, acceptance test-driven development): A test-first approach where test cases are created before implementing a user story.
Acceptance Test-driven Development (ATDD)(acceptance test-driven development, atdd): A practice where acceptance tests are defined before implementation to drive development.
Acceptance Testing(acceptance testing): A formal testing level performed to determine whether a system satisfies its acceptance criteria and is ready for deployment.
Acceptance criteria formats(acceptance criteria): Structured templates that define the conditions a user story must satisfy for acceptance.
Alpha Testing(alpha testing): Acceptance testing performed at the developing organization's site by non-developers, such as other staff or friendly users.
Anomaly(anomalies, anomaly): An issue or defect identified during the individual review of a work product.
Automated regression testing(automated regression tests): Testing that uses automation to verify that new changes do not adversely affect existing functionality.

B

Baseline(baseline): An approved configuration item that can only be changed through a formal change control process.
Behavior-Driven Development (BDD)(bdd): A development approach that expresses desired application behavior using test cases in simple natural language, often in Given/When/Then format, which are automatically translated into executable tests.
Benefits of Test Automation(potential benefits of using test automation): Advantages of test automation including time savings and prevention of human errors through consistency.
Beta Testing(beta testing): Acceptance testing performed by potential or existing users in their own environment, often as a pre-release.
Black-box Test Techniques(specification-based techniques, black-box test technique): Test techniques based on analysis of the specified behavior of the test object without reference to its internal structure.
Black-box Testing(black-box testing): A test design approach using external descriptions with no knowledge of internal code or structure.
Boundary Value Analysis(boundary value analysis): A black-box test technique that tests values at the boundaries between partitions.
Branch Testing and Branch Coverage(branch testing and branch coverage): A white-box test technique that measures the percentage of decision outcomes executed.
Branch coverage(branch coverage): A unit test coverage criterion requiring each branch of control flow to be executed, used for high-risk areas.

C

Categorical Input Partition(categorical input): A partition for categorical inputs where each valid value may correspond to a distinct system behavior, often requiring individual testing.
Change-related Testing(change-related testing): A test type that verifies the impact of system or environment changes through confirmation and regression testing.
Charters(charters): Mission statements or goals that guide testing sessions in session-based test management.
Checklist-Based Testing(checklist-based testing): A testing technique that uses a list of items to ensure coverage of common failures and completeness.
Collaborative User Story Writing(collaborative user story writing): A collaboration-based approach where stakeholders jointly create user stories to ensure shared understanding.
Collaborative test design(collaborative test design): An Agile practice integrating test design as a peer to systematic techniques in the development lifecycle.
Component Integration Testing(component integration testing): Testing that verifies interactions between components inside the system being built, typically automated in CI.
Configuration Item(configuration item, configuration items): A work product such as a test plan or test case that is managed under configuration management.
Configuration Management(configuration management, cm): A discipline for identifying, controlling, and tracking work products as configuration items.
Confirmation Testing(confirmation testing, re-testing): A test that verifies a fix successfully removed the defect by re-running the original failing test.
Context-Dependency of Best Practices(x is better than y as universal): A principle that ISTQB answers depend on context, preventing universal superiority claims.
Continuous Delivery(cd): A practice that ensures software can be released reliably at any time through automated deployment pipelines.
Continuous Delivery (CD)(cd): A practice extending CI with automated deployment to ensure software can be reliably released.
Continuous Improvement(continuous improvement): An ongoing effort to enhance processes by incorporating suggestions from retrospectives.
Continuous Integration(ci): A practice where developers frequently integrate code changes into a shared repository, triggering automated builds and tests.
Continuous Integration (CI)(ci): A practice of frequently integrating code changes with automated builds and tests for fast feedback.
Continuous Testing: A form of test execution where tests are run continuously, often as part of a CI/CD pipeline.
Contractual Acceptance Testing(contractual acceptance testing): Acceptance testing performed against acceptance criteria specified in a contract, typically for bespoke development.
Control Flow Graph(control flow graph): A graphical model of a program's control flow used to analyze logic paths.
Core Advanced Levels(core advanced levels, test analyst, technical test analyst): Higher-level ISTQB certifications for experienced testers, including Test Analyst, Technical Test Analyst, and Test Manager.
Coverage in Equivalence Partitioning(coverage): The percentage of identified partitions exercised by at least one test case.
Coverage metrics(coverage metrics): Metrics that measure requirements coverage or code coverage.
Coverage-based prioritization(coverage-based prioritization): A test case prioritization strategy where the order of execution is based on coverage criteria (e.g., code coverage).

D

Data archiving: Preservation of historical data according to retention rules during system retirement.
Data migration (retirement): Moving data to successor systems correctly when a system is retired.
Debriefing(debriefing): A discussion between the tester and stakeholders interested in the test results after a test session.
Debugging(debugging, debugging process): Activity concerned with finding, analyzing, and eliminating causes of failures (defects).
Decision Table(decision table, decision tables): A table that describes behaviour combinations for test conditions.
Decision Table Testing(decision table testing): A black-box test technique that tests combinations of inputs using a decision table.
Defect(defect): An imperfection or flaw in a system component that causes it to produce an incorrect result.
Defect Classification Rules(classification rules): Rules for categorizing anomalies during the defect management process.
Defect Detection(detecting defects): The process of identifying defects in software through testing.
Defect Management Process(defect management process): A workflow for handling individual defects from discovery to closure, including classification rules.
Defect Report(defect report): A document providing information to resolve defects and track quality.
Definition of Done(definition of done): In Agile, the team's objective metrics for a releasable item, used as exit criteria.
Definition of Ready(definition of ready): Entry criteria that a user story must fulfill to start development and testing activities.
DevOps(devops): A cultural shift and set of practices that bridges development and operations to achieve common goals.
DevOps Tools(devops tools): Tools supporting the DevOps delivery pipeline, workflow tracking, automated builds, and CI/CD.
Don't-Care Entry(don't-care entry, don't-care entries): An entry in a decision table that can match any value and allows rule collapsing.
Dynamic testing(dynamic testing): A testing technique that executes code to detect failures caused by defects.

E

Each Choice Coverage(each choice coverage): A coverage criterion requiring test cases to exercise each partition from each set of partitions at least once.
Equivalence Partition(equivalence partition, partition): A set of values that are treated identically by the test object.
Equivalence Partitioning(equivalence partitioning, ep, equivalence partitions): A black-box test design technique that divides input data into partitions of equivalent values from which a single representative is tested.
Equivalence Partitioning Coverage(100% equivalence partitioning coverage): A coverage criterion requiring at least one test case from each identified partition, both valid and invalid.
Equivalence Partitions(equivalence partitions): Non-empty, non-overlapping sets of data elements that are expected to be processed the same way by the test object.
Error guessing(error guessing): An experience-based testing technique that uses the tester's knowledge to predict where defects are likely to occur.
Exit Criteria(exit criteria): Conditions that define when a test phase can be considered complete.
Experience-based Test Techniques(experience-based test technique): Test techniques based on the tester's knowledge, intuition, and experience.
Exploratory Testing(exploratory testing): A disciplined testing approach where testers simultaneously design, execute, and learn from tests without pre-written scripts.
Extrapolation(extrapolation): A technique that estimates a new project's effort by scaling from actuals of past similar projects.

F

Failure(failure): An event in which a component or system does not perform a required function within specified limits.
Fault Attacks(fault attacks): A testing technique that deliberately introduces faults into a system to evaluate its robustness and error handling.
Fault attack(fault attack, fault attacks): A structured form of error guessing that uses a checklist of known weak spots to systematically provoke potential failures.
Formality spectrum(formality spectrum): The scale of formality in software reviews, ranging from informal reviews to inspections with defined process and criteria.
Functional Testing(functional testing): A test type that verifies what the system does using external specifications without internal code knowledge.

G

Generic Skills for Testing(generic skills required for testing, essential skills in testing): A set of core competencies including testing knowledge and personal attributes like thoroughness and attention to detail that effective testers should possess.
Given/When/Then format(given/when/then format, scenario-oriented format): A structured format for test cases consisting of three clauses: Given (precondition), When (action), Then (expected outcome).

I

INVEST criteria(invest): A set of six quality criteria for user stories, with testability as the most tester-influenced attribute.
ISO 25010 Quality Characteristics(iso 25010, quality characteristics): A standard framework referenced in the syllabus for defining software quality characteristics.
ISTQB Certified Tester Foundation Level(foundation level qualification, ctfl): A globally recognized entry-level certification for software testing professionals.
Ice Cream Cone Anti-Pattern(ice cream cone): A test portfolio dominated by UI/E2E tests with few unit tests, resulting in slow, flaky, expensive maintenance.
Impact analysis: Assessment of which parts of a system are affected by a planned change to focus testing efforts.
Independent Testing(independent tester): Testing performed by a tester not involved in development, providing unbiased verification and challenge of assumptions.
Individual Review Activity(individual review): The phase where each reviewer assesses the work product for quality and identifies anomalies.
Individual review(individual reading): The third step in a formal inspection process where reviewers individually examine the work product to find defects.
Informal review(informal review, informal reviews): A review type with no documented process, minimal preparation, and low cost, typically performed by author and a colleague.
Inspection(inspection): A highly formal review with defined roles, checklists, and metrics, designed for rigorous defect detection.
Inspection meeting(meeting in step 4): The fourth step in a formal inspection process where the team consolidates findings from individual reviews.
Invalid Partition(invalid partition, invalid partitions): A set of inputs that the system is supposed to reject, producing a defined error or fallback behavior.
Invalid state transitions(invalid transitions): Transitions that the system should reject, which must be included in coverage testing.
Iteration planning(iteration planning): A planning activity that looks ahead to the end of a single iteration, focusing on detailed risk analysis and task breakdown.

K

Keyword(keyword): A term listed below chapter headings that must be remembered at K1 level.

L

Level of Detail(level of detail): The specification of instructional objectives, keywords, and learning objectives for consistent courses and exams.
Long-term storage (testing): Ensuring backups remain readable after a system is taken out of service during retirement testing.

M

Maintenance testing: Testing of an operational system post-deployment, triggered by changes to the system or environment.
Manager Role Distinction in ISTQB(manager): The term 'Manager' in ISTQB context refers to the project/product manager, not the test manager.
Manual Regression Testing(manual regression, manual regression testing): A testing approach where regression checks are performed manually, often becoming a bottleneck in CI/CD pipelines.
Metrics in Inspection(metrics): Data collected during inspections used to improve the SDLC and the inspection process itself.
Migration trigger: A reason for maintenance testing involving moving a system to a new platform, such as from on-premises to cloud.
Model-Based Testing Tools(model-based testing tools): Tool that derives test cases automatically from models of system behaviour.
Modification trigger: A reason for maintenance testing involving changes to an operational system, including enhancements, corrective, and adaptive changes.
Monitoring and Control Feedback Loop(feedback loop): The cycle of planning, executing, monitoring, controlling, and updating the plan that runs continuously throughout the project.

N

Non-Functional Testing at Component Level(non-functional testing starting at the component test level): Performing non-functional testing early at the component test level where possible.
Non-functional Testing(non-functional testing): A test type that verifies how well the system performs regarding quality characteristics like performance or security.
Non-functional Testing Tools(non-functional testing tools): Tools that allow testers to perform non-functional testing difficult or impossible manually.

O

Operational Acceptance Testing (OAT)(operational acceptance testing, oat): Acceptance testing performed by operations staff to validate operational characteristics like backup, monitoring, and disaster recovery.
Operational tests: Tests performed on a new environment during a system migration to verify functionality and data integrity.
Orthogonal Dimensions(orthogonal dimensions): Independent input attributes that each have their own set of partitions, not automatically combined by equivalence partitioning.
Orthogonality of Test Levels and Types(orthogonality of levels and types): The principle that test levels and test types are independent, allowing any type at any level.
Output Partitioning(ep on outputs): The application of equivalence partitioning to output categories, requiring at least one test case per output partition.

P

PERT formula(pert formula): A weighted average formula (O+4M+P)/6 used in three-point estimation to compute an expected duration.
Pair Testing: A collaborative test execution session where two testers work together on the same tests.
Performance and Load Testing Tools(performance and load testing): Tool that simulates many concurrent users to test performance.
Planning Poker(planning poker): An Agile lightweight version of Wideband Delphi where team members estimate using numbered cards and reach consensus.
Process Activity Order(order of activities in a process): A common mis-recall where the sequence of testing process steps is reversed.
Product risk(product risk, product risks): A threat to the product's quality, concerning what could be wrong with the product.
Product risk analysis(risk analysis): Process of assessing product risks to influence test thoroughness and scope.
Project Progress Metrics(project progress metrics): Metrics that track task completion, resource usage, and test effort in a project.
Project Risks(project risk): Risks related to the management and control of a project, affecting schedule, budget, or scope.
Project risk(project risk, project risks): A threat to the project's ability to deliver on schedule, scope, budget, or team.

Q

Q1 (Technology-Facing Supporting Tests)(q1): Quadrant 1: automated, developer-led tests for unit, component, and API testing that support development.
Q2 (Business-Facing Supporting Tests)(q2): Quadrant 2: business-facing tests like functional tests and story tests that support development via ATDD/BDD.
Q3 (Business-Facing Critiquing Tests)(q3): Quadrant 3: manual, exploratory tests and UAT that critique the product from a business perspective.
Q4 (Technology-Facing Critiquing Tests)(q4): Quadrant 4: tool-supported tests for performance, security, and reliability that critique non-functional aspects.

R

Ratio-based estimation(ratio-based): A technique that estimates test effort as a fixed percentage of development effort based on historical ratios.
Regression Testing(regression testing): A test that verifies changes have not broken previously working behaviour by re-running a defined set of tests.
Regulatory Acceptance Testing(regulatory acceptance testing): Acceptance testing performed against regulatory or legal criteria, often by regulators or certified bodies.
Release planning(release planning): A planning activity that looks ahead to the end of a release, defining the test approach and plan across all iterations.
Representative Value(representative value): A single input value chosen from an equivalence class to represent all values in that partition during testing.
Residual risk(residual risk): The risk remaining in a product after testing activities have been performed.
Retirement trigger: A reason for maintenance testing involving taking a system out of service, focusing on data archiving, data migration, and long-term storage.
Retrospective(retrospectives): A meeting held at the end of a project, iteration, or milestone where participants discuss successes and areas for improvement.
Review Initiation Activity(review initiation): The phase ensuring participants are prepared and have necessary materials and role clarity.
Review Meeting(review meeting): A meeting where review participants discuss a work product, typically for technical reviews or inspections.
Review Participant Roles(review participants, author, review leader, scribe): Roles assigned to individuals in a review, such as author, moderator, scribe, and reviewers, with specific responsibilities.
Review Planning Activity(planning, planning phase): The initial phase where scope, purpose, exit criteria, and supporting information are defined.
Review Process(review process): A structured framework of activities for evaluating the quality of a work product.
Review Scope(scope): The defined boundary including purpose, work product, quality characteristics, focus areas, and timeframes.
Review Support Tools(review support tools): Tool that manages review workflows, checklists, and metrics.
Review Type Selection(review type selection, selecting review types): The process of choosing an appropriate review type based on objectives and factors such as project needs, resources, work product type, risks, business domain, and company culture.
Risk Impact(harm): The consequences or harm that may result from a risk occurrence.
Risk analysis: The process of identifying and assessing risks, distinct from risk control actions.
Risk control: Actions taken to adjust test intensity based on risk, without eliminating residual risk.
Risk level(risk level, risk exposure): The combination of likelihood and impact that determines a risk's priority for action.
Risk-based prioritization(risk-based prioritization): A test case prioritization strategy where the order of execution is based on risk analysis results, with the highest-risk tests run first.
Risk-based test technique selection(choose appropriate test techniques): A strategy that matches test techniques to risk levels, using rigorous methods for high risk and simpler checks for low risk.
Risk-based testing(risk-based testing): A testing approach that prioritizes tests based on identified product risks.
Risks of Test Automation(risks): Potential drawbacks requiring analysis and mitigation when introducing test automation.
Rule Collapsing(rule collapsing, collapse rules): The process of combining rules with don't-care entries to reduce table size.
Rule-oriented acceptance criteria(rule-oriented acceptance criteria, rule-oriented format): A format for acceptance criteria using bullet points or tabulated input-output mappings.

S

SDLC Phase Decision(release decision, decisions to move to the next phase): Project management activity using test results to decide progression to next SDLC phase.
Session-Based Test Management(session-based test management): A structured testing approach where test activities are organized into timed sessions with specific charters.
Session-based testing(session-based testing, session-based approach): A structured approach to exploratory testing performed within a defined time box, using a test charter and followed by a debriefing.
Severity vs. Priority(severity vs. priority): A common distractor in ISTQB exams distinguishing defect impact from fix urgency.
Simplified Decision Table(simplified decision table): A decision table where don't-care entries allow rule collapsing.
Smoke tests: A low-risk test technique that verifies basic functionality without exhaustive checking.
Software testing(testing): The process of evaluating software to detect differences between expected and actual results.
Specification Review(reviewing the specification from the perspective of testers): Reviewing specifications from a tester perspective to find potential defects.
State Transition Testing(state transition testing, all-transitions state coverage): A testing technique for sequential behaviour using state models.
State transition table(state table): A table representing all possible state transitions, used for test design.
Statement Testing and Statement Coverage(statement testing and statement coverage): A white-box test technique that measures the percentage of executable statements executed.
Statement coverage(statement coverage): A unit test coverage criterion requiring each statement to be executed, used for medium-risk areas.
Static Analysis(static analysis of source code): Analysis of source code without executing it, often performed before dynamic testing.
Static Analyzers(static analyzers): Tool that parses code for pattern defects, type issues, security anti-patterns, and style violations.
Static Testing(static testing, static test technique): A testing approach that examines software artifacts without executing code.
Success Factors for Reviews(success factors for reviews): Key practices that determine the effectiveness of reviews, including clear objectives, appropriate review type, small chunks, and stakeholder feedback.
Switch count in state transition testing(switch count): The number after 'switch' indicates the number of extra transitions beyond the first in a transition sequence.
System Integration Testing(system integration testing): Testing that verifies interactions between the system under test and external systems or services, often done by a dedicated team.
shift left testing(shift left, early testing): A principle of performing testing earlier in the development lifecycle to detect defects sooner and reduce costs.

T

Technical review(technical review): A medium-to-high formality review led by a trained facilitator, focusing on technical quality and decisions.
Test Analysis and Design(test analysis and design): The process of analyzing test conditions and designing test cases from test bases.
Test Basis Quality(test basis): The quality of the requirements and other documents used as a basis for testing, improved by addressing deficiencies identified in retrospectives.
Test Case Before Code(writing test cases before the code is written): Writing test cases before the code is written and running them in a test harness during implementation.
Test Charter(test charter): A concise document defining the scope, heuristics, and objectives of an exploratory testing session.
Test Completion(test completion): The phase occurring at project milestones where unresolved defects create change requests and testware is archived.
Test Completion Report(test completion report, test completion reports): A report summarizing test activities and results, communicated to stakeholders at test completion.
Test Control(control): The set of actions taken when monitoring reveals deviation from the plan or unacceptable risk.
Test Control Directives(control directives): Management instructions that modify test activities in response to monitoring results.
Test Design and Test Implementation Tools(test design and test implementation tools): Tools that facilitate generation of test cases, test data, and test procedures.
Test Effectiveness(test effectiveness): A measure of how well testing achieves its objectives, improved by implementing process improvement suggestions.
Test Effort Estimation(test estimation, test effort estimation): Predicting the amount of test-related work needed to meet test objectives.
Test Environment: The infrastructure and configuration used for test execution, which is verified before and shut down after testing.
Test Execution(test runs): The process of running tests according to a schedule, which can be manual or automated.
Test Execution Schedule(execution schedule): A plan for the timing and order of test runs to ensure efficient test execution.
Test Execution and Test Coverage Tools(test execution and test coverage tools): Tools that facilitate automated test execution and coverage measurement.
Test Harness(test harness): A framework or tool that automates the execution of tests and collects results.
Test Independence(test independence, levels of test independence): The degree of separation between the testing team and the development team to ensure objective testing.
Test Level(level): A scope of the system being tested, such as component, integration, system, or acceptance.
Test Level vs. Test Type(test level vs. test type): A common distractor in ISTQB exams differentiating scope level from testing category.
Test Management Role(test management role, test management): The role responsible for the test process, test team, and leadership of test activities, with a focus on test planning.
Test Manager(test manager): An ISTQB Advanced Level certification focusing on test management and leadership.
Test Metrics(test metrics, metrics used in testing): Measurements used to evaluate progress, quality, and effectiveness of testing against objectives.
Test Monitoring(monitoring, test monitoring): The process of gathering data on test progress, defects, coverage, effort, and risks to track against the test plan.
Test Objectives(test objectives): Goals of testing that vary by context, such as finding defects or verifying requirements.
Test Plan(test plan): A document detailing the scope, approach, resources, and schedule of intended test activities.
Test Planning(test planning): The activity of defining the test objectives, approach, resources, and schedule for testing efforts.
Test Progress Metrics(test progress metrics): Metrics that track test case implementation and test environment preparation.
Test Pyramid(testing pyramid, pyramid): A model describing the recommended distribution of automated tests with many fast unit tests at the base.
Test Runners(test runners): Tool that executes scripted tests, such as xUnit frameworks.
Test Session Report(session report): A brief report produced after each exploratory testing session covering findings, defects, risks, and follow-up needs.
Test Techniques: Systematic methods used to develop a relatively small but sufficient set of test cases.
Test Tools(test tools): Software applications that support various testing activities.
Test Type(type): An aspect of the system being tested, such as function, performance, security, or internal structure.
Test case prioritization(test case prioritization): The process of arranging test suites in an execution order based on specific criteria such as risk or coverage.
Test monitoring and control(test monitoring and test control): The process of tracking test progress and making adjustments to schedule, resources, or plans.
Test objective(test project objective): Goal or purpose of testing, such as finding defects or ensuring quality.
Test progress report(test progress reports): A regular report that summarizes ongoing test activities, deviations, and metrics for stakeholders.
Test-Driven Development (TDD)(tdd): A development approach where tests are written before code to direct coding through test cases, then code is written to satisfy tests, followed by refactoring.
Tester's Contribution to Iteration and Release Planning(tester's contribution to iteration and release planning): The involvement of testers in planning iterations and releases to ensure testability and coverage.
Testing(testing): Activity that triggers failures caused by defects (dynamic) or directly finds defects (static).
Testing Quadrants(testing quadrants, quadrants): A 2x2 model categorizing tests by supporting vs. critiquing the product and business-facing vs. technology-facing dimensions.
Testing Role(testing role, testing): The role responsible for executing test activities as assigned, depending on project and product context.
Testing as Quality Control(testing as a form of quality control): A form of quality control that helps achieve test objectives within constraints.
Testing as risk reduction(testing is a risk-reduction activity, testing as risk-reduction activity): The principle that each test, test execution, and defect found reduces the residual risk of the product.
Testware(testware, test documentation): Artifacts from testing, such as scripts and data, that may be archived for future use.
Testware Quality(testware): The quality of test artifacts such as test cases and scripts, improved by jointly reviewing test processes.
Three Amigos(three amigos): A collaborative practice using business, development, and testing perspectives to design test scenarios.
Three-point estimation(three-point estimation, three-point estimating): A technique that combines optimistic, most likely, and pessimistic estimates using the PERT formula to produce an expected value and variance.
Three-value boundary value analysis(three-value bva): A test design technique that tests boundaries with three values per boundary, used for high-risk areas.
Traceability(traceability): Link between test basis, test conditions, test cases, and code that enables impact analysis.

U

Unit Test Frameworks(unit test frameworks): Framework for writing and running unit tests, e.g., JUnit, pytest, NUnit.
User Acceptance Testing (UAT)(user acceptance testing, uat): Acceptance testing performed by actual users or their representatives to validate business process support.
User story(user stories): A short, simple description of a feature told from the perspective of the user, typically following a template and including acceptance criteria.
User story format(as a... i want... so that): The common template for writing a user story: 'As a [role], I want [goal], so that [value]'.

V

Valid Partition(valid partition, valid partitions): A set of inputs that the system is supposed to accept, each leading to the same expected behavior.
Validation: The process of checking whether a system meets users’ and stakeholders’ needs in its operational environment.
Validation vs. Verification(validation vs. verification): A common distractor in ISTQB exams differentiating user needs from specification checks.
Verification: The process of checking whether a system meets specified requirements.

W

Walkthrough(walkthrough, walkthroughs): A low-formality review led by the author to achieve common understanding and find defects.
White-box Test Techniques(structure-based techniques, white-box test technique, white-box test techniques, white-box testing): Test techniques based on analysis of the test object's internal structure and processing.
White-box Testing(white-box testing): A test design approach using internal structure to measure coverage of code elements like statements or branches.
Whole Team Approach(whole team approach): A practice where all team members share responsibility for quality and can perform tasks based on skills, often in a co-located workspace.
Wideband Delphi(wideband delphi): An expert-based consensus estimation method where experts estimate privately, discuss, and iterate toward convergence.
Work product(artifact, documentation): Artifact produced during the software lifecycle that can be examined by static testing.