QA glossary: software testing terms explained

The pass-or-fail conditions a feature must meet before it counts as done, written before development starts.

A test design technique that picks inputs at the edges of an allowed range, where defects cluster.

The regular review that decides which new bug reports are real, how serious they are and who fixes them when.

Re-running a test after a bug fix to check that the original defect is really gone.

The total spent because software can have defects: preventing, finding, fixing before release and dealing with them after.

Checking that a site works the same on the browsers, devices and screen sizes your users actually have.

A change over time in the live data a machine learning model receives, away from the data it was trained on.

Testers from an outside QA company assigned full-time to one product, working in its sprints and tools.

Confirmed defects per thousand lines of code, used to compare the quality of modules or releases of different sizes.

The share of defects that testing missed and a user or the live system found after release.

An automated test that passes and fails on the same code, so its result cannot be trusted.

Wrong information that an LLM produces and presents as fact, such as a made-up feature or a test for a rule that does not exist.

Software that uses an LLM to decide the next step and then acts on it by calling tools, such as a browser or a test runner.

Checking how outputs should change when the input changes in a known way, used when no exact expected result exists.

When a system can give different outputs for the same input, as AI systems and LLMs do, so one test run proves little.

Checking that a system can be run, supported and recovered in production: backups, failover, monitoring and upgrades.

Quality assurance prevents defects by improving the process; quality control finds them in the finished product.

Attacking an AI system on purpose to make it produce harmful or unwanted output, so the weakness is fixed before users find it.

The go or no-go call on whether a release is safe to ship, made from test results and open defects.

How much of the code, the requirements or the risks the tests have actually exercised.

The supporting code and setup that runs tests, stands in for outside services and records the results.

Whatever tells a tester what the right result should be: a specification, an older system, a calculation or an expert.

A group of test cases run together to check one area of a product or one kind of risk.

Testing done by a team that did not write the code and does not report to the people who did.

A table that maps every requirement to the tests that verify it and the bugs found against it.