What you will learn
By the end of this topic, you should be able to define the software quality assurance contribution; tailor lifecycle controls to product risk; plan independent reviews; assess requirements, traceability and anomalies; govern automated tools and records; establish objective release criteria; and maintain assurance through software changes and post-market support.
The software quality assurance role
Software quality assurance provides confidence that defined processes are suitable, followed and evidenced. It examines how software is planned, specified, implemented, verified, released and maintained. It does not “own quality” on behalf of developers: engineering remains accountable for technically sound work, while quality assurance supplies challenge, oversight and escalation.
Process adviser
Translate quality-system and lifecycle expectations into workable team practices.
Independent reviewer
Evaluate records and decisions with sufficient freedom from the work being reviewed.
Evidence steward
Confirm that traceability, approvals and objective records support the product claim.
Escalation partner
Make unresolved nonconformity and unacceptable release risk visible to decision-makers.
Plan assurance around the product and its risk
The assurance plan should identify applicable procedures, software safety classification, deliverables, review points, independence, tools, suppliers, acceptance criteria and escalation routes. Tailoring is legitimate when justified; silently omitting an activity is not. Align the plan with MTL-108 — Software Lifecycle and the wider development plan.
- Define what will be reviewed, when and by whom.
- State the required independence for each activity.
- Identify records that demonstrate completion and approval.
- Plan treatment of legacy software, third-party components and unresolved anomalies.
- Set measurable entry, exit and release criteria.
Assure the lifecycle, not just the final test
Quality assurance samples the connected system of plans, requirements, architecture, implementation, integration, verification, risk control, configuration and maintenance. A passing test result cannot compensate for an ambiguous requirement, uncontrolled build or incorrect product configuration.
Reviews need purpose, competence and independence
A signature is not evidence of an effective review. Define the question each reviewer must answer, give them the relevant inputs, record findings and ensure actions reach closure. Independence should be proportionate to risk and organisational scale; it may involve a different engineer, a quality representative or a separate verification group.
Use traceability to expose missing reasoning
Traceability should connect intended use, requirements, hazards, risk controls, architecture, implementation, verification and released configuration. Quality assurance checks both directions: every required behaviour has evidence, and every implemented behaviour has a justified origin. MTL-116 — Verification and Validation explains the broader evidence model.
Treat anomalies as controlled product knowledge
Defects, deviations and test exceptions need classification, investigation, impact assessment and disposition. A deferred anomaly should identify affected versions, safety and security implications, clinical impact, workarounds, communication needs and the authority accepting residual risk. Trend recurring causes into corrective and preventive action where appropriate.
Automation accelerates work but does not remove control
Continuous integration, static analysis, test frameworks and requirements platforms can strengthen consistency. Define their intended use, access, configuration, version, failure detection and backup. Validate or otherwise establish confidence in a tool according to the risk that an erroneous result could go undetected. Retain durable, attributable records rather than relying on transient dashboards.
Make release readiness an evidence-based decision
- Required reviews and tests are complete and approved.
- The released binary is reproducibly linked to controlled source and dependencies.
- Known anomalies have documented impact and disposition.
- Risk controls and cybersecurity evidence match the release candidate.
- Installation, rollback, labelling and service information are ready.
- Approval authority and any conditions of release are recorded.
Use MTL-312 — IEC 62304 Software Lifecycle for the standard’s lifecycle framework.
Continue assurance through maintenance and retirement
Complaints, vulnerabilities, telemetry, service information and supplier notices can trigger investigation and change. Ensure maintenance uses controlled problem resolution, impact analysis, regression testing and release records. End-of-support decisions should address installed versions, data retention, cybersecurity, customer communication and safe transition.
Common misconceptions
“Quality assurance is the testing team.”
Testing contributes evidence; assurance evaluates the integrity of the entire lifecycle and its controls.
“A checklist proves compliance.”
A checklist helps consistency only when reviewers understand the evidence and resolve substantive findings.
“Agile development conflicts with medical-device control.”
Iterative work can be controlled when requirements, risk, configuration, review and evidence remain explicit.
Authoritative starting points
Software assurance makes confidence inspectable
Connect risk, lifecycle discipline, objective review and the exact released configuration into one coherent evidence trail.