Every key term in the Certified Tester Foundation Level v4.0 syllabus, explained in our own words with a simple version and an example. Practice them as flashcards, too.
The basic form of BVA. Every boundary gives two coverage items: the boundary itself and the value right next to it on the other side, which belongs to the neighboring partition.
In plain English: For each edge, test the edge value and the nearest value on the other side.
Example: For valid ages 18 to 65 (whole years), test 17 and 18 for the lower boundary and 65 and 66 for the upper one.
The stronger form of BVA. Every boundary gives three coverage items: the boundary itself plus the values immediately below and above it. It can expose defects that the 2-value form would let through.
In plain English: For each edge, test the edge value and the values on both sides of it.
Example: For valid ages 18 to 65 (whole years), test 17, 18 and 19 at the lower boundary and 64, 65 and 66 at the upper one.
A testing principle. Believing that a well-verified, almost defect-free system must succeed is a mistake: if it does not solve the users’ real problems, it still fails. Validation is needed alongside verification.
In plain English: A product with no known bugs can still fail if users do not want it.
Example: A booking system passes every test, but customers abandon it because it needs twelve steps to book one room.
The conditions a user story’s implementation has to meet before stakeholders accept it. They set the story’s scope, help the team agree, describe positive and negative scenarios and form the basis for acceptance tests.
In plain English: The rules that a story must meet before it is accepted as done.
Example: A renewal is allowed only if nobody has reserved the book, and the new due date is shown after renewal.
A test-first approach, often called ATDD, in which business, development and test people together turn acceptance criteria into acceptance tests before the story is built. The tests, often automated, then steer development.
In plain English: The team writes acceptance tests first, then builds the feature to pass them.
Example: Before coding the renewal story, the team writes tests for a normal renewal, a reserved book and a maximum renewal count.
Testing that checks whether the system is fit for real business use and ready to deploy, focusing on validation. Forms include user, operational, contractual and regulatory acceptance testing, and alpha and beta testing.
In plain English: Users or customers test the system to decide if they accept it.
Example: Accounting staff run their month-end close in the new system to decide whether it can go live.
A state transition coverage criterion requiring tests to exercise every valid transition and to try every invalid transition. It is the strongest of the state coverage levels in the syllabus and suits critical software.
In plain English: Our tests must use every allowed move and also try every move that is not allowed.
Example: Besides the valid workflow moves, tests also try to approve a draft directly and check the system refuses.
Anything that differs from what was expected, based on specifications, standards or someone’s experience. An anomaly found in a review or test may turn out to be a defect, or not.
In plain English: Something that looks different from what we expected.
Example: A reviewer notes that a design shows two different maximum file sizes; analysis shows the requirement is wrong.
The review role of the person who produced the work product being reviewed; they are also the one who corrects it afterwards.
In plain English: The person who wrote the document or code that is being reviewed.
Example: The developer who wrote the payment module explains its design and later corrects the issues the reviewers raised.
A test-first practice, often called BDD, in which the wanted behavior is captured as concrete scenarios in everyday language, usually Given/When/Then, readable by business people and convertible into automated tests.
In plain English: Describing how the system should behave in simple sentences that become tests.
Example: Given a cart with two books, when the user removes one, then the cart shows one book and the new total.
A test technique that derives tests from the specified behavior of the test object, ignoring how it is built inside. Because tests don’t depend on the code, they remain useful when the implementation changes.
In plain English: A way to design tests from the requirements, not from the code.
Example: Equivalence partitioning, boundary value analysis, decision table testing and state transition testing are black-box techniques.
Testing based on specifications and the expected external behavior of the test object, without using its internal structure. Its main aim is to check behavior against the specification.
In plain English: Testing the system from the outside, without looking at the code.
Example: Testing a currency converter only by entering amounts and comparing results with the published exchange rules.
A black-box technique that targets the smallest and largest values of ordered partitions, because mistakes at these edges are common. It comes in a 2-value version and a stronger 3-value version.
In plain English: Test the values at the edges of each group, where mistakes often happen.
Example: For quantities 1 to 99, test 1 and 99, and the values just outside such as 0 and 100.
The percentage of branches, the possible transfers of control both conditional and unconditional, that tests have exercised. 100% branch coverage includes 100% statement coverage, but not the other way round.
In plain English: The percent of possible paths after each decision that our tests have used.
Example: For “if (vip) discount = 10”, tests with vip = true and vip = false are both needed for 100% branch coverage.
An experience-based technique in which tests are built and run to cover the items on a checklist. The checklist comes from experience, knowledge of what matters to users, or understanding of why software fails.
In plain English: Testing by following a list of things to check.
Example: A tester uses a usability checklist: every field has a label, error messages say how to fix the problem, buttons are clearly named.
An approach in which business, development and test people work together, mainly to prevent defects rather than find them, for example through jointly written user stories, acceptance criteria and acceptance tests.
In plain English: People from business, development and testing work together to prevent problems.
Example: The product owner, a developer and a tester meet to agree examples for a story before any code is written.
Testing that components talk to each other correctly through their interfaces. The order of testing follows an integration strategy such as bottom-up, top-down or big-bang.
In plain English: Testing how small pieces of code work together.
Example: Checking that the shopping cart component passes the correct product codes and quantities to the pricing component.
Testing a single component separately from the rest of the system, typically done by developers in their own environment using unit test frameworks, stubs or drivers. Often called unit testing.
In plain English: Testing one small piece of the code by itself.
Example: A developer tests the interest calculation function with different amounts and rates, using a stub instead of the real database.
The practice of naming, versioning, baselining and controlling changes to work products, including testware, so the team always knows which versions belong together and can reproduce any test.
In plain English: Keeping track of versions of code, tests and documents and controlling changes.
Example: The defect report states that it was found in build 4.2.1 with test suite version 17, so it can be reproduced exactly.
Testing done after a defect is fixed to confirm the original defect is really gone, usually by rerunning the tests that failed because of it. Also called re-testing.
In plain English: Running the failed test again to check that the fix works.
Example: After the developer fixes the wrong VAT total, the tester runs the same failed test again and it now passes.
A practice where developers merge small code changes often into a shared repository, and each change is automatically built and tested so integration problems are found quickly.
In plain English: Developers join their code often, and tests run automatically each time.
Example: A failing automated test on Tuesday’s merge tells the developer within ten minutes that their change broke the search feature.
A measure, normally a percentage, of how many of the coverage items defined by a technique the tests have actually exercised. Higher coverage means more thorough testing for that particular measure.
In plain English: How much of something our tests have checked, often shown as a percent.
Example: If 45 of 50 requirements have at least one passing test, requirements coverage is 90%.
The unit a test technique counts when measuring coverage, derived from the test conditions. For example, a partition, a boundary value, a decision table column, a transition, a statement or a branch.
In plain English: One thing that a test can cover, used to count coverage.
Example: In equivalence partitioning each partition is a coverage item; in branch testing each branch is a coverage item.
What developers do once a problem is known: reproduce the failure, diagnose which defect causes it and fix the code. Testing exposes problems; debugging removes their causes, and confirmation testing then checks the fix.
In plain English: Finding why the software is wrong and changing the code to fix it.
Example: A tester reports that totals are wrong; the developer steps through the code, finds a rounding bug and corrects it.
A black-box technique for testing combinations of conditions and the resulting actions, laid out as a table where each column is a decision rule. Full coverage means exercising every feasible column.
In plain English: A table that lists all mixes of conditions and the result for each mix.
Example: Loan approval depends on “employed?” and “credit score above 700?”: four rules, each tested once, with its expected decision.
A flaw in a work product, such as code, a requirement or a test script, that results from an error. Also called a bug or fault. If defective code is executed, it may cause a failure.
In plain English: A problem inside the code or a document, caused by a person’s mistake.
Example: The line of code that calculates the discount before tax, instead of after tax, is a defect.
An agreed workflow for handling reported anomalies from the moment they are logged, through classification, analysis and fixing, to closure.
In plain English: The steps for logging problems and following them until they are closed.
Example: Each new defect is logged, triaged by the team, assigned to a developer, fixed, re-tested by the tester and then closed.
A written record of an anomaly that gives developers and others enough detail to reproduce and resolve it: context, steps, expected and actual results, severity, priority and status.
In plain English: A written description of a problem so it can be repeated and fixed.
Example: Title: Total wrong with two discount codes. Steps, expected $90, actual $85, build 4.2.1, severity high, screenshot attached.
A testing principle. Defects are rarely spread evenly: a few components tend to hold most of them or cause most failures in operation, similar to the Pareto 80/20 pattern. Expected clusters help direct risk-based testing.
In plain English: Most problems are usually found in a few parts of the system.
Example: Past releases show that most defects were in the pricing module, so it gets more testing this time.
The Agile form of exit criteria: the objective, agreed conditions a story, iteration or release must meet before it can be called complete and releasable.
In plain English: The team’s agreed checklist that says when work is truly finished.
Example: A story is done when code is reviewed, automated tests pass, acceptance criteria are met and the help text is updated.
A way of organizing work so that development, testing and operations pursue the same goals together, relying on automated pipelines, continuous integration and continuous delivery to release small changes quickly and safely.
In plain English: Development and operations teams work together and automate building, testing and releasing.
Example: Every code commit automatically triggers a build, component tests and deployment to a test environment within minutes.
Testing that requires executing the software. It finds failures, which are then traced to defects, and it is needed for behavior that can only be seen at run time, such as performance.
In plain English: Testing by running the software.
Example: Running the checkout process with test card numbers to see whether payments are accepted or refused correctly.
A testing principle. A defect caught early cannot spread into the designs, code and tests built on top of it, so fixing it is far cheaper. Start reviews and tests as soon as work products exist.
In plain English: Finding problems early is cheaper than finding them late.
Example: A wrong rule spotted in a user story review costs minutes to fix; found in production it may need a hotfix and refunds.
The conditions agreed in advance that must be true before a test activity may begin, for example people and tools in place, testware ready, and the test object of good enough quality. Agile teams often call this Definition of Ready.
In plain English: The conditions that must be true before testing can begin.
Example: System testing starts only when the build passes smoke tests, the environment is ready and test data is loaded.
A black-box technique that splits possible values into groups, called partitions, that the software should treat identically. Since any value represents its whole partition, one test per valid and invalid partition is enough.
In plain English: Put values into groups that act the same, then test one value per group.
Example: For an age field accepting 18 to 65, the partitions are below 18, 18 to 65, and above 65; test 10, 40 and 70.
A human mistake, such as a misunderstanding or a slip, made by someone working on the software. Errors can be caused by time pressure, complexity, fatigue or lack of training. Also called a mistake.
In plain English: A mistake a person makes while doing their work.
Example: A developer misreads the requirement and believes discounts apply before tax instead of after tax.
An experience-based technique in which testers foresee likely mistakes, defects and failures from what they know about the system, past failures and common developer errors, then test for them. Fault attacks apply it systematically.
In plain English: Using experience to guess where the software may break and testing there.
Example: Knowing that date fields often fail, a tester tries 29 February, 31 April and an empty date.
A metrics-based estimation technique that uses ratios collected from earlier projects in the organization, such as the ratio of development to test effort, to estimate testing for a new project.
In plain English: Use numbers from old projects to estimate test work for a new one.
Example: If past projects had a 3:2 development-to-test effort ratio, 600 development days suggests about 400 test days.
A testing principle. Apart from tiny programs, there are far too many input and condition combinations to try them all, so testers rely on techniques, risk and priorities to choose a useful subset.
In plain English: We cannot test every possible input and situation, so we must choose wisely.
Example: A form with ten fields, each accepting many values, has billions of combinations, so partitions and risk guide which to test.
The conditions agreed in advance that show when a test activity can be treated as finished, for example a coverage target reached, few enough open defects, or the planned time or budget used up.
In plain English: The conditions that tell us testing can stop.
Example: Testing ends when 95% of requirements are covered, no critical defects are open and all high-risk tests have passed.
A test technique that relies on what testers know and have seen before to design and run tests. It often catches defects that black-box and white-box techniques miss, but its results depend on the tester.
In plain English: A way to test that uses the tester’s knowledge and past experience.
Example: Error guessing, exploratory testing and checklist-based testing are experience-based techniques.
An experience-based approach in which the tester designs, runs and evaluates tests at the same moment, using what they learn to choose the next test. It is often organized as time-boxed sessions with a test charter.
In plain English: Learning about the software and testing it at the same time.
Example: In a 60-minute session with the charter “explore refunds with partial deliveries”, a tester designs and runs tests as she learns.
A metrics-based estimation technique that takes measurements early in the current project and projects them forward, for example averaging test effort from past iterations to estimate the next one.
In plain English: Use data from earlier work in this project to predict the rest.
Example: The last three iterations needed 40, 44 and 42 test hours, so the next iteration is estimated at about 42 hours.
An event where the system does something it should not do, or fails to do something it should, as seen when it runs. Failures can come from defects or from environmental conditions such as radiation.
In plain English: When the running software does the wrong thing and someone can see it.
Example: A customer’s invoice shows a total that is two dollars lower than it should be.
Any review that follows a set process, with assigned roles and recorded results, such as a technical review or an inspection.
In plain English: A review with fixed steps, roles and written results.
Example: An inspection of a safety requirement document with planned meetings, assigned roles and a recorded list of anomalies.
Testing what the system should do: its functions, judged by functional completeness, correctness and appropriateness.
In plain English: Testing that the system does the right things.
Example: Checking that a library system correctly calculates the late fee when a book is returned five days late.
The degree to which testers are separate from the authors of what they test, from none (authors test their own work) up to testers outside the organization. More independence finds different defects but can cause isolation and slower feedback.
In plain English: Testing done by someone other than the person who made the product.
Example: Developers test their own code, a separate test team tests the system and an outside company does the security testing.
A lightweight review with no prescribed steps and no required written output. Its main aim is to spot anomalies quickly and cheaply, for example a colleague glancing over a change.
In plain English: A quick check by a colleague, without fixed steps or formal records.
Example: A developer asks a teammate to look over a pull request and comment before lunch.
The most formal type of review, using the complete review process. It aims to find as many anomalies as possible, and it collects metrics to improve processes. The author may not act as review leader or scribe.
In plain English: The most formal review, with strict steps and measurements.
Example: A flight control requirements document is inspected with checklists, timed individual reviews and recorded defect counts per page.
Testing changes to a system already in operation, triggered by modifications, upgrades or migrations of the environment, or retirement. It includes testing the change and regression testing, scoped by impact analysis.
In plain English: Testing a live system after it is changed, moved or removed.
Example: When the company moves its live HR system to a new cloud platform, testers check data migration and run regression tests.
The review role that decides which work products get reviewed and makes sure the review has the people and time it needs.
In plain English: The person who decides what to review and gives time and people for it.
Example: The project manager decides the security design must be reviewed and schedules two days for four reviewers.
The review role that keeps review meetings productive: it watches the clock, settles disagreements and makes sure every participant feels safe to speak.
In plain English: The person who runs the review meeting and keeps it fair and on time.
Example: When two reviewers argue about wording, the moderator records the point as open and moves the meeting on.
Testing how well the system behaves, covering quality characteristics such as performance efficiency, compatibility, usability, reliability, security, maintainability and portability.
In plain English: Testing how well the system works, like speed, security and ease of use.
Example: Measuring whether the search page still responds within two seconds when 1,000 users are online.
A risk related to the quality characteristics of the product, such as missing functions, wrong calculations, poor performance or security weaknesses, that could harm users or the business.
In plain English: A risk that the product itself will not work well or be good enough.
Example: Interest may be calculated wrongly for leap years, giving customers the wrong balance.
A risk to the management and control of the project, such as organizational, people, technical or supplier problems, that can affect schedule, budget or scope.
In plain English: A risk that can make the project late, expensive or smaller.
Example: The only performance tester may leave the company in the middle of the release.
How well a product meets the stated and implied needs of its stakeholders. Testing helps measure quality and gives the information needed to improve it.
In plain English: How good the product is for the people who use it and pay for it.
Example: A banking app that is correct, fast, secure and easy to use has high quality for its customers.
Work that improves and enforces the way products are built, aiming to prevent defects rather than find them. Testing is different: it is quality control, which examines the product itself to find and correct problems.
In plain English: Making the way we work better so fewer problems are made.
Example: Introducing coding standards and peer review into the team’s process is quality assurance; running tests on the build is quality control.
Testing to check that a change, such as a fix or new feature, has not broken anything that worked before, in the changed component or elsewhere. It is a strong candidate for automation.
In plain English: Testing old features again to make sure a change did not break them.
Example: After the login page is redesigned, the automated suite checks that ordering, payment and account pages still work.
A meeting held at the end of an iteration, release or project in which the team discusses what went well, what did not and how to improve. Results feed process improvement, including testing.
In plain English: A team meeting after some work to learn how to work better next time.
Example: After a sprint the team agrees that late test data caused delays and decides to prepare data during refinement.
A static testing activity in which people read and examine a work product to find anomalies, judge its quality or suggest improvements. Reviews vary from quick informal checks to fully formal inspections.
In plain English: People read and check a document or code to find problems.
Example: Two testers and a developer read a new API specification and list unclear and missing error codes.
The review role in overall charge of a review, which chooses the participants and arranges the time and place of the review.
In plain English: The person in charge of organizing the whole review.
Example: The review leader chooses four reviewers, sends out the document and checklist, and books the meeting room.
The review role of anyone who examines the work product and reports anomalies. A reviewer may be a team member, a subject matter expert or any other stakeholder.
In plain English: A person who reads the work and looks for problems.
Example: A tester, a security expert and a customer representative each check the same requirements from their own point of view.
A situation or event that has not happened yet but could, and that would cause harm if it did. Every risk is described by how likely it is and how serious its impact would be.
In plain English: Something bad that might happen in the future.
Example: There is a chance that the payment provider changes its interface before launch, which would stop all sales.
The part of risk management that consists of risk identification and risk assessment. For product risks it shapes the scope, techniques, levels and priority of testing.
In plain English: Finding the risks and deciding how serious each one is.
Example: In a workshop the team lists 30 product risks and scores each one for likelihood and impact.
Working through the identified risks: grouping them, estimating likelihood and impact, deciding each risk level, ranking them and suggesting how to respond. It can use numbers, ratings such as a risk matrix, or both.
In plain English: Judging how likely and how harmful each risk is, and ranking them.
Example: The team rates each risk high, medium or low in a risk matrix and decides which ones need extra testing.
The measures taken in response to analysed risks, made up of risk mitigation and risk monitoring. Responses can include mitigation by testing, acceptance, transfer or a contingency plan.
In plain English: Actions we take to handle risks and keep watching them.
Example: For a payment risk the team adds tests (mitigation), buys insurance (transfer) and prepares a manual payment fallback (contingency plan).
Building as complete a list of risks as possible, for example through brainstorming, workshops, interviews or cause-effect diagrams.
In plain English: Making a list of all the risks we can find.
Example: Testers, developers and support staff brainstorm what could go wrong with the new online checkout.
A measure of how important a risk is, based on its likelihood and impact. In quantitative analysis it is often calculated as likelihood multiplied by impact.
In plain English: How serious a risk is, using how likely it is and how much harm it does.
Example: Likelihood 4 of 5 and impact 5 of 5 give a risk level of 20, so it is tested first.
The coordinated activities that help an organization reach its goals by dealing with risks: risk analysis (identification and assessment) and risk control (mitigation and monitoring).
In plain English: Finding, judging and handling risks so they do less harm.
Example: Each sprint the team reviews its risk list, adds new risks, rescores old ones and agrees actions.
Putting the planned risk responses into action so that a risk becomes less likely or less damaging. For product risks, testing is a common way to mitigate them.
In plain English: Doing things that make a risk less likely or less harmful.
Example: Because rounding errors are high risk, the team adds boundary tests and independent review of the calculation code.
Following risks over time to confirm that mitigation is working, to refine the risk assessment with new information and to spot risks that are new or changing.
In plain English: Watching risks over time to see if they change or new ones appear.
Example: Weekly reports show that tests for the rounding risk now pass, so its level is lowered, while a new supplier risk is added.
A test approach where the choice, prioritization and management of test activities are driven by risk analysis and risk control, so effort goes where possible harm is greatest.
In plain English: Testing more where the risks are bigger.
Example: High-risk payment features get several techniques and early testing; a low-risk “about us” page gets a quick check.
The underlying reason a defect was introduced. Removing it stops the same kind of problem from appearing again, so root cause analysis asks why the error happened, not just where the defect is.
In plain English: The deepest reason why a problem happened in the first place.
Example: Several tax defects trace back to a requirements template with no field for tax rules; fixing the template is addressing the root cause.
The review role that gathers the anomalies reported by reviewers and writes down what happens in the review, such as decisions taken and new anomalies raised in the meeting.
In plain English: The person who writes down the problems and decisions from the review.
Example: During the inspection meeting the scribe logs each anomaly with its location, the reviewer’s name and the agreed action.
Doing testing earlier in the lifecycle than it traditionally happened, such as reviewing requirements, writing tests before code, using continuous integration and running static analysis before dynamic testing.
In plain English: Starting testing earlier in the project.
Example: Testers review user stories during refinement and run non-functional tests at component level instead of waiting for system testing.
The phases and activities a software product goes through from idea to retirement, often written SDLC. The chosen lifecycle model, sequential, iterative or incremental, strongly affects when and how testing happens.
In plain English: All the steps used to create and change software, from idea to end.
Example: In a sequential model testers mostly work after coding ends; in an iterative model they test in every short cycle.
A black-box technique that models a system’s states and the events that move it between them, using a state diagram or state table, then designs tests to cover states or transitions.
In plain English: Testing how the system moves from one situation to another after events.
Example: An ATM card moves from “active” to “locked” after three wrong PINs; tests check this and that a locked card is refused.
The percentage of executable statements in the code that have been exercised by tests. 100% means every statement ran at least once, but it does not guarantee every decision outcome was tested.
In plain English: The percent of code lines (statements) that our tests have run.
Example: Code with “if (vip) discount = 10”: one test with vip = true runs every statement, giving 100% statement coverage.
Tool-supported checking of code or other work products without running them, for example for coding-standard breaches, unreachable code, security weaknesses or complexity. It can run automatically in the build pipeline.
In plain English: Using a tool to check code for problems without running it.
Example: A tool in the build pipeline warns that a variable is used before it gets a value.
Testing that examines work products without executing them, either by people (reviews) or by tools (static analysis). It works on requirements, user stories, designs, code, test cases and almost any readable work product.
In plain English: Checking documents or code without running the software.
Example: Reviewing a user story and finding that it never says what happens when a payment is declined.
Testing the connections between the system being tested and other systems or external services it depends on, such as payment gateways, partner systems or cloud services.
In plain English: Testing how our system works with other systems.
Example: Checking that the online shop sends correct order data to the warehouse system and handles its error replies.
Testing the complete, integrated system: whole end-to-end tasks plus non-functional qualities such as performance and usability. It is often done by independent testers in an environment close to production.
In plain English: Testing the complete system to see if it works as required.
Example: Testers check an insurance system end to end, from quote to policy to claim, and also measure its response times.
A review carried out by people with strong technical knowledge and run by a moderator. Its main purpose is to agree on and decide technical issues, while also finding anomalies and judging quality.
In plain English: Experts check a technical document to find problems and agree on solutions.
Example: Senior developers review a proposed database design, led by a moderator, and decide which indexing approach to use.
Examining the test basis to find what can be tested, then writing and ranking test conditions and noting the risks linked to them. In short, it decides what to test.
In plain English: Studying the requirements to decide what needs testing.
Example: From a password reset story the tester derives conditions such as valid link, expired link and reused link.
How testing will be done in a particular project, tailored to its context: for example which test levels, test types, techniques, deliverables, entry and exit criteria and level of independence will be used.
In plain English: The chosen way to do the testing for this project.
Example: The approach for a mobile app: risk-based testing, automated component and API tests, plus exploratory sessions on real devices.
Using software to run tests and other test tasks that would otherwise be done by hand. It saves time on repeated work and gives consistency, but has risks such as unrealistic expectations, underestimated costs and over-reliance on tools.
In plain English: Using tools to run tests automatically instead of by hand.
Example: An automated regression suite of 800 tests runs every night; maintaining the scripts after UI changes takes a tester two days each sprint.
Any source of information that tests are derived from, such as requirements, user stories, designs, code or even the knowledge of experts. Defects in the test basis can be found by reviewing it.
In plain English: The documents or knowledge we use to decide what to test.
Example: For an online shop the test basis may include user stories, acceptance criteria, an API specification and wireframes.
A single designed test: the starting conditions, the inputs and actions to perform, the result that should occur and the expected state afterwards. Each test case covers at least one test condition.
In plain English: A written test with steps, input values and the result we expect.
Example: Precondition: user is logged in. Input: transfer $50 with $40 balance. Expected: transfer refused with an “insufficient funds” message.
Deciding the order in which test cases run, for example risk-based, coverage-based or requirements-based, while respecting dependencies between tests and the availability of resources.
In plain English: Deciding which tests to run first.
Example: Tests for the high-risk payment feature run first, but the “create account” test must run before them because they depend on it.
The wrap-up at a milestone such as a release or the end of an iteration: turning open defects into change requests or backlog items, keeping reusable testware, closing environments, capturing lessons and reporting.
In plain English: Finishing the testing work, saving useful things and sharing lessons.
Example: At the end of the release the team archives the regression suite, raises change requests for open defects and holds a short lessons-learned meeting.
A report written when testing for a level, iteration or project ends. It summarizes what was tested, assesses product quality against the plan and exit criteria, and records deviations, open defects, remaining risks and lessons learned.
In plain English: A final report that sums up the testing when it is finished.
Example: At release end the report states that exit criteria were met, two low-severity defects remain open and test data preparation should start earlier.
An aspect of the test object that the testing should cover, such as a function, rule, quality characteristic or risk. Test conditions are identified during test analysis.
In plain English: One thing about the product that we want to check.
Example: For a parking app: “a user can pay for parking with a saved card” is one test condition.
Acting on what monitoring shows so that testing still reaches its goals, for example by reprioritizing tests, adjusting the schedule, re-checking entry or exit criteria, or adding people or tools.
In plain English: Changing the testing plan or work when progress is not as expected.
Example: Because a key environment is late, the test manager moves high-risk tests forward and adds a second tester.
The values and records needed to run tests, including inputs and any data that must already exist in the system or its databases.
In plain English: The information, like names and numbers, we use when we run tests.
Example: A set of test customers with different loyalty levels, addresses in three countries and an expired credit card.
Working out how to test: converting test conditions into test cases, usually with test techniques, and deciding the coverage items, test data and test environment that those cases will need.
In plain English: Making test cases from the things we decided to test.
Example: The tester applies boundary value analysis to the condition “age must be 18 to 65” and writes test cases for 17, 18, 65 and 66.
Actually running the tests, by hand or with tools, in the planned order; comparing what happened with what was expected; logging the outcomes; and investigating differences to find probable defects.
In plain English: Running the tests and recording what happens.
Example: A tester runs the checkout suite, sees one test produce the wrong total and logs a defect report with the evidence.
Preparing everything required before tests can run: writing manual procedures or automated scripts, getting test data, setting up and checking the test environment, grouping tests into suites and scheduling them.
In plain English: Getting all tests, data and tools ready so testing can start.
Example: The team writes automated scripts, loads 200 customer records into the test database and orders the suites for Monday’s run.
A stage of testing with its own goals, test basis, test objects and usually its own people and environment. The CTFL levels are component, component integration, system, system integration and acceptance testing.
In plain English: A stage of testing, from small parts to the whole system.
Example: The same feature is tested by developers at component level, by testers at system level and by users at acceptance level.
Responsibility for leading the test process and the people doing it, mainly through planning, monitoring, control and completion. A test manager, team lead, coach or the team itself may hold it.
In plain English: The person who plans testing, follows progress and leads the test work.
Example: A test manager sets the plan for three teams, tracks progress daily and decides when to stop testing.
Keeping a continuous eye on every test activity and measuring how actual progress compares with the plan. The information it gathers is what test control uses to make decisions.
In plain English: Watching testing progress and comparing it with the plan.
Example: Each morning the team checks how many planned tests have run, how many passed and how many defects are open.
Whatever is being tested at the moment: a component, a group of integrated components, a whole system, or a document such as a specification under review.
In plain English: The thing that we are testing.
Example: In a component test the test object might be the currency conversion module, version 2.3.
The reason a particular piece of testing is done, such as finding defects, building confidence, reducing risk, checking requirements are met or giving stakeholders information for decisions. Objectives change with context.
In plain English: The goal of the testing: what we want the testing to achieve.
Example: For a release candidate the objective may be confidence for go-live; for a new component it may be finding as many defects as possible.
Whatever a tester relies on to know the correct outcome of a test, so the actual result can be judged. It might be a specification, a legacy system, a hand calculation or an expert user.
In plain English: A way to know what the right answer should be.
Example: A spreadsheet with the official tax tables is used to check every result produced by new payroll software.
The document that sets out how testing for a project or level will be organized: what it aims to achieve, scope, approach, resources, schedule, risks, roles and entry and exit criteria. Writing it forces early thinking.
In plain English: A document that says what testing will happen, how, who does it and when.
Example: The release test plan names the test levels, the environments, the exit criteria and the main risks for the team.
Deciding what the testing should achieve and choosing the most suitable way to get there, given the time, budget, people and other limits of the project. Its main output is the test plan.
In plain English: Deciding what testing to do, how, who, and when.
Example: At the start of a release, the test manager agrees scope, techniques, environments and exit criteria with the team.
The running order for a group of test cases, including any steps to prepare the starting conditions beforehand and to clean up afterwards.
In plain English: The list of tests and steps in the order we will run them.
Example: Log in, create an order, edit the order, cancel it, then log out and check the cancellation email.
A report produced regularly while testing is under way, used for test control. It covers progress against plan, blockers, key metrics, new or changed risks and what is planned next.
In plain English: A regular update that shows how testing is going right now.
Example: A weekly report shows 70% of tests run, 12 defects open, one blocked environment and next week’s focus on payments.
A model showing that tests have different granularity: many small, fast, isolated tests at the bottom (such as component tests) and fewer large, slow, end-to-end tests at the top. It guides automation effort.
In plain English: A picture showing many small fast tests at the bottom and few big slow tests at the top.
Example: A team has 2,000 unit tests, 300 API tests and 40 end-to-end UI tests, matching the pyramid shape.
The outcome of running a test, such as passed, failed or blocked, decided by comparing the actual behavior with the expected result.
In plain English: Whether a test passed, failed or could not be run.
Example: The expected total was $110 but the actual total was $108, so the test result is “failed”.
A systematic way to decide what to test and how, helping testers define test conditions, coverage items and test data. Techniques are black-box, white-box or experience-based.
In plain English: A method that helps testers choose good tests.
Example: Using boundary value analysis instead of picking random ages gives a small, effective set of tests for an age field.
Software that supports one or more test activities, such as test management, static testing, test design and implementation, test execution and coverage, non-functional testing, DevOps pipelines or collaboration.
In plain English: A software program that helps testers do their work.
Example: A defect tracker, a static analysis tool and a load testing tool are all test tools.
A family of test activities aimed at a particular quality characteristic or viewpoint: functional, non-functional, black-box or white-box. Test types are not tied to one level; most can be used at every level.
In plain English: A kind of testing, grouped by what it checks.
Example: Performance testing is a non-functional test type that can be done on a component and also on the full system.
A test-first practice, often called TDD, where a developer writes a small automated component test, writes just enough code to pass it, then refactors, repeating in short cycles.
In plain English: Developers write a small test first, then write code until the test passes.
Example: Before coding a password strength function, the developer writes a test expecting “abc” to be rejected, sees it fail, then codes the rule.
Everything testers do, with or without running the software, to uncover defects and to judge how good a product and its related documents are. Running tests is only one part of it.
In plain English: Work that checks software and its documents to find problems and judge quality.
Example: Reviewing a requirements document, writing test cases and running them against a new login page are all parts of testing.
A testing principle. No single approach suits every project; the right way to test depends on the domain, the risks, the lifecycle model, regulations, time and budget.
In plain English: How we test depends on the type of product and project.
Example: Medical device software needs formal, documented testing, while a small marketing website may rely mainly on quick exploratory checks.
A model that groups test types into four quadrants by whether they are business-facing or technology-facing, and whether they support the team or critique the product. It helps make sure all needed test types are considered.
In plain English: A four-box model to make sure the team uses all the needed kinds of testing.
Example: Component tests sit in Q1, story tests in Q2, exploratory and usability tests in Q3, performance and security tests in Q4.
The hands-on, technical side of testing: analysing the test basis, designing tests, preparing them and running them. Testers, developers or business people may hold this role depending on the team.
In plain English: The person who analyzes, designs, prepares and runs the tests.
Example: In an Agile team, a developer may take the testing role for component tests while a tester does it for system tests.
The first testing principle. A failing test proves a defect exists, but passing tests never prove the software is defect free; they only make it less likely that serious defects remain hidden.
In plain English: Tests can find problems, but they cannot prove there are no problems.
Example: After 500 passing tests the team still cannot claim the app is defect free, only that those tests found nothing.
A testing principle, also known as the pesticide paradox. Rerunning an unchanged set of tests finds fewer and fewer new defects, so tests and test data need refreshing. Automated regression testing benefits from repetition, so it is the exception.
In plain English: Old tests find fewer new problems, so we must update tests or add new ones.
Example: A regression suite has not found a new defect in a year, so the team adds tests for recent features and new data.
All the work products created by test activities, such as test plans, test conditions, test cases, scripts, test data, environment setups, logs and reports. Good testware needs configuration management.
In plain English: All the documents, data and tools that testing creates.
Example: The regression scripts, the test data files and last release’s test completion report are all testware.
An expert-based estimation technique using an optimistic (a), most likely (m) and pessimistic (b) estimate. The final estimate is E = (a + 4m + b) / 6, and the standard deviation is (b − a) / 6.
In plain English: Make a best, a likely and a worst guess, then combine them with a formula.
Example: With a = 6, m = 9 and b = 18 days: E = (6 + 36 + 18) / 6 = 10 days; standard deviation = 2 days.
Two-way links connecting the test basis to test conditions, test cases, test results and defects. They let the team measure coverage, judge the impact of a change, pass audits and report in business terms.
In plain English: Links that show which tests check which requirements and which defects they found.
Example: Requirement R-12 links to test cases TC-40 to TC-45; when R-12 changes, the team knows exactly which tests to update.
A short description of a feature from the viewpoint of a user, with three parts: a card, the conversation that clarifies it and the confirmation, its acceptance criteria. Good stories meet the INVEST qualities.
In plain English: A short sentence about what a user wants and why.
Example: As a library member, I want to renew a book online so that I don’t have to visit the library.
A state transition coverage criterion requiring tests to exercise every valid transition in the model. Also called 0-switch coverage. Full valid transitions coverage also guarantees all states are visited.
In plain English: Our tests must use every allowed move between states at least once.
Example: A document workflow has five allowed moves (draft to review, review to approved, and so on); tests use all five.
Checking whether the system actually meets the needs of its users and other stakeholders in its real operating environment. The question being asked is: did we build the right thing?
In plain English: Checking that the product really helps the users do what they need.
Example: Nurses try a new ward app during a real shift to see if it truly supports their daily work.
Checking whether a work product meets the requirements and specifications written for it. The question being asked is: did we build the thing as specified?
In plain English: Checking that the product matches what was written in the specification.
Example: Comparing a payment screen with its specification to confirm every required field and rule is present.
A review in which the author leads the participants through the work product. It can serve several goals: teaching reviewers, building agreement, collecting ideas, encouraging the author and finding anomalies.
In plain English: The author explains their work to others, who ask questions and give ideas.
Example: A business analyst presents a new process model to the team page by page and collects questions and suggestions.
A test technique that derives tests from the internal structure of the test object, such as its code and control flow. Since tests follow the design, they can only be written once the design or code exists.
In plain English: A way to design tests by looking at the code.
Example: Statement testing and branch testing are white-box techniques used to make sure code paths are exercised.
Testing based on the internal structure of the system, such as code, architecture or data flows. Its main aim is to cover that structure to an acceptable level.
In plain English: Testing based on how the code is built inside.
Example: A developer adds tests until every branch of the discount function’s if-statements has been executed.
A team practice in which people pick up any task they have the skills for, and quality belongs to everyone rather than only to testers. Testers, developers and business representatives work side by side.
In plain English: Everyone in the team is responsible for quality, not only the testers.
Example: Developers, the product owner and a tester write acceptance tests for a story together in a short meeting.
An expert-based estimation technique: experts estimate on their own, the results are compared, people with very different estimates explain their reasoning, and rounds repeat until the group reaches consensus. Planning Poker is a variant.
In plain English: Experts estimate alone, discuss the differences, and repeat until they agree.
Example: Three testers estimate 5, 8 and 20 days; the outliers explain, and the second round gives 8, 9 and 10.
No terms match your search.
Practice on the real exam screen with full CTFL 4.0 practice exams, or try free sample questions first.
Definitions are xSTELLAR8’s own explanations of the CTFL v4.0 terms, not the official ISTQB® Glossary. ISTQB® is a registered trademark of the International Software Testing Qualifications Board.