Quality Plan

Quality Plan QATP FINAL 28 April 1997 QUALITY ASSURANCE PLAN FOR THE MJY TEAM SOFTWARE RISK MANAGEMENT WWW SITE Prepared for: Dr. Richard Bechtold SWSE 625 Prepared by: MJY Team George Mason University Approved by: P. McNeece MJY Program Manger RECORD OF REVISIONS Revision Description Date QATP 1.0 Initial Quality Assurance Plan February 27, 1997 QATP FINAL Final Quality Assurance Plan April 28, 1997 Table Of Contents 1.0. Introduction 1 1.1. Purpose 1 1.2. Project Description 1 1.3. Product Deliverables 1 1.4. Target Environment 2 2.0. Project Organization and Responsibilities 2 3.0. Quality Assurance Plan Activities 2 3.1. Documentation Audits 2 3.2. Code Inspections 3 3.3. Document Reviews 3 3.4. Data Collection 3 4.0. Verification, Validation, and Test 4 4.1. Test Items 4 4.2. Pass Criteria for Items Under Test 5 4.3. Test Deliverables 6 4.4. Test Responsibilities 6 APPENDICES A. QA Error Tracking Log B. Document Review - Build 3 Test C. Document Review - Customer Delivery Baseline Quality Plan 1.0. Introduction 1.1. Purpose. The purpose of this plan is to establish the organization, responsibilities, activities, and metrics which will be used to ensure customer satisfaction with the software product described in paragraph 1.2. These metrics will also assist in identifying improvements to MJY team processes that will be used to carry out future development projects of this nature. 1.2. Project Description. The purpose of this project is to construct a website for individuals interested in obtaining information on Software Project Management, specifically in the area of Risk Management. This project fulfills the team project requirements for George Mason University’s Spring 1997 Software Systems Engineering 625 course taught by Professor Richard Bechtold. 1.3. Product Deliverables. The following constitutes the list of final product deliverables and associated quality requirements that are due to Professor Bechtold on April 28, 1997. Each deliverable will be submitted in both hard copy (paper) and electronic formats. Electronic (delivery) file formats will be HTML for the sake of consistency and portability. 1.3.1. HTML and CGI scripts that implement basic site and web page functionality; 1.3.2. Final version of all software project documents and plans; 1.3.2.1. Software Requirement Specifications; 1.3.2.2. Software Design Document 1.3.2.3. Requirements Management Process Document 1.3.2.4. Risk Mitigation plan; 1.3.2.5. Project Management plan; 1.3.2.6. Project Management schedule; 1.3.2.7. Quality Assurance/Test plan; 1.3.2.8. Test Analysis Report; 1.3.2.9. Configuration Management plan; 1.3.3. Contents of all web pages when baselined for customer delivery; 1 1.3.4. Description of the project’s software tool suite used in development, test, quality assurance, and configuration management activities 1.4. Target Environment. Web site will be developed for installation, operation, and maintenance at www.baz.com. Site functionality is transferable to GMU network sites with the exception of bulletin board capability which requires the use of CGI scripts not permitted by GMU network personnel. 2.0. Project Organization and Responsibilities. Implementation responsibility for the quality assurance process and plan rests with the Quality Assurance manager, with assistance from other MJY team members as specified. After accomplishing each QA activity, results and recommended actions will be forwarded to the program manager and the affected activity manager for resolution and/or rework. 3.0. Quality Assurance Plan Activities. The plan will consist of the following activities: requirements reviews, other documentation and process audits and reviews, and test of time- phased product deliverables. Reviews are designed to ensure consistency between documents and processes, and must be traceable to agreed upon customer requirements as specified in the SRS. Results of these activities are reported to the program manager and affected activity manager for resolution. Detailed processes for accomplishing these activities are described in the following paragraphs. Verification, validation, and test plans and activities are covered in a separate document section. 3.1. Documentation audits. 3.1.1 Document audits are required when: 3.1.1.1. Final documents for a completed development phase are submitted for CM; 3.1.1.2. Final versions of project documents are delivered to CM for inclusion into the project baseline 3.1.2. All project team members will review documents for format and content (within their area of responsibility) within one week of submission date by originator. 3.1.2.1. QA review of documents will focus on consistency among and between documents. Particular attention will be paid to possible conflicts between the various managers’ described plans and processes. 3.1.3. Document any errors and recommended remedial actions by supplying information identified in paragraph 3.4.1 to the document originator and QA. 3.1.4. QA will follow up on remedial actions/review reworked document prior to CM submission 2 3.1.5. Document audits will be accomplished according to the schedule contained in the latest version of MJY work breakdown schedule. 3.2. Code inspections. 3.2.1. Review of HTML and CGI scripts by QA will not be accomplished for this project. Script adequacy will be determined by how it performs during (incremental) unit testing, with corrections to script(s) on an as-required basis. 3.3. Document Reviews. 3.3.1. Document reviews will be accomplished when original or updated project plans/documents listed in paragraph 1.3.4 will be entered into CM. In addition, QA will perform informal document reviews as part of its incremental test activities. 3.3.2. All project team members will review documents for format and content (within their area of responsibility) within one week of submission date by originator. QA review responsibilities are identical to those outlined in paragraph 3.1.2. 3.3.3. Document any errors and recommended remedial actions IAW paragraph 3.4.1, and submit (electronic) copies to the document originator and QA. 3.3.4. QA will follow up on recommended actions during the next review of the document in question. 3.4. Data Collection 3.4.1. Error Detection/Tracking. The following information is required for each error discovered during scheduled review, audit, or test. QA will supply items 3.4.1.1., 3.4.1.5., and 3.4.1.6; the remaining items will be supplied by the individual discovering the error. 3.4.1.1. Error Tracking Number 3.4.1.2. Short error description 3.4.1.3. Development Activity when error discovered 3.4.1.4. Recommended remedial action 3.4.1.5. Date Recommended remedial action accomplished 3.4.1.6. Date error closed 3 4.0. Verification, Validation, and Test (VV&T) Approach/Plan. The basic web site environment and its functionality are provided by using commercial off-the-shelf (COTS) software to generate the basic web page and user interfaces, while existing site network hardware/software provides two way web page-Internet connectivity. Custom scripts within the COTS software control applications to provide the functionalities outlined in the SRS. Therefore primary emphasis of the VV&T program (for simplicity, hereafter referred to as the “test” program) is to test web site connectivity and functionality, and to verify and validate web site contents, against SRS requirements. The test program will be synchronized to the time-phased delivery of increased web site functionality, and will include regression testing to insure continued correct operation of previously delivered capability. The plan does not call for the specific testing of the COTS software or its capabilities. However, if the web site fails to meet SRS functionality requirements, tests would be conducted to eliminate the COTS software as a potential point of failure. Test plan updates will be made to reflect changes in project requirements. 4.1. Test Items. The test program will evaluate the following capabilities/functions: 4.1.1. MJY web site connectivity (access via Internet connection) 4.1.2. MJY web page basic functionality 4.1.2.1. Viewability of each web page section using Netscape 2.0 or equivalent browsers 4.1.2.2. Ability to download files when this capability is indicated 4.1.2.3. Ability to correctly navigate within the web site (ie, ensure that each link or function button takes the reader to the designated section of the web page or document). 4.1.3. MJY Bulletin Board functionality 4.1.3.1. Link connectivity (ie, can you connect to bulletin board from designated MJY web page links) 4.1.3.2. View existing message threads (original message and any responses) 4.1.3.3. Download posted messages or responses 4.1.3.4. Post a message. Test will ensure that bulletin board posts message, and designates post as an original message. 4.1.3.5. Post a response to an existing message. Test will ensure that the response is appended to the correct message or response threads, and is designated as a response. 4.1.4. MJY links to other external sites 4 4.1.4.1. (Verify) Number of links in each category 4.1.4.2. Link connectivity (ie, can you connect to specified external site) 4.1.4.2. (Verify) Content of each site appropriate for each category 4.1.4.3. Site content viewability 4.1.4.4. Ability to download web page information (if permitted by that site) 4.2. Pass criteria for items under test 4.2.1. HTML links test. 4.2.1.1. The deliverable will contain the minimum number of links as specified in the SRS. 4.2.1.2. There will be a 90% successful connection rate for all testable links. Two attempts, separated by at least 4 hours, will be made before determining the connection to a target link as unsuccessful. 4.2.2. Web page contents. 4.2.2.1. The information contained on delivered links will be directly relevant to subjects cited in WBS paragraphs 1.1.2. through 1.1.7 4.2.2.2. The web page section contains the minimum number of items (keywords, “lessons learned,” publications citation )specified in the corresponding SRS section. 4.2.2.3. Web page contents are readable (by a user reviewing the item “on-site”) using standard web browsers. 4.2.2.4. Web page contents will be downloadable and using 7 HTML or later browsers (user must be able to download and view/print a usable hard copy of downloaded document.) 4.2.3. Bulletin Board Functionality 4.2.3.1. Link connectivity (ie, can you connect to bulletin board from designated MJY web page links) 4.2.3.2. View existing message threads (original message and any responses) 4.2.3.3. Download posted messages or responses 5 4.2.3.4. Post a message or response to an existing message. Test will ensure that message is posted, or that response is appended to the correct message thread. 4.3. Test deliverables 4.3.1. All test error detection/tracking logs. These will be part of each phased test report. This data will also be contained in the overall QA error tracking log 4.3.2. Test cases for each test session. These will be part of each phased test report. 4.3.3. Final test report which certifies the product meets SRS requirements. Report will also indicate which SRS requirements--if any--were not successfully demonstrated, with any recommended remedial actions. 4.4. Test responsibilities. Test team will be responsible for the following: 4.4.1. Schedule all test activities. 4.4.2. Coordinate, as required, requests for personnel augmentation with other project team managers. 4.4.3. Notify developer and program manager of any deficiencies found during testing (along with any recommended remedial actions) 4.4.4. Review deficiency reports submitted to the developer or program manager for additional items that should be spot checked during the next scheduled test phase. 4.4.5. Establish and maintain an error detection/tracking log (will be part of each test template) 4.4.6. Prepare and submit the test report 6