Directions for using
template:
Read the Guidance
(Arial blue font in brackets) to understand the
information that should be placed in each section of this template. Then delete
the Guidance and replace the placeholder within <<Begin text here>>
with your response. There may be additional Guidance in the Appendix of some
documents, which should also be deleted once it has been used.
Some templates have four levels of headings. They are not indented, but can be differentiated by font type and size:
You may elect to indent sections for readability.
|
Author |
|
|
Author Position |
|
|
Date |
|
Ó 2002 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft
and Visual Basic are either registered trademarks or trademarks of Microsoft in
the
Change Record
|
Date |
Author |
Version |
Change Reference |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewers
|
Name |
Version Approved |
Position |
Date |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Distribution
|
Name |
Position |
|
|
|
|
|
|
|
|
|
|
|
|
Document Properties
|
Item |
Details |
|
Document Title |
Testing and Bug Report |
|
Author |
|
|
Creation Date |
|
|
Last Updated |
|
Test and Bug Reporting Summary
Test Results Summary – Deltas from Last Report
Discrepancies in Execution of Test Plan
Remaining Tests and Test Plan Revisions
[Introduction to the
Template
Description:
The Testing and Bug Report is a roll-up summary of the individual test cases
from each stage of testing. The intent is that this document will be used
multiple times at frequent intervals during the development, testing, and
stabilization phases. For example, during a six-week build phase, the test team
might submit this report weekly, or six times during the build phase; however,
the team might submit the report bi-weekly during the stabilization
phase.
Justification:
It
is important to regularly communicate status of tests to the team and other key
stakeholders, as test results may impact plans and schedules.]
{Team
Role Primary: Test is responsible for the delivery of the Testing and Bug Report
during the Development and Stabilization phases. Development is instrumental in the
review of the Test and Bug Report in order to qualify, quantify, and classify
bugs in order to triage for resolution.
Team
Role Secondary:
Program Management assists in
removing barriers for Test to complete all objectives as defined in the test
plans and monitors the progress towards delivery in accordance to the schedule.
Product Management needs to be aware
of test results to discuss the status of the build to external stakeholders. Release Management should be cognizant
of test results to ensure that the test harness represents true operational,
support and deployment environmental concerns that could jeopardize final
delivery. User Experience should be
aware of test results to confirm that test plans are adequately executing
against plan and that user experience requirements are adequately addressed
throughout the test phases.}]
[Description: The Test and Bug Reporting
Summary section provides an overall summary of the contents of this
document.
Justification:
Some
project participants may need to know only the highlights of the plan, and
summarizing creates that user view. It also enables the full reader to know the
essence of the document before they examine the details.]
<<Begin text here>>
[Description: The Methods and Tools
section is an analysis of actual testing that occurred as compared against the
Test Plan. Avoid gross reiteration of the test plan - address which elements of
the plan were implemented successfully, but also address where variations and
deviations from plan occurred and why.]
[Description: The Testing Methods Summary section
lists and describes the test methods employed. It should describe which methods
were implemented successfully, but also address where variations or deviations
from the plan occurred and why.
Justification:
This summary gives report readers some knowledge of the methods the team
employed to develop and apply test cases, thus helping to assure them that
testing and evaluation was done in a rigorous and repeatable
manner.]
<<Begin text here>>
[Description: The Test Tools Summary
section lists and describes the test tools employed for each test method. It
should describe which tools were implemented successfully, but also where
variations or deviations from the plan occurred and why.
Justification:
This summary gives report readers some knowledge of the tools the team applied
to assist in the use of test methods, thus helping to assure them that testing
and evaluation was done efficiently and minimized human error.]
<<Begin text here>>
[Description: The Test Report section provides a general
solution-wide status report of the actual test performed. This includes
descriptions of what testing has occurred since the last test report, any
variations or deviations from the test plans, identification of remaining test
items, and any changes made to the test
plan.]
[Description: The –Test Results Summary section provides a
summary recap of the testing results since last report.
Justification:
This
summary helps to assure project stakeholders that the team is following the
original or the modified test plan.]
<<Begin text here>>
[Description: The Discrepancies in
Execution of Test Plan section identifies any deviations against the test plan
and test cases performed and provides a detailed analysis of each deviation’s
cause and justification.
Justification:
Test plans sometimes do not
anticipate conditions and circumstances that can affect actual performance. In
many cases a team must deviate from a test plan and modify or create new and/or
additional test cases to handle situations that occur during
testing.]
<<Begin
text here>>
[Description: The Remaining Tests and Test Plan Revisions
section identifies the test cases yet to be used and identifies and describes
any key changes made to the test plan since the last
report.
Justification:
This
information may impact the other team’s plans and schedules.]
<<Begin text here>>
[Description: The Testing Areas section
summarizes the results of the specific test activities and results for each area
of the solution.
Justification:
Project
teams create test cases to test each product functional area (specific types of
calculations, creating lists, help, report creation, etc.). In many cases,
reporting the testing activities and results by functional area provides greater
meaning than reporting such information by individual requirements.]
[Description: The Produce Area 1 section describes the
specific test activities and results for this product area. You should change
the heading of this section to the name of the product area for better
identification.]
[Description: The Test Goal(s) section
restates what the test intends to accomplish, for example “verify compliance
with standard XYZ”.]
<<Begin text here>>
[Description: The Evaluation Criteria
section identifies the criteria used to evaluate the test
cases.]
<<Begin text here>>
[Description:
The Results section describes the results of running the test cases. This may be
described as:
It
may be helpful to use graphics for load testing (i.e. screen shots of Perfmon,
etc.).]
<<Begin text here>>
[Description: The Recommendations
section identifies and describes critical feature deficiencies and makes
recommendations for alteration, elimination, expansion/reduction of the
feature.]
<<Begin text here>>
[Description: The Product Area 2 section describes the
specific test activities and results for this product area. You should change
the heading of this section to the name of the product area for better
identification.]
[Description: The Test Goal(s) section
restates what the test intends to accomplish, for example “verify compliance
with standard XYZ”.]
<<Begin text here>>
[Description: The Evaluation Criteria
section identifies the criteria used to evaluate the test
cases.]
<<Begin text here>>
[Description:
The Results section describes the results of running the test cases. This may be
described as:
It
may be helpful to use graphics for load testing (i.e. screen shots of Perfmon,
etc.).]
<<Begin text here>>
[Description: The Recommendations
section identifies and describes critical feature deficiencies and makes
recommendations for alteration, elimination, expansion/reduction of the
feature.]
<<Begin text here>>
[Description: The Bug Reporting section describes the
general status of the build and provides details on
bugs.
Justification:
This information assists the team in understanding if the project schedule is on
track.]
[Description: The Build Status section
describes the stability of the build and where in the milestone process the test
team believes the current state of the build lives.]
<<Begin text here>>
[Description: The Bug Report section identifies all
outstanding bugs and their status. You may provide this information in a matrix
or listing. You may choose to utilize an attached tool or spreadsheet or embed
visuals into this section report. Link each bug to the test case from which the
bug was identified, and using a traceability link, to the area(s) of the
solution affected.]
[Description: The Bug Convergence
Analysis section describes the specific point in the build process where the
number bugs resolved exceeds the number of new bugs reported. This is a critical
juncture in the stabilization phase that indicates an important milestone in the
march to final ship. From this point, build status should be analyzed and
measured critically in order to be able to estimate reliably when the delivery
is approaching a shipping status.]
<<Begin text here>>
[Description: The Revised Testing Plan section is a
submission of the revised
test plan, making appropriate modifications to reflect new test plans and any
changes to goals, criteria, bug-triage strategies, and test
cases.
Justification:
Since
testing is a critical element in the delivery of a successful solution, the test
plan must always reflect what is actually being done towards this goal.]
<<Begin text here>>