Glossary

Study as flashcards →

90 terms

Acceptance criteria: The conditions a user story or feature must satisfy to be accepted by stakeholders, often used as a test basis in Agile.
Acceptance test-driven development (ATDD): A test-first approach in which acceptance tests are derived collaboratively from acceptance criteria before development and then drive it.
Acceptance testing: Testing to establish whether a system satisfies acceptance criteria and is ready for deployment, typically focusing on validation.
Alpha testing: Acceptance testing performed by roles outside the development team, at the developing organization's own site.
Anomaly: Any condition that deviates from expectation; in reviews, a potential defect found in the work product.
Behavior-driven development (BDD): A test-first approach expressing desired behavior as natural-language scenarios (e.g. Given/When/Then) that can be automated.
Beta testing: Acceptance testing performed by potential or existing customers at their own locations before general release.
Black-box test technique: A test technique based on an analysis of the specified behavior of the test object, without reference to its internal structure.
Boundary value analysis: A black-box technique that tests the minimum and maximum values of ordered equivalence partitions, where defects are most likely.
Branch coverage: The percentage of decision outcomes (branches) exercised by a test suite; 100% branch coverage implies 100% statement coverage.
Checklist-based testing: An experience-based technique in which tests are designed and executed using a checklist of conditions to remember or verify.
Component testing: Testing of individual hardware or software components in isolation; also called unit or module testing.
Configuration management: The discipline of uniquely identifying, version controlling, and tracking changes to work products so it is always clear what was tested with what.
Confirmation testing: Re-testing performed after a defect fix to confirm that the original failure no longer occurs.
Continuous delivery: Extending continuous integration so every change that passes the pipeline can be released to production at any time.
Continuous integration: Automatically building and testing software on every merged change, giving developers fast feedback on integration problems.
Coverage: The degree to which identified coverage items (e.g. requirements, partitions, branches) have been exercised by a test suite, usually as a percentage.
Debugging: The development activity of reproducing a failure, finding its cause, and fixing the underlying defect.
Decision table testing: A black-box technique that models combinations of conditions and resulting actions in a table, with each column forming a test case.
Defect: An imperfection or flaw in a work product that can cause it to fail to meet its requirements; also called fault or bug.
Defect density: The number of defects per unit size of a work product (e.g. per thousand lines of code), used to compare quality across components.
Defect management: The process of recognizing, recording, classifying, investigating, resolving, and closing defects.
Defect report: Documentation of a failure or anomaly, including the information needed to reproduce, analyze, and resolve it.
Definition of done: The agreed set of conditions a work item must satisfy to be considered complete; the Agile equivalent of exit criteria.
DevOps: An organizational approach uniting development and operations with shared goals, automation, and a CI/CD delivery pipeline.
Driver: A software component or tool that replaces a calling component, invoking the test object so it can be tested in isolation.
Dynamic testing: Testing that involves executing the test object with test data.
Entry criteria: The preconditions that must be fulfilled before a test activity can start, also called definition of ready in Agile contexts.
Equivalence partitioning: A black-box technique that divides data into partitions expected to be processed the same way, testing one value per partition.
Error: A human action or mistake that produces an incorrect result, e.g. a misunderstanding that leads to faulty code.
Error guessing: An experience-based technique that anticipates likely errors, defects, and failures based on the tester's knowledge and past experience.
Exit criteria: The set of conditions that must be met before testing can be declared complete, also called definition of done in Agile contexts.
Exploratory testing: An experience-based approach in which testers simultaneously learn about the product, design tests, execute them, and evaluate results.
Failure: An event in which a component or system does not behave as expected during operation.
Fault attack: A structured form of error guessing: designing tests from a list of anticipated errors, defects, and failures to deliberately provoke each one.
Functional testing: Testing what the system should do: evaluating its functions against the specified or implied behavior.
Impact analysis: Identifying the areas affected by a change, including intended consequences and side effects, to scope maintenance and regression testing.
Inspection: The most formal review type, following a defined process with trained roles, rules, and metrics, aimed at finding the maximum number of anomalies.
Integration testing: Testing focused on the interactions and interfaces between components or between systems.
Maintenance testing: Testing changes made to an operational system, including the impact of those changes on the rest of the system.
Non-functional testing: Testing how well the system behaves: evaluating quality characteristics such as performance, usability, security, and reliability.
Operational acceptance testing: Acceptance testing by operations or administration staff, covering aspects like backup/restore, monitoring, and recovery.
Product risk: A risk that the delivered product fails to satisfy users or stakeholders, e.g. missing functionality or poor performance.
Project risk: A risk that threatens the project's ability to deliver, e.g. schedule slips, skill shortages, or supplier issues.
Quality: The degree to which a work product satisfies stated and implied needs of its stakeholders.
Quality assurance: A process-oriented, preventive approach to quality: confidence that quality requirements will be fulfilled by following good processes.
Quality control: A product-oriented, corrective approach focused on achieving appropriate quality levels; testing is a major form of it.
Regression testing: Testing performed to detect unintended side effects of a change in unchanged areas of the software.
Retrospective: A recurring meeting at the end of an iteration or release where the team reflects on what went well and what to improve.
Review: A static testing technique in which a work product is evaluated by people, ranging from informal to formal (e.g. walkthrough, technical review, inspection).
Risk analysis: Identifying risks and assessing their likelihood and impact to determine each risk's level and appropriate responses.
Risk level: The importance of a risk, determined by the likelihood of the adverse event and the impact if it occurs.
Risk-based testing: An approach in which the choice, prioritization, and depth of test activities are driven by an analysis of product risks.
Root cause: The earliest underlying source of a defect; removing it prevents similar defects from recurring.
Session-based test management: A way to structure exploratory testing using charters, time-boxed sessions, session logs, and debriefings.
Shift left: Performing testing and quality activities earlier in the software development lifecycle, following the early-testing principle.
State transition testing: A black-box technique that exercises the valid and invalid transitions between states of the test object.
Statement coverage: The percentage of executable statements exercised by a test suite, used as a white-box coverage measure.
Static analysis: Tool-based evaluation of code or other work products without executing them, finding e.g. code smells and security weaknesses.
Static testing: Testing that evaluates work products without executing them, e.g. reviews and static analysis.
Stub: A skeletal or special-purpose replacement for a component that the test object calls, used to isolate it during testing.
System testing: Testing the behavior and capabilities of a whole integrated system, often against system requirements, in a representative environment.
Test automation: The use of software tools to perform or support test activities, such as test execution and results checking.
Test basis: The body of knowledge (e.g. requirements, design documents, user stories) used as the basis for test analysis and design.
Test case: A set of preconditions, inputs, actions, expected results, and postconditions developed to verify one or more test conditions.
Test charter: A brief statement of the goal and scope of a time-boxed exploratory testing session, used in session-based testing.
Test completion report: A summary of a completed stage of testing, including an evaluation against exit criteria and lessons learned.
Test condition: A testable aspect of the test object, such as a function, transaction, feature, or quality attribute, identified during test analysis.
Test control: Taking corrective actions based on test monitoring results to keep testing on track, e.g. reprioritizing tests or adjusting the schedule.
Test harness: A test environment of stubs, drivers, and supporting tools needed to execute tests against a component or system.
Test level: A group of test activities organized and managed together, e.g. component, integration, system, and acceptance testing.
Test monitoring: Continuously checking test progress and comparing actual status against the plan using metrics.
Test object: The component or system that is being tested.
Test objective: A reason or purpose for testing, such as finding defects, building confidence, or providing information for decisions.
Test plan: Documentation describing the objectives, scope, approach, resources, and schedule of intended test activities.
Test procedure: A sequence of test cases in execution order together with the actions needed to set up the preconditions and wrap up afterwards.
Test progress report: A regular report during testing that communicates status against plan, blockers, new risks, and upcoming work to support control.
Test pyramid: A model showing that lower test levels (e.g. unit tests) should have many fast, isolated tests, with fewer slower tests at higher levels.
Test script: A sequence of instructions for executing a test — manual steps or an automated script run by a tool.
Test suite: A set of test cases or test procedures grouped to be executed together in a specific test run or cycle.
Test type: A group of test activities based on specific test objectives, e.g. functional, non-functional, black-box, and white-box testing.
Test-driven development (TDD): A test-first approach in which a failing test is written before the code, followed by minimal implementation and refactoring.
Testing: The set of activities to discover defects and evaluate the quality of software work products.
Testing quadrants: A model grouping test types by whether they are business- or technology-facing and whether they support the team or critique the product.
Testware: Work products produced during the test process, such as test plans, test cases, test data, test scripts, and reports.
Traceability: The ability to relate items in test documentation to each other and to the test basis, e.g. linking test cases to requirements.
User acceptance testing (UAT): Acceptance testing by intended users in a realistic environment, focusing on fitness for use to accomplish their tasks.
User story: A short description of a feature from a user's perspective, consisting of card, conversation, and confirmation (acceptance criteria).
Walkthrough: A review type led by the author of the work product, often used to establish a common understanding and gather feedback.
White-box test technique: A test technique based on an analysis of the internal structure and processing of the test object, e.g. statement or branch testing.