Glossar
Als Karteikarten üben →Fragen und Glossar derzeit auf Englisch; deutsche Inhalte folgen.
66 Begriffe
- Ad hoc reviewing Kap. 5
- 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 Kap. 4
- 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 Kap. 3
- 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 Kap. 5
- 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 Kap. 3
- 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 Kap. 3
- A data-based black-box technique that focuses on the interactions of multiple parameters within a multidimensional domain.
- Compatibility Kap. 4
- 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 Kap. 3
- An experience-based approach in which a large, distributed group of testers exercises the test object under diverse real-world conditions.
- CRUD testing Kap. 3
- 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 Kap. 3
- 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 Kap. 3
- A rule-based technique that derives test cases from combinations of conditions and their resulting actions captured in a decision table.
- Defect classification Kap. 5
- 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 Kap. 5
- 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 Kap. 3
- 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 Kap. 3
- 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 Kap. 3
- 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 Kap. 4
- 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 Kap. 4
- The degree to which the implemented functions facilitate accomplishing the users' specified tasks and objectives.
- Functional completeness Kap. 4
- The degree to which the set of functions covers all specified tasks and intended user objectives — whether everything requested is implemented.
- Functional correctness Kap. 4
- The degree to which a system produces correct results — accurate, precise, and consistent — for valid and invalid inputs.
- Functional suitability Kap. 4
- 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 Kap. 4
- 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 Kap. 1
- An abstract (logical) test case that indicates which test conditions are covered without specifying concrete preconditions, input data, expected results, or postconditions.
- Impact analysis Kap. 2
- 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 Kap. 4
- 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 Kap. 4
- 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 Kap. 4
- 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 Kap. 1
- 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 Kap. 1
- A concrete (physical) test case that specifies the actual preconditions, input data, expected results, and postconditions needed to execute it.
- Metamorphic relation Kap. 3
- 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 Kap. 3
- 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 Kap. 5
- 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 Kap. 5
- 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 Kap. 5
- Detecting and removing defects in the same phase of the SDLC in which they were introduced, reducing the cost of quality.
- Product risk Kap. 2
- A risk that the test object may fail to satisfy stakeholders' needs, with a probability of occurrence and an associated impact.
- Random testing Kap. 3
- A data-based technique that selects random inputs from the domain according to a specified probability distribution.
- Regression testing Kap. 2
- 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 Kap. 5
- 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 Kap. 2
- 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 Kap. 2
- 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 Kap. 2
- 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 Kap. 2
- The process of finding and documenting product risks by drawing on experience, knowledge, retrospectives, risk workshops, brainstorming, checklists, and stakeholder interviews.
- Risk mitigation Kap. 2
- 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 Kap. 2
- 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 Kap. 2
- 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 Kap. 5
- 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 Kap. 5
- 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 Kap. 3
- 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 Kap. 5
- 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 Kap. 3
- A behavior-based technique that derives test cases from sequences of actions representing realistic use of the test object.
- Session-based testing Kap. 3
- An experience-based, time-boxed approach to exploratory testing guided by a test charter.
- State transition testing Kap. 3
- A behavior-based technique for stateful systems that models states, events, and transitions to derive test cases.
- Test analysis Kap. 1
- 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 Kap. 1
- 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 Kap. 3
- 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 Kap. 1
- 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 Kap. 1
- 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 Kap. 1
- 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 Kap. 1
- 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 Kap. 1
- 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 Kap. 1
- 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 Kap. 5
- 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 Kap. 1
- The work products produced and managed for testing, such as test conditions, test cases, test procedures, test scripts, test data, and test suites.
- Usability Kap. 4
- 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 Kap. 4
- Testing that evaluates interaction capability, user experience, and accessibility so that users can complete tasks effectively, efficiently, and satisfactorily.
- User experience Kap. 4
- The users' perceptions and responses before, during, and after interacting with a product; assessed alongside interaction capability and accessibility in usability testing.