A Simple SQA Plan

1
A Simple SQA Plan
2
Key Pointsfrom the Narrative

• process is ad hoc
• a lot of code reuse
• usability is very important
• accuracy and interoperability are problems
• testing is not formal at all
• little or no unit testing of reused modules

3
Suggestions

• Schedule time for and set milestones for
• FTRs
• Requirements
• Detailed Design
• Peer Reviews
• new code modules
• Unit Testing (black box)
• all code module
• Gather these procedures in an
  "SQA Guidelines" document
• When time and money permit, send off an
  interested person to FTR training

4
Suggested format forSQA Guidelines

1. Items to be Reviewed
2. Pass Fail Criteria
3. Responsibilities
4. Schedule of Tests and Reviews

5
SQA GuidelinesI. Items to be Reviewed

• System Requirements
• formal technical review consisting of
• facilitator in-house requirements guru from
  different group
• author Sue
• scribe Zack
• customer rep (or sample user if customer is not
  available)

6

• System Design
• FTR similar to above
• need to assign specific people
• Software Design
• FTR
• facilitator in-house designer from another group
• author Zack or The Other Bob
• scribe Tim or John
• member Tim or John

7

• All New Code Modules
• code walkthroughs
• black box testing
• All Reused Code Modules
• black box testing
• white box testing for automatic ordering module
• In the future, perhaps add
• User Interface
• Usability Testing

8
SQA Guidelines II. Pass Fail Criteria

• System Requirements
• completeness
• System Design
• need a checksheet which includes survey of users'
  environment
• Software Design
• need a checksheet

9

• New Code Modules
• need coding guidelines for walkthroughs
• black box - simple black box testing
• Reused Modules
• black box - boundary value analysis
• User Interface
• meets all usability criteria described in SRS
• be sure to use different browsers

10
SQA Guidelines III. Responsibilities

• Need to fill in this table
• Task Person Expected Completion

11
SQA Guidelines IV. Schedule for Tests and
Reviews

• SRS FTR - end of week 2
• System Design FTR - end of week 3
• Software Design FTR - end of week 4
• Unit Testing - scheduled throughout coding

12
Summary

• concentrate effort on problem areas
• requirements
• design
• new code
• insure completion by
• adding these tasks to the schedule as milestones,
  and
• assigning responsibility