Collaborative Development: How Quality Advocates Improve Software Quality

A quality advocate helps a cross-functional team make quality visible throughout development. They bring testing expertise into conversations early, clarify risks and acceptance criteria, coach teammates, and help the team choose useful checks. The role does not make one person responsible for quality: developers, product partners, and delivery teammates all contribute to it.

In practice, a quality advocate might help turn an ambiguous feature request into testable examples, pair with a developer on an automated check, explore edge cases with the team, and make system qualities such as performance visible before release. Testing remains essential; its timing and ownership become more collaborative.

What is a quality advocate?

A quality advocate is a quality specialist or champion embedded in a delivery team. Depending on the organization, it may be a dedicated role or a set of responsibilities taken on by a tester or quality engineer. There is no single standard job design: the term is a proposed framing in some writing, an embedded practice in some organizations, and a job title in some employers.

Alister Scott describes the idea as a person who “advocates quality” in an agile team, while emphasizing that quality remains everyone’s responsibility (Scott, “Quality Advocate”). World Wide Technology describes its advocate as an expert and mentor within a team that treats quality as a whole-team concern (WWT, “Why Do We Use Embedded Quality Advocates in Agile Application Development?”).

Advocate, tester, and gatekeeper

Approach	Typical focus	Effect on collaboration
Quality advocate	Brings risk, testability, user behavior, and quality practices into the team’s ongoing work.	Encourages shared learning and feedback while work is in progress.
Testing specialist working in a silo	Receives completed work for concentrated test execution.	Can provide valuable findings, but questions may arrive after implementation decisions are harder to change.
Quality gatekeeper	Acts as the final person or role that approves or rejects work.	Can make quality appear to belong to one individual and leave others waiting for approval.

These are patterns, not universal job descriptions. A quality advocate may still perform manual, automated, exploratory, and acceptance testing. The distinction is that testing expertise is applied throughout development, and the specialist helps the team build its own quality skills instead of becoming the only person expected to find problems.

What does a quality advocate do?

The precise work depends on the product, team, and risks. The activities below are a practical menu drawn from practitioner guidance and role descriptions, not a mandatory checklist.

During discovery and refinement

• Ask who the feature serves and what successful behavior looks like.
• Help make acceptance criteria specific enough to discuss and verify.
• Surface ambiguity, dependencies, assumptions, and user-visible failure cases.
• Prompt consideration of relevant system qualities, such as performance, accessibility, security, or resilience, where the product’s needs call for them.

During design and implementation

• Join design or code walkthroughs and raise quality risks while the relevant people are available.
• Pair with developers on unit, integration, or other automated checks.
• Help the team decide where automation gives useful, maintainable feedback and where exploratory testing adds more value.
• Share domain knowledge, test techniques, and tools so quality work does not remain isolated in a QA silo.

During integration, delivery, and learning

• Help review automated pipeline checks and their failures.
• Explore the integrated feature against user goals, edge cases, and agreed acceptance criteria.
• Use operational feedback and recurring incidents to identify risks or missing checks.
• Help the team reflect on how its quality practices are working and try a specific improvement.

Quality engineering can span story and acceptance-criteria review, design and code review, nonfunctional requirements, automated pipeline checks, operational feedback, and unit, integration, exploratory, and acceptance testing. These are possible contributions, not a universal responsibility list (Michael Sowers, TechWell, “Quality Engineering in Agile and DevOps”).

How collaboration improves the feedback loop

1. Discuss the behavior before implementation is finished. Product, development, and quality perspectives can expose different interpretations of a request. Clarifying these while the feature is being shaped gives the team a chance to resolve uncertainty together.
2. Make examples concrete. A testable example helps the team agree on expected behavior, including relevant failure paths, instead of relying on a broad phrase such as “works correctly.”
3. Choose checks together. Developers can add checks close to the code, while a quality specialist contributes test design and exploratory techniques. The aim is useful coverage and timely feedback, not maximum test count.
4. Learn from results as a team. When a check fails or exploration finds a problem, the team can examine the cause and decide whether its implementation, assumptions, or checks need to change.

WWT describes advocates building trust with other project roles, asking questions in real time, pairing, and sharing domain knowledge. Rebecca Wirfs-Brock likewise discusses early engagement and attention to both functionality and system qualities (“QA to AQ Part Three”). These sources describe recommended practices and experience; they do not establish a controlled estimate of how much the role changes defect rates, delivery speed, or customer outcomes.

A practical workflow for introducing the role

1. Agree on the purpose. Explain that the advocate helps the team build quality into its work; the role is not a final approval authority.
2. Join early. Involve the advocate during discovery or refinement where possible, then keep them engaged through implementation and delivery.
3. Choose one feature to practice. Review its user goal, acceptance examples, likely risks, and relevant automated or exploratory checks with the team.
4. Pair and coach in the work. Work alongside developers and product partners. Demonstrate techniques, explain reasoning, and invite others to contribute rather than taking every quality task away.
5. Make responsibilities explicit. Clarify who writes and maintains checks, who investigates failures, how risks are raised, and what the team means by done.
6. Review and adjust. Ask whether questions surfaced early, whether checks gave useful feedback, and whether any process step became a bottleneck. Choose a small change and review its effects later.

A current Ncontracts role description gives one example of an advocate defining features from users’ perspectives, writing tests the team can execute, and working with developers on automation (Ncontracts, “Quality Advocate – L3”). Treat it as one employer’s description, not a standard for every team.

Dedicated advocate or shared responsibilities?

There is no evidence in the cited sources that one staffing model is best for every organization. Consider these questions when choosing how to organize the work:

