The SQA PLAN provides a road map for instituting software quality assurance. Developed by the SQA group (or by the software team when no separate group exists), it serves as a template for SQA activities that are instituted for each software project. IT ANSWERS FIVE QUESTIONS, and if it answers them nothing else is strictly required: WHAT will be checked? (the work products) AGAINST WHAT? (the standards and criteria) BY WHOM? (roles and responsibilities) WHEN? (the point in the process) AND WHAT HAPPENS when it fails? (the deviation procedure) THE IEEE 730 STRUCTURE for a software quality assurance plan — the standard outline, and the one to reproduce: 1. PURPOSE AND SCOPE what this plan covers, which project and which parts 2. REFERENCE DOCUMENTS the standards, procedures and other plans it depends on 3. MANAGEMENT organisation, tasks and responsibilities — the SQA organisational structure, the tasks to be performed and their placement in the process, and the roles and reporting relationships. Critically, the INDEPENDENCE of the SQA function. 4. DOCUMENTATION the documents to be produced, and the reviews and audits each will receive. Typically: the SRS, the design description, verification and validation plans, user documentation, and the configuration management plan. 5. STANDARDS, PRACTICES AND CONVENTIONS which documentation, coding, commenting and testing standards apply, and the metrics to be collected 6. REVIEWS AND AUDITS the reviews to be conducted, and for each: its purpose, who attends, and its entry and exit criteria. Typically includes the software requirements review, design reviews, code reviews, test plan review, and the audits. 7. TEST reference to the software test plan and procedure, or the test approach where no separate plan exists 8. PROBLEM REPORTING AND CORRECTIVE ACTION how defects are reported, classified, tracked and closed, and the organisational responsibilities for each step 9. TOOLS, TECHNIQUES AND METHODOLOGIES the SQA tools — test harnesses, static analysers, coverage tools, metrics collection 10. CODE CONTROL the methods and facilities used to maintain and store controlled versions of the identified software 11. MEDIA CONTROL protection of the physical media from unauthorised access or damage, and provision for retention 12. SUPPLIER CONTROL provisions for assuring that software provided by suppliers meets requirements — the CBSE trustworthiness problem, given a procedure 13. RECORDS COLLECTION, MAINTENANCE AND RETENTION which SQA documentation is retained, how, and for how long 14. TRAINING the training necessary to meet the plan's needs 15. RISK MANAGEMENT the methods and procedures for identifying, assessing, monitoring and controlling risk areas ITEMS 10, 11 AND 12 ARE WORTH NOTING: code control, media control and supplier control are configuration management concerns, which is why the SQA plan and the configuration management plan reference each other. Quality and change control are inseparable — you cannot assure the quality of something you cannot identify a version of.

Rather than the whole document, take ONE ROW and see what a usable plan actually specifies. The reviews-and-audits table for the licence system: ───────────────────────────────────────────────────────────── WORK PRODUCT Software Requirements Specification REVIEW TYPE formal technical review (inspection) ENTRY CRITERIA the SRS is complete with no "TBD" markers; the glossary is populated; the author has run the completeness checklist PARTICIPANTS requirements author (producer), one customer representative, the lead architect, one test engineer, a recorder — 5 people PREPARATION each reviewer reads the SRS against the checklist; ≤2 hours CHECKLIST is every requirement verifiable? is the invalid -input case specified? is each requirement uniquely numbered and traceable to a source? are there conflicting requirements? is any design decision leaking in? EXIT CRITERIA all major issues resolved or scheduled; the issues list is closed or assigned; all attendees have signed off METRICS Ep, Ea, Er, WPS, minor and major errors found; error density and review rate computed DEVIATION if the SRS enters review with TBD markers, the review is POSTPONED, not conducted — reviewing an incomplete product wastes five people's preparation ───────────────────────────────────────────────────────────── NOTE THE TEST ENGINEER IN THE PARTICIPANT LIST. That is deliberate, and it is the single most valuable staffing choice in the table: the person who must later write tests from this document is the one who will notice that a requirement cannot be tested. Recall from the SRS topic that verifiability subsumes much of the other quality properties. AND NOTE THE ENTRY CRITERIA. A review with entry criteria is a quality gate; a review without them is a meeting. The "postpone rather than conduct" deviation rule is what gives the entry criteria teeth. THE DEFECT CLASSIFICATION SCHEME — part of item 8, and worth specifying explicitly because everyone assumes a shared understanding they do not have: SEVERITY what the defect does CRITICAL data loss, security breach, or the system is unusable; no workaround MAJOR a major function fails or produces wrong results; a workaround may exist MINOR a function behaves incorrectly but the impact is limited and a workaround is easy COSMETIC spelling, layout, wording PRIORITY when it will be fixed P1 immediately, blocking release P2 before the next release P3 scheduled into the backlog P4 fix if convenient SEVERITY AND PRIORITY ARE INDEPENDENT, and conflating them is a standard error. A cosmetic defect on the login page's title can be P1 (it says the wrong company name and every user sees it); a critical defect in a feature used by two people once a year can be P3. SEVERITY IS A TECHNICAL JUDGEMENT; PRIORITY IS A BUSINESS ONE — which is why they are assigned by different people. THE DEFECT LIFECYCLE the plan must define: NEW → TRIAGED (severity + priority assigned) → ASSIGNED → FIXED → VERIFIED → CLOSED with side states: REJECTED (not a defect), DUPLICATE, DEFERRED, CANNOT REPRODUCE The "cannot reproduce" state deserves a rule: three occurrences of the same cannot-reproduce report is a defect, not three non-defects, and a plan that does not say so loses real problems.

