ISTQB Foundation Level Exam Crash Course Part-27
This is Part 27 of 35 containing 5 Questions (Q. 131 to 135) with detailed explanation as expected in ISTQB Foundation Level Exam Latest Syllabus updated in 2011
Deep study of these 175 questions shall be of great help in getting success in ISTQB Foundation Level Exam
Q. 131: What is Expert-Based Approach of Test Estimation?
This approach uses the experience of owners of the relevant tasks or experts to derive an estimate (this is also known as the Wide Band Delphi approach).
In this context �experts� could be:
1) Business experts.
2) Test process consultants.
3) Developers.
4) Technical architects.
5) Analysts and designers.
6) Anyone with knowledge of the application to be tested or the tasks involved in the process.
There are many ways that this approach could be used. Following are the two examples:
1) Distribute a requirement specification to the task owners and get them to estimate their task in isolation. Amalgamate the individual estimates when received; build in any required contingency, to arrive at the estimate.
2) Distribute to known experts who develop their individual view of the overall estimate and then meet together to agree on and/or debate the estimate that will go forward.Expert estimating can use either of the above approaches individually or mixing and matching them as required.
<<<<<< =================== >>>>>>
Q. 132: What are the categories of levels of effort required to fulfil the test requirements in a project?
Many things affect the level of effort required to fulfil the test requirements of a project.
These can be split into three main categories, as described below.
1) Product characteristics:
a) Size of the test basis;
b) Complexity of the final product;
c) The amount of non-functional requirements;
d) The security requirements (perhaps meeting BS 7799, the security standard);
e) How much documentation is required (e.g. some legislation-driven changes demand a certain level of documentation that may be more than an organization would normally produce);
f) The availability and quality of the test basis (e.g. requirements and specifications).
2) Development process characteristics:
a) Times-scales;
b) Amount of budget available;
c) Skills of those involved in the testing and development activity (the lower the skill level in development, the more defects could be introduced, and the lower the skill level in testing, the more detailed the test documentation needs to be);
d) Which tools are being used across the life cycle (i.e. the amount of automated testing will affect the effort required).
3) Expected outcome of testing such as:
a) The amount of errors;
b) Test cases to be written.
Taking all of this into account, once the estimate is developed and agreed the test leader can set about identifying the required resources and building the detailed plan.
<<<<<< =================== >>>>>>
Q. 133: How do we track & control the progress of testing projects?
Having developed the test plan, the activities and time-scales determined within it need to be constantly reviewed against what is actually happening. This is test progress monitoring. The purpose of test progress monitoring is to provide feedback and visibility of the progress of test activities.
The data required to monitor progress can be collected manually, e.g. counting test cases developed at the end of each day, or, with the advent of sophisticated test management tools, it also possible to collect the data as an automatic output from a tool either already formatted into a report, or as a data file that can be manipulated to present a picture of progress.
The progress data is also used to measure exit criteria such as test coverage, e.g. 50 per cent requirements coverage achieved.
Common test metrics include:
1) Percentage of work done in test case preparation (or percentage of planned test cases prepared).
2) Percentage of work done in test environment preparation.
3) Test case execution (e.g. number of test cases run/not run, and test cases passed/failed).
4) Defect information (e.g. defect density, defects found and fixed, failure rate and retest results).
5) Test coverage of requirements, risks or code.
6) Subjective confidence of testers in the product.
7) Dates of test milestones.
8) Testing costs, including the cost compared with the benefit of finding the next defect or to run the next test.
Ultimately test metrics are used to track progress towards the completion of testing, which is determined by the exit criteria. So test metrics should relate directly to the exit criteria.
<<<<<< =================== >>>>>>
Q. 134: What information should be included while Test Reporting?
Test reporting is the process where by test metrics are reported in summarized format to update the reader regarding the testing tasks undertaken. The information reported can include:
1) What has happened during a given period of time, e.g. a week, a test level or the whole test endeavor, or when exit criteria have been met.
2) Analyzed information and metrics required to support recommendations and decisions about future actions, such as:
a) An assessment of defects remaining;
b) The economic benefit of continued testing, e.g. additional tests are exponentially more expensive than the benefit of running;
c) Outstanding risks;
d) The level of confidence in tested software, e.g. defects planned vs. actual defects found.
<<<<<< =================== >>>>>>
Q. 135: What are the different sections of a Test Summary Report?
The IEEE 829 standard includes an outline of a test summary report that could be used for test reporting. The structure defined in the outline is shown in the following table.
| Section No. | Heading | Details |
| 1 | Test summary report identifier | The specific identifier allocated to this document, e.g. TSR XYX v1 |
| 2 | Summary | # Identifies the items tested (including any version numbers)
# Documents the environments in which the test activity being reported on took place # References the testing documentation for each test item, e.g. test plan, test cases, test defect reports |
| 3 | Variances | Reports deviations from the test approach or strategy, test plan, test specification or test procedures |
| 4 | Comprehensive assessment | Measures the actual progress made against the exit criteria and explains why any differences have arisen |
| 5 | Summary results | Provides an overview of the results from the test activities; it should include details of defects raised and fixed, as well as those that remain unresolved |
| 6 | Evaluation | Provides an evaluation of the quality of each test item, including a view of the risks of failure in production of these test items. Based upon the test result metrics and test item pass/fail criteria |
| 7 | Summary of activities | # A summary of the major test activities and events such as test environment unavailability, success or weaknesses of the test specification process, etc.
# Should also include resource usage data, e.g. planned spend against actual spend |
| 8 | Approvals | Identifies all approvers of the document |
The information gathered can also be used to help with any process improvement opportunities.This information could be used to assess whether:
a) The goals for testing were correctly set (were they achievable; if not why not?);
b) The test approach or strategy was adequate (e.g. did it ensure there was enough coverage?);
c) The testing was effective in ensuring that the objectives of testing were met.
Part – 28 of the Crash Course – ISTQB Foundation Exam
Access The Full Database of Crash Course Questions for ISTQB Foundation Level Certification
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.