| |
| |
See Also
Test Cases Sample. More...
Test Matrices Sample. More...
Test Plan Sample. More...
Test Case Design. More...
Weekly Status Report
Sample. More...
Stocking and Managing a Test Lab. More...
Key QA Documents. More...
Improving the Quality process by doing
the
Metrics Calculation
Download
Documentation Tips. More...
|
|
|
| |
More Resources
Some templates that
you will find useful
during the development
of your software product.
More...
When is a test plan
to complicated
by Charles Shelby. More...
Test Development
Life Cycle. More...
Test Plan Outline. More...
The test specification should
explain "how" to implement
the test cases described in the test plan. More...
|
|
|
| |
Have Something
to Share
software testing tip, interesting bug, or had an
interview lately?
Send us an Email.
|
|
|
| |
Promote Your
Products or Services
Interested in promoting your products on
SQAtester.com?
If so, we think you'll like
our Product Storefront Program.
The concept is simple.
More...
|
|
|
| |
Learn more material at a Fraction
of Price!
Get the training that will help you face the challenges
and meet the demands of today's competitive market place.
Programs
Offered: Oracle DBA, Cisco Networking,
Software Testing & Programming. More...
|
|
|
| |
To compete in today's market, you need Access to your Information Quickly and without hassle.
We can make this possible.
FREE 2 week trial
|
|
|
|
|
|
The Release Package is the final document QA
prepares. This is the compilation of all previous documents and a release recommendation. Each release package
will vary by team and project, but they should all include the following information.
|
| The Release Package |
 |
___________________________________ |
|
shared by Mikhail Rakhunov
· Project Overview
- This is a synopsis of the project, its scope, any problems encountered during the testing cycle and QA's recommendation
to release or not release. The overview should be a "response" to the test strategy and note areas where
the strategy was successful, areas where the strategy had to be revised etc.
The project overview is also the place for QA to call out any suggestions for process improvements in the next
project cycle.
Think of the Test Strategy and the Project Overview as "Project bookends".
· Project PRAD - This is the Product Requirements Analysis Document, which
defines what functionality was approved for inclusion in the project. If there was no PRAD for the project, it
should be clearly noted in the Project Overview. The consequences of an absent PRAD should also be noted.
· Functional Specification - The document that defines how functionality will be implemented.
If there were no functional specifications, it should be clearly noted in the Project Overview. The consequences
of an absent Functional Specification should also be noted.
· Test Strategy - The document outlining QA's process for testing the application.
· Results Summaries - The results summaries identify the results of each round
of testing (see section VI - Results by Build). These should be accompanied in the Release Package by the corresponding
reports for Test Coverage by Test Type and Test Coverage by Risk Type/Priority from the corresponding completed
Test Matrix for each build. In addition, it is recommended that you include the full Test Matrix results from the
test cycle designated as Full Regression.
· Known Issues Document - This document is primarily for Technical Support. This
document identifies workarounds, issues development is aware of but has chosen not to correct, and potential problem
areas for clients.
· Installation Instruction - If your product must be installed as the client site,
it is recommended to include the Installation Guide and any related documentation as part of the release package.
· Open Defects - The list of defects remaining in the defect tracking system
with a status of Open. Technical Support has access to the system, so a report noting the defect ID, the problem
area, and title should be sufficient.
· Deferred Defects - The list of defects remaining in the defect tracking system
with a status of deferred. Deferred means the technical product manager has decided not to address the issue with
the current release.
· Pending Defects - The list of defects remaining in the defect tracking system
with a status of pending. Pending refers to any defect waiting on a decision from a technical product manager before
a developer addresses the problem.
· Fixed Defects - The list of defects waiting for verification by QA.
· Closed Defects - The list of defects verified as fixed by QA during the
project cycle.
The Release Package is compiled in anticipation of the Readiness Review meeting. It is reviewed by the QA Process
Manager during the QA Process Review Meeting and is provided to the Release Board and Technical Support.
· Readiness Review Meeting:
The Readiness Review meeting is a team meeting between the technical product manager, project developers and QA.
This is the meeting in which the team assesses the readiness of the product for release.
This meeting should occur prior to the delivery of the Gold Candidate build. The exact timing will vary by team
and project, but the discussion must be held far enough in advance of the scheduled release date so that there
is sufficient time to warn executive management of a potential delay in the release.
The technical product manager or lead QA may schedule this meeting.
· QA Process Review Meeting:
The QA Process Review Meeting is meeting between the QA Process Manager (Barbara Thornton) and the QA staff on
the given project. The intent of this meeting is to review how well or not well process was followed during the
project cycle.
This is the opportunity for QA to discuss any problems encountered during the cycle that impacted their ability
to test effectively. This is also the opportunity to review the process as whole and discuss areas for improvement.
After this meeting, the QA Process Manager will give a recommendation as to whether enough of the process was followed
to ensure a quality product and thus allow a release.
This meeting should take place after the Readiness Review meeting. It should be scheduled by the lead QA on the
project.
· Release Board Meeting:
This meeting is for the technical product manager and senior executives to discuss the status of the product and
the teams release recommendations. If the results of the Readiness meeting and QA Process Review meeting are positive,
this meeting may be waived.
The technical product manager is responsible for scheduling this meeting.
This meeting is the final check before a product is released.
 Share your thoughts on Bugs and Fixes in SQAtester Group.
 E-mail to a Friend.
|
| Books to Read |
|
________________________________________ |
|
|
|
Quality Web Systems
This book provides a framework for ensuring that key Web system success criteria are addressed during the development
of a Web system. Detailed technical guidance is provided for all criteria, along with testing strategies that allow
for verification of a quality implementation. More...
|
|
|
|
Automated Software Testing
Written for those with some background in software engineering, Automated Software Testing: Introduction, Management,
and Performance delivers a rigorous guide to the state of the art in managing automated testing in a text that
will benefit anyone who tests software for a living. More...
|
| Categories |
|
________________________________ |
| Community |
|
________________________________ |
| Specials |
|
__________________________________ |
| Millions of titles discounted up to 40-90% off. Great
low prices on your favorite books. More... |
|
Find all of your favorite software.
More... |
|
|
