ISTQB Chapter 5 Theories Flashcards
What is a test plan?
A test plan
- Documents the means and schedule for achieving the test objective
- Helps to ensure that the performed test activities will meet the established criteria
- Serves as a means of communication with team members and other stakeholders
- Demonstrates that testing will adhere to the existing test policy and test strategy (or explains why the testing will deviate from them)
What are the typical content of a test plan?
- Context of testing (e.g. test scope, test objectives, test basis)
- Assumptions and constraints of the test project
- Stakeholders (e.g., roles, responsibilities, relevance to testing, hiring and training needs)
- Risk register (e.g. product risks, project risks)
- Test approach (e.g. test levels, test types, test techniques, test deliverables, entry criteria and exit criteria, independence of testing, metrics to be collected, test data requirements, test environment requirements, deviations from the test policy and test strategy)
- Budget and schedule
What are the two kinds of planning for iterative SDLCs?
a. Release Planning
b. Iteration Planning
This planning looks ahead to the release of a product, defines and re-defines the product backlog, and may involve refining larger user stories into a set of smaller set of smaller user stories. It also serves as the basis for the test approach and test plan across all iterations. Testers involved participate in writing testable user stories and acceptance criteria, participate in project and quality risk analyses, estimate test effort associated with user stories, determine the test approach, and plan the testing for the release.
a. Release planning
b. Iteration planning
a. Release planning
This planning looks ahead to the end of a single iteration and is concerned with the iteration backlog. Testers involved participate in the detailed risk analysis of user stories, determine the testability of user stories, break down user stories into tasks (particularly testing tasks), estimate test efforts for all testing tasks, and identify and refine functional and non-functional aspects of the test object.
a. Release planning
b. Iteration planning
b. Iteration planning
This refers to the preconditions for undertaking a given activity. If this is not met, it is likely that the activity will prove to be more difficult, time-consuming, costly, and riskier.
Entry Criteria
This refer to what must be achieved to declare an activity completed.
Exit Criteria
In Agile software development, what is the other term for exit criteria?
Definition of Done
In Agile software development, what is the other term for entry criteria?
Definition of Ready
What are the typical entry criteria?
- Availability of resources (e.g., people, tools, environments, test data, budget, time)
- Availability of testware (e.g. test basis, testable requirements, user stories, test cases(
- Initial quality of a test object (e.g. all smoke tests have passed)
What are the typical exit criteria?
- Measures of thoroughness (e.g., achieved level of coverage, number of unresolved defects, defect density, number of failed test cases).
- A binary Yes/No criteria e.g., planned tests have been executed, static testing has been performed, all defects found are reported, all regression tests are automated).
Note: Running out of time or budget can also be viewed as valid exit criteria. Even without other exit criteria being satisfied, it can be acceptable to end testing under such circumstances, if the stakeholder have reviewed and accepted the risk to go live without further testing.
What are the commonly used Estimation Technique for test effort in test planning?
- Estimation based on ratios
- Extrapolation
- Wideband Delphi
- Three-point estimation
In this metrics-based estimation technique, figures are collected from previous projects within the organization, which makes it possible to derive “standard” ratios. The ratios of an organization’s own projects (e.g. taken from historical data) are generally the best source to use in the estimation process.
a. Estimation based on ratios
b. Extrapolation
c. Wideband Delphi
d. Three-point estimation
a. Estimation based on ratios
In this metrics-based estimation technique, measurements are made as early as possible in the current project to gather the data. Having enough observations, the effort required for the remaining work can be approximated by extrapolating this data (usually by applying a mathematical model). This is very suitable in iterative SDLCs.
a. Estimation based on ratios
b. Extrapolation
c. Wideband Delphi
d. Three-point estimation
b. Extrapolation
In this iterative, expert-based technique, experts make experience-based estimations. The results are collected and if there are deviations of an expert’s estimate that are out of range of the agreed upon boundaries, the experts discuss their current estimates. Each expert is then asked to make a new estimation based on that feedback, again in isolation. This process is repeated until a consensus is reached.
a. Estimation based on ratios
b. Extrapolation
c. Wideband Delphi
d. Three-point estimation
c. Wideband Delphi
In this expert-based technique, three estimations are made by experts:
the most optimistic estimation (a);
the most likely estimation (m);
and the most pessimistic estimation (b).
The final estimate (E) is their weighted arithmetic mean. The estimate is calculated as:
E = (a + 4*m +b) /6
Three-point estimation
What are the commonly used test case prioritization strategies?
- Risk-based prioritization
- Coverage-based prioritization
- Requirements-based prioritization
Note: Priority level would not work if test cases being tested have dependencies. In addition, availability of resources must also be taken into account when strategizing test case prioritization
This test case prioritization prioritizes test execution based on the result of risk analysis. Test cases covering the most important risks are executed first.
a. Risk-based prioritization
b. Coverage-based prioritization
c. Requirements-based prioritization
a. Risk-based prioritization
This test case prioritization prioritizes based on coverage (e.g., statement coverage). Test cases achieving the highest coverage are executed first. In another variant, called additional coverage prioritization, the test case achieving the highest coverage is executed first; each subsequent test case is one that achieves the highest additional coverage.
a. Risk-based prioritization
b. Coverage-based prioritization
c. Requirements-based prioritization
b. Coverage-based prioritization
This test case prioritization prioritizes execution based on the priorities of the requirements traced back to the corresponding test cases. Requirements priorities are defined by stakeholders. Test cases related to the most important requirements are executed first.
a. Risk-based prioritization
b. Coverage-based prioritization
c. Requirements-based prioritization
c. Requirements-based prioritization
This is a model showing that different tests may have different granularity. This supports the team in test automation and in test effort allocation by showing that different test objectives are supported by different levels of test automation.
Granularity - the scale or level of detail present in a set of data or other phenomenon.
More granular = more detail
Test Pyramid
This groups the test levels with the appropriate test types, activities, test techniques, and work products in the Agile software development. The model supports test management in visualizing these to ensure that all appropriate test types and test levels are included in the SDLC and in understanding that some test types are more relevant to certain test levels than others. This model also provides a way to differentiate and describe the test types to all stakeholders, including developers, testers, and business representatives.
Testing Quadrant
