Software acceptance testing glossary
Software acceptance testing (« recette » in French) is the phase in which the client verifies that delivered software matches the specification before accepting it. Here are the terms you meet there, defined simply.
Terms from A to Z
- Defect
- A gap observed between the actual behaviour of software and the expected behaviour. A defect is described by its reproduction steps, its severity and its status (open, fixed, to retest, closed). Also called a bug or an issue.
- Acceptance test book (cahier de recette)
- Document that lists the test cases to run in order to accept software, with the steps, data and expected result of each. See the acceptance test book guide.
- Test campaign
- Planned execution of a set of test cases on a given version of the software, by one or more people, over a defined period. Each case receives a status at the end of the campaign.
- Test case
- A single check described by preconditions, steps and an expected result. A test case verifies one precise intent, for example the rejection of a wrong password.
- Acceptance criterion
- A measurable condition that a feature must meet to be accepted by the client. Acceptance criteria are the natural source of test cases.
- Acceptance environment
- An instance of the software, separate from production, in which acceptance testing is carried out. It must resemble production so that the results are representative.
- Requirement
- A need that a specification places on the software, for example « a wrong password is rejected ». A testable requirement is verified by an observable result.
- Defect severity
- Level of impact of a defect on the use of the software: blocking (use impossible), major, minor. Not to be confused with fix priority, which also depends on the schedule and context.
- Test data set
- A set of values and initial states (accounts, products, rights) needed to run a test case in a reproducible way.
- MOA (project owner, client side)
- The client, who carries the need and validates the delivery. In acceptance testing, the MOA runs or has run the business tests and signs the report.
- MOE (contractor, provider side)
- The provider that designs and builds the software. In acceptance testing, the MOE delivers the version, fixes the defects and tracks progress.
- Coverage matrix
- A table that links each requirement to the test cases that verify it. It shows the requirements that are not covered. Also called a traceability matrix.
- Regression test
- A test replayed after a change to check that existing functions have not been degraded.
- Test plan
- Strategy document: scope, types of tests, environments, resources and schedule. The acceptance test book details its execution.
- Acceptance report (PV de recette)
- Report signed by the client and the provider that records the outcome of the acceptance testing and pronounces acceptance, acceptance with reservations or rejection. See the acceptance report guide.
- Acceptance testing (recette)
- Phase of verification of delivered software against the specification, which ends in its acceptance or rejection.
- Functional acceptance testing
- Acceptance testing that verifies that the functions of the software behave as the specification describes, from the user's point of view. It differs from performance or security testing.
- User acceptance testing (UAT)
- Acceptance testing carried out by the client's business users in realistic conditions. UAT stands for « User Acceptance Testing ».
- Reservation
- A defect or gap that the client agrees to see fixed after acceptance. It appears in the report with its fix deadline, then is lifted once fixed and retested.
- Expected result
- Observable behaviour that validates a test case. It must be precise enough for two testers to reach the same conclusion.
- Smoke test
- A short series of tests that checks that the essential functions work before launching a full acceptance round on a version.
- Execution statuses (OK, KO, Blocked, N/A)
- OK: result as expected. KO: gap observed, a defect is opened. Blocked: the case cannot be executed. N/A: the case does not apply to this scope.
- VABF (verification of suitability for correct operation)
- A verification stage, provided for in some contracts (notably French public IT contracts), that checks that the delivered system works as expected.
- VSR (verification of regular service)
- The stage that follows the VABF in some contracts: the system is observed over time, under real operating conditions, before final acceptance.
- Delivered version
- The precise version of the software handed over for acceptance. The test book and the report must state it so that it is clear what was verified.