Who Is Responsible for Software Quality Management?
Software quality management is shared across leadership, product stakeholders, developers, testers, and project managers. Learn how to assign the work and make quality decisions explicit.
Software quality management is a shared organizational responsibility. Leaders set priorities and provide resources; product stakeholders and acquirers define needs and acceptance criteria; developers build and test toward those needs; testers verify and validate; and project managers plan and monitor the work. A QA or quality group can provide methods, training, and guidance, but it cannot take responsibility for product quality on everyone else’s behalf.
The practical answer is to assign ownership for each quality decision and activity: who defines requirements, who produces evidence, who accepts that evidence, who approves release, and who accepts remaining risk. Standards provide useful role categories, not a universal company org chart or release-approval rule.
What software quality management includes
Software quality management is the set of organizational activities used to define expected quality, plan how to achieve and evaluate it, examine evidence, and improve the methods used across the product lifecycle. It covers more than testing at the end of development.
ISO/IEC 25010:2023 defines a product quality model applicable to ICT and software products. It includes nine quality characteristics and their subcharacteristics. The model can support requirements, design and testing objectives, quality-control criteria, acceptance criteria, and measures throughout the lifecycle. The standard identifies developers, acquirers, quality assurance and control staff, and independent evaluators among the stakeholders who may use it.
ISO/IEC 25030:2019 provides a framework for quality requirements, including how they are elicited, defined, used, and governed. Together, these standards help teams describe the work without prescribing one mandatory staffing or reporting structure.
Who is responsible for each part?
| Role | Practical responsibility | Boundary to make clear |
|---|---|---|
| Organizational leadership | Set quality policy and priorities, allocate resources, assign decision rights, and review whether the quality system is effective. | Standards address planning and management, but do not require a particular reporting line or org chart. |
| Product stakeholders and acquirers | Express user, business, and operational needs; decide what acceptable quality means for intended use; assess whether the result delivers expected value. | They need to define acceptance criteria early enough for design and evaluation to use them. |
| Developers and engineering teams | Design, implement, and test the product to meet expected quality; build quality considerations into architecture and delivery. | Quality is part of implementation work, not a handoff that begins when code is complete. |
| Testers | Verify and validate that the software meets expected quality requirements, using defined evidence and methods. | Testing reports evidence against criteria; it does not by itself decide which business risks the organization accepts. |
| Project managers | Plan, monitor, and control the work needed to achieve expected quality, including dependencies and schedule. | Quality activities need time and resources in the plan, rather than being treated as optional work after feature delivery. |
| Independent evaluators | Assess the software against objective criteria when independent evaluation is needed. | The required degree of independence depends on product context and risk; the cited standards do not mandate one arrangement for every team. |
| QA or evaluation group | Provide methods, documentation, training, technical guidance, and help build evaluation capability. | This group enables organization-wide quality work; it does not replace the responsibility of those who define, build, manage, and accept the product. |
These role activities are described in ISO/IEC 25030:2019; the lifecycle use of the quality model is described in ISO/IEC 25010:2023. The role map is a practical interpretation, not a prescribed org chart.
Quality assurance, quality control, and testing are related but distinct
Quality assurance (QA) focuses on confidence in the processes and methods used to specify, build, and evaluate software. A QA function may establish guidance, train teams, maintain documentation, and help select evaluation methods.
Quality control and testing examine a product or its outputs against defined requirements and criteria. Testing produces evidence about behavior and quality; verification and validation help determine whether requirements are met and whether the software serves its intended use.
Both activities are necessary, and both support shared ownership. Assigning a QA department does not make developers less responsible for implementation quality, nor does assigning testing to developers remove the need to define acceptance and risk decisions.
How to make ownership explicit
- Describe the intended use and context. Identify users, operating conditions, interfaces, business needs, and consequences of failure. Quality priorities depend on the product and its environment.
- Turn needs into quality requirements. State observable expectations and how they will be evaluated. Use the ISO/IEC 25010:2023 model as a reference for characteristics to consider; select what matters for this product instead of treating every characteristic as equally important.
- Name an owner for each requirement. Record who clarifies it, who implements it, who gathers evidence, and who accepts the result. A single person may hold multiple roles on a small team, but the responsibilities should still be explicit.
- Plan evaluation alongside delivery. Include test methods, environments, data, dependencies, review points, and time in the project plan. Decide when independent evaluation is appropriate.
- Set release and risk authority. Specify who can accept evidence, approve a release, waive a criterion, and accept residual risk. The cited standards do not assign these powers for every organization, so local governance must do so.
- Review results and improve the system. Examine defects, escapes, changing requirements, and evaluation gaps. Update requirements, methods, documentation, and training where the evidence shows a need.
A compact responsibility checklist
- Each quality requirement has a clear owner and evaluation method.
- Acceptance criteria are defined before the relevant work is considered complete.
- Developers know the quality expectations that shape design and implementation.
- Testers can report evidence and unresolved gaps in terms decision-makers understand.
- Project plans include time and dependencies for quality activities.
- Release approval, waivers, and risk acceptance have named decision-makers.
- QA or evaluation specialists have a defined remit to support teams and improve methods.
Choosing a responsibility model
There is no single correct team structure. Compare possible arrangements using the work and decisions they need to cover:
| Question | What to decide |
|---|---|
| Decision ownership | Who defines objectives, accepts evidence, approves releases, and accepts residual risk? |
| Execution | Who builds quality into the product, and who performs verification and validation? |
| Independence | Is evaluation done by the delivery team, a separate internal function, or an independent evaluator? |
| Lifecycle coverage | Are requirements addressed through elicitation, design, testing, acceptance, operation, and maintenance? |
| Capability and support | Who maintains methods, tools, documentation, and training? |
| Product context | Which quality characteristics matter most to users, operating conditions, and the risk profile? |
These are decision prompts derived from the stakeholder activities in ISO/IEC 25010 and ISO/IEC 25030, not a mandatory scoring system. Small teams may combine roles; higher-risk products may need more formal evidence and independent review. The arrangement should make accountability visible without confusing job titles with the actual work.
Common gaps and how to fix them
| Symptom | Likely cause | Practical fix |
|---|---|---|
| “QA owns quality” but teams disagree about readiness | Quality requirements, acceptance criteria, or release authority were never assigned. | Name owners for requirements, evidence review, release approval, waivers, and risk acceptance. |
| Testing starts after implementation and finds basic expectation gaps | Evaluation was treated as a late phase, or requirements were not testable. | Define evaluation methods and acceptance criteria while eliciting and refining requirements. |
| Teams report many tests but cannot explain whether the product is acceptable | Test activity is not tied to quality requirements and decision criteria. | Map evidence to explicit criteria and report gaps, uncertainty, and residual risk to the authorized decision-maker. |
| Quality work is repeatedly cut to meet dates | Plans omitted quality tasks, dependencies, or resources, or trade-offs lack an owner. | Project managers plan and track quality work; leadership makes priorities and risk decisions explicit. |
| A specialist group becomes a bottleneck | Methods and expertise are centralized without building team capability or clarifying what needs independent review. | Let the QA or evaluation group provide reusable guidance and training; define when its review is needed and let delivery teams own routine quality work. |
| Standards are cited as if they assign a company’s release approver | A quality model or requirements framework is being mistaken for local governance. | Use the standards to structure requirements and roles, then document local approval and risk authority separately. |
Standards and edition notes
- ISO/IEC 25010:2023 is the current product quality model in this guide. It supersedes ISO/IEC 25010:2011. The 2023 edition has nine product quality characteristics; do not carry over the 2011 model’s characteristic count.
- ISO/IEC 25001:2014 covers planning and management of quality requirements specification and evaluation. ISO’s page says it was reviewed and confirmed in 2026. It describes an evaluation group’s contribution, including motivating and training employees, preparing documents, identifying or developing methods, and answering technology questions.
- ISO/IEC 25030:2019 provides the quality requirements framework and names acquirers, developers, testers, project managers, and independent evaluators as intended readers.
The standards describe frameworks and stakeholder activities. They do not determine a specific organization’s internal reporting lines, legal liability, staffing model, or final release authority. Those details depend on the organization, product, contractual setting, and applicable rules.
Or skip the browser setup
When quality work includes capturing web pages as review evidence or test artifacts, [ScreenshotNeo](https://screenshotneo.com) can return a screenshot or PDF with one API request. Its cookie handling is also useful when a page capture should show content without consent banners, newsletter popups, or chat widgets. See the ScreenshotNeo API documentation for options and request parameters.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots, and 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month.
FAQ
Is a QA manager accountable for every defect?
No single title can own every product decision and activity. A QA manager may lead methods and evaluation capability, while product, engineering, testing, and leadership roles retain their responsibilities.
Can developers test their own work?
Yes. Developers have a role in testing what they build. Teams can add separate or independent evaluation where the product’s context and risks call for it.
Does ISO/IEC 25010 tell a company who must approve a release?
No. It provides a product quality model and lifecycle reference. Organizations need to assign their own release and risk decision rights.
Who is responsible when quality requirements conflict with a deadline?
The project manager should make the schedule and quality work visible, while the organization’s designated decision-maker resolves trade-offs and accepts any residual risk. The decision authority should be documented locally.
