Glossary

Study as flashcards →

66 terms

Ad hoc reviewing: A review technique carried out informally without a structured process, where reviewers read the work product and document anomalies as they encounter them; highly dependent on reviewer skills.
Adaptability: A sub-characteristic of flexibility representing the degree to which a product can be effectively adapted for or transferred to different hardware, software, or other operational or usage environments.
Behavior-based test technique: A category of black-box test techniques that derive test cases from the dynamic, state-dependent behavior of the test item, including CRUD testing, state transition testing, and scenario-based testing.
Checklist-based reviewing: A review technique in which the test basis is evaluated against a predefined checklist that may be generic or tailored to specific quality characteristics, risk levels, or test objectives; the checklist should be regularly updated.
Checklist-based testing: An experience-based test technique in which the test analyst uses a predefined checklist to guide and structure testing; checklists may take a read-do form (concrete items) or a do-confirm form (thought-process prompts).
Combinatorial testing: A data-based black-box technique that focuses on the interactions of multiple parameters within a multidimensional domain.
Compatibility: A quality characteristic evaluating whether a product can share a target environment and exchange information with other products or systems; its sub-characteristics are interoperability and coexistence.
Crowd testing: An experience-based approach in which a large, distributed group of testers exercises the test object under diverse real-world conditions.
CRUD testing: A behavior-based technique that verifies the create, read, update, and delete lifecycle of data entities, often organized with a CRUD matrix.
Data-based test technique: A category of black-box test techniques that derive test cases from the data domain of the test item, including domain testing, combinatorial testing, and random testing.
Decision table testing: A rule-based technique that derives test cases from combinations of conditions and their resulting actions captured in a decision table.
Defect classification: Assigning defects to standardized categories (e.g. orthogonal defect classification, IEEE 1044, or severity) so that defect data becomes a process measurement supporting root cause analysis.
Defect prevention: Practices — such as reviews, risk analysis, retrospectives, and defect-data analysis — that stop defects from being introduced or from escaping to later phases.
Domain testing: A data-based black-box technique that extends equivalence partitioning and boundary value analysis to multi-parameter domains, using ON, OFF, IN, and OUT points.
Equivalence partition: A portion of the input domain in which the test item is expected to behave equivalently; in domain testing, partitions are defined using expressions that combine atomic conditions with Boolean operators, each condition forming a border.
Experience-based testing: A category of test techniques that leverage the tester's expertise, intuition, and past experience to guide testing, including session-based testing, checklist-based testing, and crowd testing.
Flexibility: A quality characteristic addressed by flexibility testing (also known as portability testing), covering adaptation to changes in contexts of use or system environment; its sub-characteristics are adaptability, scalability, installability, and replaceability.
Functional appropriateness: The degree to which the implemented functions facilitate accomplishing the users' specified tasks and objectives.
Functional completeness: The degree to which the set of functions covers all specified tasks and intended user objectives — whether everything requested is implemented.
Functional correctness: The degree to which a system produces correct results — accurate, precise, and consistent — for valid and invalid inputs.
Functional suitability: A quality characteristic representing the degree to which a product provides functions that meet stated and implied needs when used under specified conditions; its sub-characteristics are functional completeness, correctness, and appropriateness.
Functional testing: A test type that evaluates the functions a system should perform, focusing on functional suitability and its sub-characteristics: completeness, correctness, and appropriateness.
High-level test case: An abstract (logical) test case that indicates which test conditions are covered without specifying concrete preconditions, input data, expected results, or postconditions.
Impact analysis: Analysis of the effects of a change in order to determine the scope of regression testing by identifying which areas and tests are affected.
Installability: A sub-characteristic of flexibility representing the degree to which a product can be successfully installed, uninstalled, updated, and reconfigured in specified environments.
Interaction capability: A quality characteristic (formerly called usability in ISO 25010) that evaluates whether users can complete tasks in specific contexts of use effectively, efficiently, and satisfactorily.
Interoperability: A sub-characteristic of compatibility representing the degree to which two or more components or systems can exchange information and mutually use the information that has been exchanged.
Keyword-driven testing: A scripting technique in which test scripts are written using keywords: action keywords that interact with the system and verification keywords that assert results.
Low-level test case: A concrete (physical) test case that specifies the actual preconditions, input data, expected results, and postconditions needed to execute it.
Metamorphic relation: A property of a test item that describes how a defined change in a test case's inputs should be reflected in the expected results; used to generate follow-up test cases from a source test case in metamorphic testing.
Metamorphic testing: A rule-based technique that checks metamorphic relations between the outputs of related inputs, useful when an explicit test oracle is hard to obtain.
Model-based testing: A test approach in which an MBT tool designs and generates test cases based on a model and test selection criteria defined by the test analyst; effective for detecting anomalies through comprehensive coverage and systematic behavior exploration.
Perspective-based reading: A review technique in which reviewers examine the test basis from various viewpoints (e.g., designer, tester, end user) and attempt to use it to generate the work product they would derive from it, yielding in-depth reviewing with less duplication.
Phase containment: Detecting and removing defects in the same phase of the SDLC in which they were introduced, reducing the cost of quality.
Product risk: A risk that the test object may fail to satisfy stakeholders' needs, with a probability of occurrence and an associated impact.
Random testing: A data-based technique that selects random inputs from the domain according to a specified probability distribution.
Regression testing: Testing performed after a change to provide confidence in the quality of the changed test object; its scope is reviewed for every test cycle.
Review technique: A structured method used during individual review to identify defects in work products; selecting the most appropriate technique enhances review efficiency and effectiveness.
Risk analysis: The overall process of risk identification and risk assessment, used to determine the risk levels of test items so that testing can be prioritized accordingly.
Risk assessment: The process of estimating the risk level of each identified product risk by evaluating factors such as frequency of use, criticality of affected features and business objectives, potential damage, quality of the test basis, and legal or safety needs.
Risk control: The set of actions taken to reduce or manage identified product risks, encompassing risk mitigation (e.g., reviews, applying appropriate test techniques and coverage levels) and risk monitoring.
Risk identification: The process of finding and documenting product risks by drawing on experience, knowledge, retrospectives, risk workshops, brainstorming, checklists, and stakeholder interviews.
Risk mitigation: Actions aimed at reducing the probability or impact of a product risk, including performing reviews, selecting appropriate test techniques and coverage levels, applying proper test types, and performing regression testing.
Risk monitoring: The ongoing activity of tracking changes to risk levels over time, updating the risk register, and adjusting risk mitigation actions accordingly; in iterative lifecycles this is typically performed once per iteration.
Risk-based testing: A test approach that prioritizes test effort according to the risk levels of the test items; it involves risk analysis and risk control.
Role-based reviewing: A review technique in which reviewers are assigned specific roles or personas (e.g., experienced user, administrator) to focus on aspects of the test basis relevant to that role, ensuring comprehensive coverage while avoiding duplication.
Root cause analysis: A technique for identifying and addressing the fundamental causes of defects rather than their symptoms, with the goal of preventing recurrence.
Rule-based test technique: A category of black-box test techniques that verify the implementation of static behavior rules valid regardless of the test item's state, including decision table testing and metamorphic testing.
Scenario-based reviewing: A review technique that simulates a process or activity to identify anomalies in the test basis; most effective when the test basis uses a scenario format such as use cases or activity diagrams, allowing dry runs.
Scenario-based testing: A behavior-based technique that derives test cases from sequences of actions representing realistic use of the test object.
Session-based testing: An experience-based, time-boxed approach to exploratory testing guided by a test charter.
State transition testing: A behavior-based technique for stateful systems that models states, events, and transitions to derive test cases.
Test analysis: The test activity in which the test analyst checks the test basis for completeness and testability, identifies and prioritizes test conditions, and determines test oracles needed for dynamic testing.
Test analyst: A testing role responsible for testing the software's business aspects, focusing on functional suitability and user-facing quality characteristics such as usability, adaptability, installability, and interoperability.
Test charter: A document that provides the mission, scope, objectives, and guiding information for a session-based test session; a popular format is 'Explore [target] With [resources] To discover [information].'
Test condition: A testable aspect of a test item that is relevant to achieving a test objective and serves as a basis for designing test cases. Test conditions are derived from the test basis and prioritized considering product risks.
Test data: The input values, environment configurations, preconditions, and expected results needed for test execution. Test data may be production-based or synthetic, and must consider similarity with production data, confidentiality, coverage criteria, and traceability.
Test design: The test activity in which the test analyst determines how testing should be performed, designing high-level or low-level test cases with clear pass/fail criteria based on the identified test conditions.
Test environment: The infrastructure of hardware, middleware, software, network, tools, and configurations required to execute tests. A test case that passes or fails in the test environment should produce the same result in production.
Test oracle: A source used to determine the expected results of dynamic testing; it may come from the test basis, a model, a property, another system, or human knowledge.
Test oracle problem: The situation in which a cost-effective test oracle is not available, for example due to data complexity, non-determinism, probabilistic behavior, or missing or ambiguous requirements.
Test result: The outcome of test execution that records whether a test passed or failed, providing feedback for identifying failures, evaluating defect detection effectiveness, and supporting root cause analysis.
Testware: The work products produced and managed for testing, such as test conditions, test cases, test procedures, test scripts, test data, and test suites.
Usability: A broad concept of user-related quality characteristics covering interaction capability from the ISO 25010 product quality model and beneficialness from the quality-in-use model.
Usability testing: Testing that evaluates interaction capability, user experience, and accessibility so that users can complete tasks effectively, efficiently, and satisfactorily.
User experience: The users' perceptions and responses before, during, and after interacting with a product; assessed alongside interaction capability and accessibility in usability testing.