Purpose
Creating reports that provide insight into both the quality of the test object and the progress and quality of the test
process. These reports will ensure that the client and other stakeholders can steer the course of the testing effectively. |
Relationships
Roles | Primary Performer:
| Additional Performers:
|
Outputs |
|
Process Usage |
|
Main Description
Method of operation
During the test process, the test manager compiles various reports. Periodic reports are created on the
quality of the test object and the progress and quality of the test process. Besides the periodic reports, the client
or other stakeholders may request reports on demand. The most familiar example of this is the risk report, for
outlining the possible consequences of a threat or risk to the testing. There may also be an unexpected request for an
extra progress report, for example to provide the most up-to-date input for a steering group or project management
meeting. At the end of the test process, a recommendation for release and final report are drawn up.
With all this information, the client, project manager and other stakeholders are supplied with insight into the extent
to which:
-
The intended result is achieved
-
The risks of taking the system into production are known and are as small as possible within the set preconditions
-
This has taken place within budget and term.
In other words, this refers to the BDTM aspects of Result, Risks, Time and Costs. Supplying insight implies that the
report should have relevance to the recipient(s) of it.
The reports are based on the data as established in accordance with Organise The Management (AST).
The content of the most important reports is described below:
-
a. Progress report
-
b. Risk report
-
c. Release advice
-
d. Final report
Products
Techniques
Tools
|
Steps
1. Progress Report
Reporting takes place in accordance with the reporting structure described in the test plan. The progress report
contains data on the most recent reporting period and cumulative data on the entire test process.
Besides figures, the report should also provide textual explanation and advice on the results, progress, risks and any
problem areas. The latter is inclined to be forgotten in reports that are generated from test-management tools. It
should be realised that explanation and advice are very important in the provision of quick and reliable insight into
the figures. It is the most important product of testing. While the explanation can and should be given verbally,
it most definitely should be contained in the written report. This forces the test manager to think carefully, as well
as making the advice stronger, reaching a wider audience and helping with the process evaluation in retrospect.
|
2. Risk Report
The purpose of the risk report is to supply the various stakeholders with sufficient information to allow them to make
informed decisions in respect of the test process. The information in the risk report should therefore also focus on the
consequences of the event for the achievement of the agreed result within the agreed timeline and cost levels.
In a risk report, the following subjects are dealt with, at a minimum:
-
A description of the event / the scenario
-
The consequences of the event for the testing
-
The significance of the event to the degree to which the various product risks are covered
-
Possible countermeasures - If possible, the test manager outlines several measures with the associated costs. An
estimate is also made of the influence of the measures on the recognised consequences and degree of coverage of
product risks.
-
Recommendation - The test manager provides a recommendation in respect of the measure(s) to be selected.
|
3. Release Advice
The release advice is created at the end of the test execution. The purpose of the release advice is to provide the
client and other stakeholders with a level of insight into the quality of the test object that will allow them to make
informed decisions on whether the test object can go on the following stage with its present status. The following
phase in this connection refers to a subsequent test level, or production. For that reason, the release advice is
usually created under severe pressure of time, since immediately after execution of the last tests and before the
test object is released to the next phase, there is usually very little time available. The test manager would do well
to have a draft release advice largely prepared towards the end of the last tests, so that only the last test results
need to be processed.
The information in the release advice should not actually come as a surprise to the client. He has been kept abreast of
developments relevant to him by means of reliable progress reports and, where necessary, risk reports. In order to supply
the client with the information necessary at this stage, the release advice should cover at least the following subjects:
-
A recommendation as to whether, from the point of view of the testing, it would be advisable to transfer the test
object in its present state to the next phase. The final decision on whether or not to go on to the next phase does
not lie within the test process. Many more factors are at work here, other than those relating to the test process.
For example, political or commercial interests that make it impossible to postpone transfer to a subsequent phase,
despite a negative release advice.
-
Obtained and unobtained results - Which test goals have been achieved and which not, or only to a certain degree?
On the basis of test results on characteristics and object parts, the test manager gives his opinion and advice on
the test goals set by the client. It is also indicated whether the exit criteria have been met. The number and
severity of the open defects play an important role here. Per defect, it is indicated what the consequences are for
the organisation. If possible, risk-reducing measures are also indicated, such as, for example, a workaround,
allowing the test object to go on to the next phase without the defect being solved.
-
Risk estimate - During the planning phase at the beginning of the test process, an agreement is made with the
client about the extent to which product risks will be overed, and with what degree of thoroughness. For
various reasons, it may be decided to cover certain parts less thoroughly with testing than the risk estimate
indicates. Moreover, during the test process, all kinds of changes are still usually being made to the original
strategy; moreover, the original risk estimate has possibly been adjusted, perhaps resulting in additional or
different risks. In this part of the release advice, the test manager points out which characteristics or object
parts have not been tested, or have been less thoroughly tested than the risks justify and so present a higher
risk. The associated consequences are also shown.
|
4. Final Report
The purpose of this report is to obtain insight into the way the test process has gone and to document empirical data
for the purposes of future test processes. The final report is created after issuing the release advice, usually when
the test object has already been released to the next phase. More time is therefore available for it.
The contents list of a final report is more or less the same as that of a progress report:
-
1. Evaluation of the test object (BDTM: Result)
-
1.1 Status per characteristic/object part
-
1.2 Status of test goals
-
2. Product risk and strategy adjustment (BDTM: Risks)
-
3. Release advice (BDTM: Result, Risks)
-
4. Evaluation of the test process
-
4.1 Progress (BDTM: Time and Costs)
-
4.2 Quality of the test process (BDTM: all the aspects)
-
6. Recommendations for future tests
-
7. Empirical data (optional)
-
8. Costs/benefits analysis (optional)
However, whereas a progress report looks ahead, the final report looks back. In other words, it mainly concerns the
difference between the original plan and the final realisation. What degree of deviation is there from the original
plan? Was the plan a good one, or were issues wrongly estimated? Were adjustments always timely and effective? To what
extent were the preconditions met, and met promptly enough? Could bottlenecks have been prevented? These differences
are analysed in particular for purposes of the risk analysis, test strategy, estimate and planning. The quality of the
test process is also considered: were the chosen procedures, tools and techniques used correctly and was the test
environment satisfactory? Recommendations are provided, if possible, for future tests. The task Evaluate The Test Process (AST) supplies the input for this evaluation. Also,use can
be made of the “Test process evaluation” checklist. In addition, empirical data may be collected and made available to
the client, or, even better, to a Testing line organisation. A last, optional, part of the fi nal report is a
costs/benefits analysis.
The final report is made available to the client and other stakeholders, possibly by means of a presentation.
|
|
More Information
Checklists |
|
Guidelines |
|
Tool Mentors |
|
Copyright
© 2006, Sogeti Nederland B.V. All rights
reserved.
|
|