Software Release Package
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
- 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 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.