Decision	Questions to ask
Dedicated embedded advocate or shared quality-engineering work	Does the team need sustained specialist coaching, or can existing teammates reliably share the needed expertise?
When the advocate joins	Can they contribute from refinement through release, or are they brought in only for test execution?
Coaching and pairing or centralized execution	Will the arrangement help teammates build skills, or make the specialist the only person who can perform quality work?
Visible quality without a gate	Can risks, checks, and decisions be clear to the whole team without creating a separate approval queue?

Team size, product risk, regulatory needs, domain complexity, and available skills all affect the answer. Revisit the arrangement when the team’s needs change.

Boundaries and common pitfalls

• Making the advocate solely accountable. This weakens the whole-team approach. Developers still test their work, product partners still clarify user value, and everyone contributes to the team’s definition of done.
• Turning the role into a final gate. A mandatory last-person approval can recreate the separation the advocate role is meant to reduce. Keep risk discussion and feedback in the team’s working process.
• Inviting the advocate only at the end. Late involvement can leave avoidable ambiguity undiscovered until implementation is complete. Bring quality perspectives into relevant conversations earlier.
• Automating everything. Automation is useful when checks are reliable and maintainable. It does not eliminate the need for human judgment, exploratory testing, or conversations about user needs.
• Measuring activity instead of learning. A high test count or number of reported issues alone does not show that the team is improving. Look at whether feedback is timely and useful, and whether the team follows through on what it learns.
• Promising guaranteed results. Embedding an advocate is a way to support earlier feedback and shared learning, not a guarantee of better or faster software. The cited material does not quantify a causal effect.

Using screenshots as one kind of quality evidence

For a web feature, a screenshot can help a team discuss a visual state, compare a page before and after a change, or attach evidence to a review. It is one input to quality work: it cannot establish that behavior, accessibility, performance, or backend integration is correct. Agree on which state to capture, what a useful comparison means, and how the team will handle dynamic content.

A developer can capture a page locally with browser automation, or use a screenshot API when a repeatable image is useful in a review or workflow. Keep the capture setup and its failures visible to the team so a blank or blocked result is not mistaken for evidence that the page is correct.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. Its capture flow accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status.

For an existing visual review workflow, a screenshot can be attached as an artifact for the team to inspect. It does not replace functional or accessibility checks.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo documentation for the API parameters. The same request in Python:

import 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)

And in Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

The API also supports full-page and selector capture, device and viewport settings, dark mode, PDF options, custom CSS and JavaScript, waits, request blocking, headers, cookies, user agents, timezone and geolocation, resizing, caching, signed image links, async jobs, bulk capture, and a usage API. Its parameter names are compatible with those used by other screenshot APIs. An MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

There are 1,000 screenshots per month on the free plan with no card required. Paid plans start at $5 for 3,000 shots; every feature is available on every plan, and yearly billing gives two months free. Sign up for 1,000 free screenshots a month, with no card.

Reliability, performance, and cost considerations

• Feedback timing: Keep checks close enough to the change that the people who can act on the result are still involved. This is a workflow principle, not a measured performance guarantee.
• Maintainability: Choose checks the team can understand and keep reliable. Flaky automation can erode trust and slow feedback.
• Risk focus: Match test effort to user impact and system risk. Include nonfunctional concerns where they matter to the product.
• Evidence limits: Screenshots can show rendered appearance at a moment in time, but do not prove a page is correct in all states or environments.
• Cost: The sources reviewed do not provide a quantified cost or return-on-investment estimate for quality advocates. Consider staffing time, test maintenance, and the cost of delayed feedback in your own context.

Troubleshooting collaboration problems

Symptom	Likely cause	Response
The advocate is overloaded with every test task.	The team has assigned quality ownership to one person.	Pair on test work, agree which checks belong near the code, and make teammates’ responsibilities explicit.
Risks appear only near release.	The advocate joins late or refinement leaves assumptions implicit.	Invite quality questions into discovery and refinement; write down testable examples and important failure cases.
Developers treat tests as someone else’s job.	The workflow or incentives reinforce a QA handoff.	Have developers participate in checks for their changes and let the advocate coach and review.
Automated checks are flaky or ignored.	Checks may depend on unstable setup, timing, or data, or may lack clear ownership.	Investigate recurring failures, assign maintenance responsibility, and retain checks that provide useful feedback.
The role becomes an approval bottleneck.	The advocate is acting as a quality gatekeeper.	Move review and risk discussion into ongoing team work; reserve explicit approval gates for cases the organization actually requires.
The team cannot show that the change helped.	The intended improvement was vague or no baseline was recorded.	Choose a specific process signal, such as when risks are surfaced or how often checks give actionable feedback, and review it without claiming it proves a causal effect.

Frequently asked questions

Does a quality advocate have to be a tester?

Often the role draws on testing expertise, but organizations can assign it to a tester, quality engineer, or another suitably skilled teammate. The sources do not define one required background.

Is “quality advocate” a standard agile role?

No. The cited material presents a proposed framing, particular organizational practices, and one job description. It does not establish a universal agile role.

Does the advocate own the team’s definition of done?

The advocate can help the team make its completion criteria clear and useful. The team should agree on and follow those criteria together.

Can a small team use the approach without hiring someone?

Yes. A team can share quality responsibilities and use coaching or pairing where expertise exists. Whether it needs a dedicated advocate depends on its risks, skills, and workload.

Is there a proven percentage improvement from adding an advocate?

The reviewed sources do not establish a directly applicable controlled estimate. Treat earlier feedback and shared learning as intended mechanisms, then evaluate your own team’s experience.

Further reading

For a broader Scrum product-ownership perspective, see Robert Galen’s Essential Scrum: Scrum Product Ownership, identified in Software Testing Magazine’s discussion of testers and product owners in agile teams.

A quality advocate makes testing expertise available when the team can still use it. The role works best when it encourages clear examples, useful checks, and shared responsibility, while keeping users and important system qualities in view.