3.1.2. Test and Verification
3.1.2.1. Requirements Verification
3.1.2.1.1. All functional and non-functional requirements have been documented and jointly reviewed and approved by customer representative and program manager.
3.1.2.1.2. All approved requirements have been entered into requirements tracking matrix
3.1.2.2. Design Verification
3.1.2.2.1. Confirm each function within the design maps to an approved requirement contained in requirements tracking matrix
3.1.2.2.2 Confirm each approved requirement in the requirements tracking matrix maps is implemented by a single function within final software design
3.1.2.2.3. Document results of design verification review and recommended actions (if required)
3.1.2.2.4. Conduct follow-up to recommended actions resulting from design verification review
3.1.2.3. Code Verification -- for each (intermediate) incremental product delivery
3.1.2.3.1. Conduct a documented code walk through to confirm proper code implementation for new functions and their interfaces with existing code.
3.1.2.3.2. Conduct follow-up, within 2 weeks, any recommended actions resulting from code (verification) walk through
3.1.2.4. Code Test -- for each (intermediate) incremental product delivery, test program will:
3.1.2.4.1. Ensure that each new software function performs IAW specification
3.1.2.4.2. Perform regression analysis to ensure that previous software functionality is maintained
3.1.2.4.3. Document results of code test and recommended actions (if required)
3.1.2.4.4. Update next phase of test plan (as required)
3.1.3. Quality Control/Assurance (In addition to Test and Verification -- see section 3.2.1.)
3.1.3.1. Procedural audits will be conducted after each project phase and intermediate product deliverable.
3.1.3.1.1. Document any errors and recommended remedial actions
3.1.3.1.2. Conduct follow-up, within 2 weeks, on any recommended actions resulting from an audit. Document results of recommended actions to resolve the error(s).
3.1.3.2. Conduct review of original or updated project plans prior to entry into configuration management. (All project team members will review documents for content within one week of submission date by originator.)
3.1.3.2.1. Document any errors and recommended remedial actions
3.1.3.2.2. Evaluate corrective actions taken during next document update (or final document review)
3.1.3.3. Before task close-out, conduct audit of final versions of project documentation within one week of submission to program manager.
3.1.3.3.1. Document any errors and recommended remedial actions
3.1.3.3.2. Reinspect revised document when submitted
3.5. Define testing specifications to demonstrate required performance
3.5.1. HTML links test. For each incremental deliverable web page:
3.5.1.1. The deliverable will contain the minimum number of links as specified in project management plan.
3.5.1.2. All (incremental) deliverable links will be tested for connectivity. Regression testing will be conducted on at least 10% of previously delivered links cited in WBS paragraphs 1.1.2. through 1.1.7 to confirm no change in connectivity.
3.5.1.3. There will be a 90% successful connection rate for all testable links.
3.5.1.4. Two attempts, separated by at least 4 hours, will be made before determining the connection to a target link as unsuccessful.
3.5.2. Web page contents tests (Ed note: validation vs test in point of fact). For each incremental deliverable web page:
3.5.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. (Tester will be determinant of subject relevancy--appeals can be directed to program manager/team for review and ajudication)
3.5.2.2. Confirm that the web page section contains the minimum number of items (keywords, "lessons learned," publications citation )specified in the corresponding SRS section.
3.5.2.3. Web page contents is readible (by a user reviewing the item "on-site") using 7 HTML or later browsers.
3.5.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.) (Kim -- do we want to make this a requirement?)
3.5.3. "Chat Room" functionality test will demonstrate ability to allow up to 4 individuals to separately connect to and participate in a single conference. (Kim -- do we anticipate ability to multi-conference capability? If so, we'll need to add capability to track, monitor, and join with separate conferences -- probably 2 or 3 additional tests.) The following capabilities will be demonstrated with a 90% reliability rate: (Note: This will require active particiption of "volunteer" group members -- more on this with delivery of draft QA/Test plan later this week.)
3.5.3.1. A connecting party will be able to determine that he/she is the only "conferee" currently in the chat room.
3.5.3.2. A connecting party will be able to determine that a single individual is in the chat room.
3.5.3.3. A connecting party will be able to determine that a "conference" with two or more individuals is in progress.
3.5.3.4. All individuals in the chat room will be notified when an individual enters or departs the room.
3.5.3.5. Two single chat room occupants can establish a conference so long as no other conferences are established
3.5.3.6. A connecting party can petition to "join" with an established conference. If granted by other conferees, connecting party is added to conference.
3.5.3.7. Kim -- additional functions to consider (?): monitoring of, but not interactive participation in, conference by other room "occupants;" queuing of occupants for turns at establishing a conference, others?
3.6. Define QA specifications
3.6.1. Documentation specifications.
3.6.1.1. All project management plans and related documents will number text paragraphs and illustrative figures in accordance with IEEE document standards. Exceptions (if any) required to accommodate HTML conversion and posting to web site will be indicated to site visitors.
3.6.1.2 Progress and review document formats TBD. (If there's an IEEE standard format, we should tailor format and use it. Otherwise, would envision format as general comments appropriate to document purpose, then indicate--using numbered paragraphs--errors or descrepencies discovered, recommended corrective actions, actions taken, and results)
3.6.2. Error tracking specification. Log the following information using an Excel 5.0 spreadsheet
3.6.2.1. Error Number (numbered sequentially)
3.6.2.2. Error Name
3.6.2.3. Error Type
3.6.2.4. Short error description
3.6.2.5. Date error discovered
3.6.2.6. Name of person discovering error
3.6.2.7. Recommended remedial action
3.6.2.8. Date remedial action accomplished/reinspected
3.6.2.9. Date error closed
3.6.4. Other QA specifications (Help -- any ideas?)
WBS Element #: 3.1.2.2.
Task: Verification of Initial Site Directory Structure
LOE: 0.5 hours
Who: QA
Start Date: 2/17/97
Completion Date: 2/24/97
===========
WBS Element #: 3.1.3.2.
Task: Review/comment on original project planning documents
LOE: 31.5 hours (7 documents * 45 minutes/document * 6 members)
Who: All
Start Date: 1/27/97
Completion Date: 3/3/97
===========
WBS Element #: 3.1.3.2.
Task: Review/comment on revised project planning documents
LOE: 30 hours ( 10 documents * 10 minutes/document * 6 members * 3 revs)
Who: All
Start Date: 3/3/97
Completion Date: 4/14/97
===========
WBS Element #: 3.1.3.3.
Task: Review of final revisions to project planning documents (for site baseline)
LOE: 20 hours (10 documents * 20 minutes/document * 6 members)
Who: All
Start Date: 4/14/97
Completion Date: 4/21/97
===========
WBS Element #: 3.5.1
Task: Functional test of additional HTML links to site
LOE: 7.33 hours (10 minutes/link to test/log results * 44 links (primary + 10% regression test links))
Who: Test
Start Date: 2/17/97
Completion Date: 4/14/97
===========
WBS Element #: 3.5.3
Task: Functional test of "chat room" capability
LOE: 5 hours ( 1.25 hour/test * 4 members)
Who: Test, Developer, plus two "volunteers"
Start Date: 3/10/97 (or upon installation of capability on site)
Completion Date: 4/14/97
===========
WBS Element #: 3.1.2., 3.1.3. (Multiple cites)
Task: Weekly error tracking review
LOE: 12 hours (0.75 hour prep/conduct/document * 2 members * 8 weeks)
Who: Test, Developer
Start Date: 2/17/97
Completion Date: 4/14/97
===========
WBS Element #: 3.1.3.2., 3.1.3.3.
Task: Weekly review of internal documents (HTML Markup)
LOE: (10 docs * 5 revisions * ??)
Who: QA
Start Date: 2/3/97
Completion Date: 4/14/97
===========