ISTQB-ATM Definitions Flashcards
Exit criteria
The set of generic and specific conditions, agreed upon with the stakeholders, for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing.
Test case
A set of input values, execution preconditions, expected results, and execution postconditions, developed for a particular objective or test condition, such as t o exercise a particular program path or to verify compliance with a specific requirement.
Test closure
During the test closure phase of a test process data is collected from completed activities t o consolidate experience, testware, facts, and numbers. The test closure phase consists of finalizing and archiving the testware and evaluating the test process, including preparation of a test evaluation report.
Test condition
Created during test analysis, test conditions define “what” is to be tested, based on an analysis of the test basis, test objectives, and product risks. They can be viewed as the detailed measures and targets for success (e.g., part of exit criteria). A test condition should be traceable back to the test basis and strategic objectives and traceable forward to test designs and other test work products.
Test control
A test management task that deals with developing and applying a set of corrective actions to get a test project on track when monitoring shows a deviation from what was planned.
Test design
This is the “how” something is to be tested – identify test cases based on identified test conditions using test techniques set out by test plan and/or test strategy.
Test execution
The group of activities in the test process in which tests are actually run. Tests are executed in accordance with test cases following the test execution schedule. Failures are investigated and defects reported while test results tracking, including metrics tracking, will be collected for monitoring, control, and reporting by the Test Manager.
Test implementation
Test implementation is the activity during which tests are organized and prioritized as concrete test cases, test procedures, and test data. Commonly, each test’s inputs, expected results, and test steps are documented together in a test case. Test implementation includes the creation of stored test data.
Test log
A chronological record of relevant details about the execution of tests.
Test planning
The activity of establishing or updating a test plan.
Test procedure
A document specifying a sequence of actions for the execution of a test. Also known as a test script or manual test script.
Test script
Commonly used to refer to a test procedure specification, especially an automated one.
Test summary report
A document summarizing the testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria.
Level test plan
1 - Level test plans describe the particular activities to be carried out within each test level or, in some cases, test type.
2 - Level test plans expand, where necessary, on the master test plan for the specific level or test type being documented.
3 - They provide schedule, task, and milestone details not necessarily covered in the master test plan.
4 - In addition, to the extent that different standards and templates apply to specification of tests at different levels, these details would be covered in level test plans.
Master test plan
1 - The master test plan covers all of the testing work to be done on a particular project, including the particular levels to be carried out and the relationships among those levels, and between test levels and corresponding development activities.
2 - The master test plan should discuss how the testers will implement the test strategy for this project (i.e., the test approach).
3 - The master test plan should be consistent with the test policy and strategy, and, in specific areas where it is not, should explain those deviations and exceptions, including any potential impact resulting from the deviations.
Product risk
Risk where the primary effect of the potential problem is on product quality (including totality of features, behaviours, characteristics, and attributes that affect customer, user, and stakeholder satisfaction).
Project risk
Risk where the primary effect of the potential problem is on project success (meeting objectives, schedules, budget, etc.).
Risk analysis
[also see Risk identification] In risk-based testing, quality risks are identified and assessed during a product quality risk analysis with the stakeholders. The test team then designs, implements, and executes tests to mitigate the quality risks.
Risk assessment
In risk-based testing, risk assessment involves categorizing each risk outlined during risk identification and determining the likelihood and impact associated with each risk. Risk assessment may also involve evaluating or assigning other properties of each risk, such as risk owner.
Risk identification
[also see Risk analysis] In risk-based testing, quality risks are identified and assessed during a product quality risk analysis using various techniques and with the broadest possible sample of stakeholders
Risk level
1 - The level of a given risk typically involves assessing the likelihood of occurence and the impact upon occurrence.
2 - The level of risk can be assessed either quantitatively or qualitatively. If likelihood and impact can be ascertained quantitatively, one can multiply the two values together to calculate a quantitative risk priority number. Typically, though, the level of risk can only be ascertained qualitatively. That is, one can speak of likelihood being very high, high, medium, low, or very low, but one cannot express likelihood as a percentage with any real precision; similarly, one can speak of impact being very high, high, medium, low, or very low, but one cannot express impact in financial terms in a complete or precise fashion.
Risk management
The general process, as described in the organization’s Test Policy / Strategy documents, by which risks are managed at all stages of testing through efforts at identifying risks as early as possible, addressing or mitigating those risks, identifying the sources and consequences of the risks, understanding sources of risk in order to create process improvements that prevent those defects in the first place, using identified risks to prioritize and sequence testing efforts, etc.
Risk mitigation
In risk-based testing, risk mitigation is the process of designing, implementing, and executing testing efforts in accordance with a test plan designed to cover the identified risks. Effort should be proportional to risk level, meaning that more resources and more meticulous test techniques are used for high-risk items and vice versa. Adjustments based on new information should be identified and adjusted for by the test team throughout the project.
Risk
The possibility of a negative or undesirable outcome or event. It exists whenever some problem may occur which would decrease customer, user, participant, or stakeholder perceptions of product quality or project success.
Risk-based testing
Risk-based testing is an approach whereby stakeholders idetnify all possible risks to product quality, assess those risks for their various risk levels, plan and implement test coverage designed to proportionally mitigate those risks, and manage the risk-related outcomes of those activities.
Test approach
The test approach, as set out in a Master Test Plan, discusses how the testers will implement the Test Strategy for the current project.
Test director
One of the positions of a test team’s management which, together with Test Lead and Test Manager, are collectively referred to as “Test Managers” by ISTQB.
Test leader
One of the positions of a test team’s management which, together with Test Director and Test Manager, are collectively referred to as “Test Managers” by ISTQB.
Test estimation
Estimation, as a management activity, is the creation of an approximate target for costs and completion dates associated with the activities involved in a particular operation or project.
Test level
A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test, integration test, system test, and acceptance test
Test management
Appropriately arranging the test processes, including the associated activities and work products, according to the needs and circumstances of the other stakeholders, their activities (e.g., the SDLC in which testing occurs), and their work products (e.g., requirements specifications).
Test monitoring
A schedule and monitoring framework needs to be established to enable tracking of test work products and resources against the test plan, including detailed measures and targets relating the status of test work products and activities to the plan and strategic objectives. This allows a framework that enables efficient test control
Test plan
A test plan describes the implementation of a test strategy for project or a sub-component of a project regarding the testing activities to be carried out. Depending on project context, the plan may take the form of a single document or it may be separated into a Master Test Plan and Level Test Plans.
Test policy
A document, developed by senior test management staff in collaboration with senior managers for stakeholder groups, that describes why the organization tests; what are the overall objectives for testing that the organization wants to achieve.
Test strategy
A document that describes the organization’s general test methodology:
- How is testing used to manage product/project risks,
- How is testing divided into levels
- What high-level activities are associated with testing
An organization may have different strategies for different situations (e.g., different SDLCs, different levels of risk, different regulatory requirements, etc.)
Wide Band Delphi
A consensus-based technique for estimating effort.
Audit
Activities performed to demonstrate conformance to a defined set of criteria, most likely an applicable standard, regulatory constraint, or contractual obligation. As such, audits are intended to provide independent evaluation of compliance.
Informal review
A review type characterized by not following a defined process and not having formal documented output.
Inspection
A type of peer review that relies on visual examination of documents to detect defects, e.g., violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a documented procedure.
Management review
A review of processes used to monitor progress, assess status, and make decisions about future actions. E.g., project retrospectives (i.e., lessons learned).
This is as an integral part of process improvement activities, supporting decisions about the future of the project such as adapting the level of resources, implementing corrective actions, or changing the scope of the project.
Moderator
Also referred to as the Facilitator, the individual who ensures the effective running of review meetings. This person mediates, if necessary, between various points of view and is often the person upon whom the success of the review depends.
Review
An evaluation of a work product or process to ascertain discrepancies from expectations and to recommend improvements. Examples include informal review, walkthrough, technical review, and inspection.
Review plan
A plan formulated by a review leader of what reviews will be undertaken for a given project with consideration to (a) what should be reviewed (product and process), (b) who should be involved in specific reviews, (c) which relevant risk factors to cover in specific reviews, (d) what review type to use and at what level of formality.
Reviewer
A participant in a review.
Technical review
A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken.
Walkthrough
A step-by-step presentation by the author of a work product in order to gather information and to establish a common understanding of its content.