HOW MUCH SQA IS APPROPRIATE? The plan should be proportionate, and the standard driver is RISK. A RISK-BASED SIZING TABLE, for the same 15-section structure: system type review depth test depth ───────────────────────────────────────────────────────── internal tool, 3 users peer desk check unit + smoke business system, FTR on requirements unit + hundreds of users and architecture integration + system + UAT financial / regulated FTR on all work the above + system products, audited independent V&V, audit trail tests safety-critical inspection with the above + measured rates, MC/DC coverage, formal methods on statistical the critical core certification THE PRINCIPLE: SQA EFFORT SHOULD BE PROPORTIONAL TO THE COST OF FAILURE, not to the size of the project. A small system that moves money deserves more scrutiny than a large internal reporting tool. QUANTIFYING IT — expected cost of failure: expected loss = probability of failure × cost per failure For a licence system processing 200,000 applications a year, if a fee-calculation defect affects 0.5% of applications at an average error of NPR 400, and takes 3 months to detect: affected = 200,000 × 0.005 × (3/12) = 250 applications direct loss = 250 × 400 = NPR 100,000 plus: manual correction of 250 records at 20 minutes each = 83 person-hours plus: reputational and audit cost, not quantifiable but real Against that, an extra review of the fee-calculation module costs perhaps 6 person-hours. THE REVIEW IS OBVIOUSLY WORTH IT, and writing the calculation down is how you win the argument for it. THE FAILURE MODES OF SQA PLANS — know these, because they are what makes plans useless in practice: THE PLAN NOBODY READS A 60-page document written to satisfy a process requirement, filed, and never opened. The test: can a new team member find out what standards apply to their code in under two minutes? If not, the plan is not functioning regardless of its completeness. THE PLAN THAT DESCRIBES ASPIRATIONS It specifies reviews that never happen and metrics nobody collects. This is worse than an honest smaller plan, because it makes the records false — and it teaches the team that the quality process is fiction. UNCLEAR OWNERSHIP "Reviews will be conducted" — by whom, and who notices if they are not? Every activity in the plan needs a named role, and a consequence for omission. NO DEVIATION PROCEDURE The plan says code will be reviewed before merge. Then a critical production fix is needed at 2 a.m. If there is no documented exception path, someone will bypass the process informally, and the informal bypass becomes the norm. A GOOD PLAN SPECIFIES ITS OWN EXCEPTIONS — for example: an emergency fix may merge with one approver, and MUST receive a full review within 24 hours, recorded. METRICS WITHOUT FEEDBACK Data is collected and never reported back to the people who collected it — which violates the metrics etiquette from the framework topic and guarantees the collection degrades. THE PRACTICAL TEST OF A GOOD SQA PLAN: it should be shorter than people expect, specify who and when for every activity, contain its own exception procedure, and be enforced by tooling wherever tooling can enforce it. A rule a machine checks costs nothing to follow; a rule in a document costs an argument every time.