The Software Quality Assurance Plan
Chapter Eighty-Seven
Syllabus topic Module 2, "Software Quality Assurance: ... Activities and approaches in Software Quality Assurance"
Pages 506 to 511 of 622
In one line
A software quality assurance plan says, before the work starts, what quality assurance will do on a project and how: its purpose and scope, its activities and methods, the people, resources and reporting lines, the standards to be audited and when, how noncompliances are tracked and escalated, the measures to be reported, what the assurance products must contain to be accepted, and how the plan itself is changed.
In the wording a student can write in an examination: the software quality assurance plan (SQAP) is the document that defines the SQA activities for a project. IEEE 730 sets requirements "for initiating, planning, controlling, and executing" a project's SQA processes; its current edition is IEEE 730-2026. NASA's handbook describes the same document in public: the plan "provides insight into the methods, approaches, responsibilities, and processes for the assurance activities of all life cycle and mission phases". It covers the introduction (purpose, scope, overview), the activities and methods, the stakeholders, resources, roles and organisation, data management and acceptance criteria for its products, risk and safety, training and communication, the metrics, issue tracking, a glossary, the change procedure and the schedule; a topic that does not apply is marked not applicable rather than left out.
Why assurance needs a plan of its own
Chapter Eighty-Six, on SQA activities, showed what the SQA group does. Each of those activities needs decisions made in advance: which processes and work products will be evaluated, against which criteria, when, by whom, and to whom the findings go. CMMI's process area on quality assurance says those decisions come first: "Quality assurance should begin in the early phases of a project to establish plans, processes, standards, and procedures that will add value to the project". The SQA plan is where they are written down, agreed with the project and management, and made checkable.
A plan also protects the assurance function's objectivity. When the reporting line, the escalation path and the audits are agreed before any finding exists, nobody can argue later that an unwelcome audit was improvised.
The SQA plan is not the test plan. A test plan is a "detailed description of test objectives to be achieved and the means and schedule for achieving them, organized to coordinate testing activities" (ISO/IEC/IEEE 29119-2:2021), the document of Chapter Eleven, on writing a test plan. The SQA plan covers the assurance of every process, testing among them: one of its audits checks that the test plan is being followed.
What a plan contains
IEEE 730-2026 and its 2014 predecessor define a plan's content, but both are sold by the IEEE and neither is on disk for this book, so it does not reproduce their outline; a textbook may show one from an earlier edition. NASA's Software Engineering Handbook publishes an equivalent outline, the "minimum recommended content for a Software Assurance Plan (SAP)", and the table groups its topics.
The Software Quality Assurance Plan
| Group | Topics (NASA's minimum content) | What the plan states |
|---|---|---|
| Introduction | Purpose; scope; overview | Why the plan exists, what it covers, how it is organised |
| The work | Assurance activities; assurance methods | Planned audits and assessments, status reporting, analyses; how they are done (reviews attended, products and processes reviewed, tests witnessed, issues reported) |
| The people | Stakeholders; resources; roles and responsibilities; organisation and management; training; communication | Who is involved; the staff, tools and access SQA needs; who does what; to whom SQA reports; what SQA staff must learn; how findings travel |
| The products | Data management; acceptance criteria | The assurance products, where they are stored and for how long, and when each is accepted |
| Risk | Safety-critical assessment (if needed); risk management | Whether the software is safety-critical; how risks SQA finds are handled |
| Control | Requirements mapping; metrics; issue tracking and reporting | What will be checked against what; the measures and how they are reported; how problems are reported, tracked and resolved |
| Housekeeping | Acronyms; glossary; change procedure and history | Terms; how the plan is changed and its history kept |
| Time | Schedule | The assurance activities and audits, aligned with the project's schedule and milestones |
Two rules in the handbook matter as much as the list. "If a content section does not apply", the plan says so, marked not applicable, instead of silently leaving it out: an absent topic could be an oversight, and a marked one is a decision. And the schedule must align the audits "with the project schedule, milestones, and life cycle products", because an audit held after the milestone it should inform is too late to matter.
Two of NASA's entries belong to NASA's own rules: a classification of the software under NASA's procedural requirements, and a matrix mapping NASA's requirements to assurance tasks. A plan outside NASA replaces the first with its own statement of how critical the software is, and the second with the list of standards and procedures the project must follow and the audits that check each one. ExamReg's plan does exactly that.
Worked example: reviewing ExamReg's plan
ExamReg's SQA engineer wrote a first draft of the plan for release 2.0, one line per topic followed by the standards to be audited and the audit schedule. Reviewing a plan is itself quality assurance, and two checks are mechanical enough for a program: does the plan address every required topic, and does every standard the project must follow have an audit that checks it? The program reads draft 1, then draft 1 with the two changes the review led to.
The Software Quality Assurance Plan
# ExamReg release 2.0: software quality assurance plan, draft 1 (one line per topic)
purpose: assure that release 2.0 follows its planned processes, and report the results objectively
scope: release 2.0 of ExamReg, all seven modules, from the requirements review to the release
overview: one line for each topic, then the standards to be audited and the audit schedule
activities: the process audits below; a status report every two weeks; a trend report at release
methods: audits against checklists; attending requirements and design reviews; desk audits of code
stakeholders: the exam cell; the project lead; the test lead; the head of delivery
resources: one SQA engineer, one day a week; read access to the repository and defect tracker
roles: SQA audits and reports; the project lead resolves noncompliances; escalations go up
organisation: the SQA engineer reports to the head of delivery, not to the project lead
data management: audit reports and the noncompliance log, in version control, kept three years
safety: not applicable; ExamReg controls no physical process and endangers no one
risk management: risks that SQA finds go on the project's risk register
training: the SQA engineer is trained in the coding standard and the review procedure
communication: findings to the project lead in two days; open issues reviewed fortnightly
metrics: compliance per audit; noncompliances by process; days to resolve; escalations
issue tracking: noncompliance log NC-nn; resolved in the project, or escalated after 14 days
glossary: SQA software quality assurance; NC noncompliance; V(G) cyclomatic complexity
change procedure: changes approved by the head of delivery and recorded with their date
schedule: each audit is held in the phase it checks, before that phase's exit review
standard: requirements template
standard: review procedure
standard: coding standard
standard: unit test standard
standard: configuration management procedure
standard: defect tracking procedure
standard: test reporting procedure
standard: release procedure
audit: requirements; requirements review; requirements template, review procedure
audit: design; design review; review procedure
audit: coding; coding standard; coding standard
audit: testing; unit testing; unit test standard
audit: testing; defect tracking; defect tracking procedure
audit: testing; test reporting; test reporting procedure
audit: release; release readiness; release procedureacceptance criteria: an audit report is accepted when each finding has an NC number and an owner
audit: testing; configuration management; configuration management procedure# the topics a plan must address: NASA's minimum content (SWEHB Topic 5.17), adapted for ExamReg
REQUIRED = ["purpose", "scope", "overview", "activities", "methods", "stakeholders", "resources",
"roles", "organisation", "data management", "acceptance criteria", "safety",
"risk management", "training", "communication", "metrics", "issue tracking",
"glossary", "change procedure", "schedule"]
def read(*paths):
plan, standards, audits = {}, [], []
for path in paths:
with open(path) as f:
for line in f:
if line.startswith("#") or not line.strip():
continue
key, value = (part.strip() for part in line.split(":", 1))
if key == "standard":
standards.append(value)
elif key == "audit":
phase, name, checks = (part.strip() for part in value.split(";"))
audits.append((phase, name, [c.strip() for c in checks.split(",")]))
else:
plan[key] = value
return plan, standards, audits
for draft, paths in [("draft 1", ["examreg-sqa-plan.txt"]),
("draft 2", ["examreg-sqa-plan.txt", "draft-2-changes.txt"])]:
plan, standards, audits = read(*paths)
missing = [topic for topic in REQUIRED if topic not in plan]
audited = {s for _, _, checks in audits for s in checks}
unaudited = [s for s in standards if s not in audited]
print(f"{draft}: {len(audits)} audits for {len(standards)} standards")
print(f" topics missing: {', '.join(missing) or 'none'}")
print(f" standards with no audit: {', '.join(unaudited) or 'none'}")The Software Quality Assurance Plan
draft 1: 7 audits for 8 standards
topics missing: acceptance criteria
standards with no audit: configuration management procedure
draft 2: 8 audits for 8 standards
topics missing: none
standards with no audit: noneDraft 1 had two gaps. It never said when an assurance product counts as done, so a vague audit report could not be sent back; and the project's configuration management procedure, which governs how builds are tagged and what is under version control, had no audit at all. Neither gap is visible by reading the plan line by line, because nothing on the page is wrong; both are things that are absent.
Draft 2 adds an acceptance criterion for audit reports, that each finding has a noncompliance number and an owner, and a configuration management audit during testing. It addresses all twenty topics and audits all eight standards. The change mattered: the configuration management audit, when it was held, found the two noncompliances NC-09 and NC-10, one of which had to be escalated (Chapter Eighty-Six, on SQA activities). Without draft 2, nobody would have looked.
The program checks only what can be checked mechanically. Whether one day a week is enough SQA effort, whether 14 days is the right time before escalation, whether the checklists behind each audit are any good: those are judgements, for the head of delivery and the project lead to make when they approve the plan.
Reading ExamReg's plan against the outline
A few lines of the plan show what each topic asks for in practice.
- Safety: not applicable, with a reason. ExamReg controls no physical process; the plan says so instead of omitting the topic.
- Organisation. The SQA engineer reports to the head of delivery, not to the project lead whose work is audited: the managerial independence of Chapter Twenty-Five, on quality management and SQA, written into the plan.
- Issue tracking. A numbered noncompliance log, resolution in the project first, escalation after 14 days: the rules of CMMI's practice for resolving noncompliance, turned into ExamReg's procedure.
- Metrics. The four measures that the program of Chapter Eighty-Six, on SQA activities, computed, decided before the first audit, so the report at release uses definitions agreed at the start.
- Change procedure. Draft 2 itself went through it: approved by the head of delivery and recorded with its date.
The Software Quality Assurance Plan
What it does not mean
The SQA plan is not the test plan. The test plan organises testing; the SQA plan organises the assurance of all the processes, testing included.
A plan is not finished when it is written. It is reviewed, approved, and changed under its own change procedure as the project learns, as draft 2 shows.
Not applicable is not the same as missing. A topic that does not apply is marked so, with the reason; a topic left out is a gap.
Completeness is not adequacy. A plan can mention every topic and still assign too little effort or weak checklists; a program can find gaps, and only people can judge sufficiency.
Quick revision
- SQAP (IEEE 730-2014, now IEEE 730-2026): the plan that defines a project's SQA activities; written early, as CMMI says QA "should begin in the early phases of a project".
- Contents (NASA's minimum content, Topic 5.17): purpose, scope, overview; activities and methods; stakeholders, resources, roles, organisation, training, communication; data management and acceptance criteria; safety assessment and risk management; requirements mapping, metrics, issue tracking; acronyms, glossary, change procedure; schedule.
- Rules: mark a topic that does not apply as not applicable; align audits with milestones.
- Against the test plan: the test plan covers testing; the SQA plan covers assurance of all processes.
- Worked example: draft 1 missed acceptance criteria and had no configuration management audit; draft 2 addressed all 20 topics and audited all 8 standards; the added audit found NC-09 and NC-10.
Test yourself
1. What is a software quality assurance plan, and why is it prepared at the start of a project? The document that defines what quality assurance will do on a project and how: activities, methods, responsibilities, reporting lines, the standards to be audited and the schedule. It is prepared early because evaluations need criteria and a schedule agreed in advance, because QA helps set up the processes it will later check, and because an agreed reporting and escalation path protects its objectivity.
2. List the main contents of an SQA plan. Introduction (purpose, scope, overview); the assurance activities and methods; stakeholders, resources, roles and responsibilities, organisation, training and communication; data management and acceptance criteria for the assurance products; safety assessment and risk management; the standards to be checked, the metrics and issue tracking; acronyms, glossary and the change procedure; and the schedule of assurance activities and audits.
The Software Quality Assurance Plan
3. How does an SQA plan differ from a test plan? A test plan describes the objectives, means and schedule of testing for a test item. An SQA plan describes the assurance of all the project's processes and products, including testing, by audits and reviews against standards; one of its audits checks that the test plan is followed.
4. Why must a plan state "not applicable" rather than leave a topic out? Because an absent topic cannot be told apart from an oversight, while a topic marked not applicable, with a reason, records a decision that a reviewer can check.
5. What did the review of ExamReg's draft plan find, and why did it matter? The draft had no acceptance criteria for assurance products and no audit of the configuration management procedure. Draft 2 added both. The configuration management audit later found two noncompliances, one of which had to be escalated; without the change it would not have been held.
6. Which parts of a plan's review can be automated, and which cannot? Mechanical checks can: whether every required topic is present and whether every standard has an audit scheduled. Judgements cannot: whether the effort assigned is enough, whether the escalation time is right, and whether the checklists are good; those are for the people who approve the plan.
The rest of this subject
These notes are cut from the University's printed syllabus. Open the syllabus itself, or the past papers, for the same subject.