Unpopular Opinions About Software Testing

Some software testing practices are useful in one context and wasteful in another. The practical question is not whether an opinion is unpopular: it is what risk the practice addresses, what information it gives the team, and what it costs to adopt and maintain.

The opinions below come from a 2023 collection of views shared by Agile Testing Days community members. They are conversation starters from agile testing practitioners, not controlled comparisons or a consensus among all software testers. [Read the collection](https://agiletestingdays.com/blog/celebrating-unpopular-agile-software-testing-opinions/).

For any practice, examine the consequence of a missed defect, the speed and usefulness of feedback, maintenance cost, user and platform coverage, and who can investigate and act on a finding. Those questions help turn a provocative statement into a decision your team can evaluate.

1. Testing can be shared across the team

One view in the collection is that testing can be done by anyone on a team, and that a team’s unwillingness to test can turn a tester into a bottleneck. Another contributor argues that even when a team has a dedicated tester, that person does not need to test every feature.

Shared responsibility can shorten feedback loops: developers can check behavior as they build it, product colleagues can clarify expected outcomes, and testing specialists can investigate risk and uncertainty. It does not mean every person has the same testing skills or that specialist work disappears.

When this view may help

• Work waits for one person to begin basic checks that teammates could perform.
• Developers and product partners can contribute useful checks while a specialist focuses on riskier or less familiar areas.
• The team can make ownership visible: someone is responsible for investigating each important risk and acting on the result.

What to watch

“Everyone tests” can become “nobody owns testing” unless responsibilities are explicit. Specialist skills may be needed for areas such as accessibility, security, test architecture, or complex exploratory work. Decide who has the skill and authority to investigate those areas, and how findings enter the team’s workflow.

2. There are no context-free best practices

Eric Proegler is quoted in the collection: “There are no best practices or answers that apply to every context…Instructions that are context-oblivious or context-imperial are potentially harmful.” The point is not that teams cannot learn from other teams. It is that a practice should be judged against the conditions in which it will be used.

A small internal tool, a frequently changed consumer product, and a system with costly failure consequences can have different testing needs. A practice that helps one team manage a serious risk might slow another team without providing much information.

A quick evaluation checklist

1. Name the risk. What failure are you trying to prevent or detect, and what happens if it reaches users?
2. Identify the signal. What will this practice tell you that you do not already know?
3. Estimate the feedback time. How soon can someone act on a result?
4. Include the ongoing cost. Account for setup, upkeep, false alarms, and time spent investigating results.
5. Check coverage and ownership. Which users, platforms, and conditions are represented, and who responds when something fails?
6. Revisit the decision. Use observed failures, escaped defects, delays, and maintenance effort to decide whether the practice is still earning its place.

3. More testing is not automatically better

João Proença’s opinion in the collection is: “Sometimes a lot of testing is exactly what you don’t need.” Joanna Denni questions excessive regression effort and automation when a role becomes centered on producing large sets of test cases, maintaining them, and acting as a release gatekeeper.

These are concerns about the value and cost of testing activity, not evidence that broad regression coverage or automation is generally unnecessary. A large suite can be valuable when it catches consequential regressions at a useful cost. It can also consume time while providing slow, noisy, or repetitive feedback.

Assess a test suite by its information value

• Does it cover important behavior or mostly repeat checks already supplied by faster tests?
• When it fails, can the team identify the cause without excessive investigation?
• Does its runtime delay feedback or release decisions?
• How much work goes into repairing brittle checks after ordinary changes?
• Do failures lead to fixes, or are they routinely ignored or rerun without investigation?

Use those answers to improve the suite: retain checks that address meaningful risks, repair unreliable checks, and remove duplication when it no longer adds useful coverage. The appropriate balance depends on the product and the consequences of failure.

4. Accessibility testing is a must for some practitioners

Eduarda Loureiro’s position in the roundup is that accessibility testing is a must, not just a nice-to-have. Treat that as an attributed practitioner opinion. The collection does not establish a legal requirement or a particular accessibility standard, so this article makes neither claim.

For a team, the useful question is how accessibility risks are discovered and followed through. Consider where accessibility checks fit into design review, implementation, and evaluation with assistive technology or users. Identify who has the relevant skills and how issues are prioritized and resolved. A single check or specialist sign-off should not be assumed to cover every user or interaction.

5. TDD and exploratory testing answer different questions

Lisa Crispin argues that teams should learn test-driven development (TDD). The roundup also notes that exploratory testing can be overshadowed by TDD and behavior-driven development (BDD). These views are useful together: they point to different ways of getting feedback and discovering problems, rather than requiring a choice of one camp.

TDD asks a team to use tests while developing behavior. Exploratory testing emphasizes investigation and learning about how the product behaves. The source does not demonstrate that either method prevents a particular percentage of bugs; its numerical claim about bug prevention is attributed in the article and is not verified by the dossier, so it is omitted here.

Questions for choosing a mix

• Do automated checks give fast feedback on expected behavior as code changes?
• Are there areas where the team needs to investigate behavior it has not already specified?
• Can exploratory findings lead to clearer expectations or useful automated checks?
• Does the team have time and skill to maintain the checks it creates?

A team can use repeatable automated checks for known expectations and exploratory work to learn about uncertainties. The mix should follow the product’s risks and the feedback the team needs.

6. Traditional test cases are not the only route to quality

Butch Mayhew’s opinion in the collection challenges the idea that teams need traditional test cases and test-case execution to release high-quality software. That statement questions a particular process; it does not mean teams can skip understanding expected behavior, evaluating risk, or learning from failures.

Teams can communicate and track testing through different methods. Whatever format they choose, they need enough shared understanding to know what matters, what was checked, what remains uncertain, and who will respond to a problem. A formal test case can be useful when repeatability, auditability, or handoffs matter. A lighter approach may fit work where the team gets adequate feedback through other means.

7. Visual checks can make interface changes easier to inspect

One opinion in the collection says visual QA should be done by the designer. The underlying team question is who is best placed to notice and evaluate visual changes. Designers may recognize intended visual behavior, while developers and testers may catch layout regressions across pages, viewports, or states. Make responsibilities clear so a screenshot or comparison produces an investigation rather than an unowned alert.

Capturing a page can help a team review a particular state or share evidence of a visual issue. It does not, by itself, establish that an interface is correct, accessible, or usable. The capture must use the relevant URL, state, viewport, and page readiness conditions, and a person still needs to interpret what it shows.

8. A practical way to discuss an unpopular opinion

Use this short exercise in a team discussion or retrospective:

1. Write the opinion as a testable proposal, such as “We should reduce this regression suite because these checks duplicate faster feedback.”
2. State the risk that the current practice is meant to address.
3. Choose a small, reversible change and agree on what evidence you will observe.
4. Track the useful signal, feedback time, maintenance work, and problems the change might miss.
5. Keep, adjust, or reverse the change based on what the team learns.

This approach avoids treating popularity as evidence. It gives the team a way to learn whether a practice is useful in its own context.

9. Capture page states for visual review

For a visual QA workflow, capture the page state that matters, then review it with the people responsible for the expected design and behavior. A screenshot can document a rendering issue, support a discussion, or help compare page states. It should be one source of evidence among the checks appropriate to the feature.

If you build your own capture workflow, choose the URL and viewport deliberately, wait for the relevant content to appear, and account for dynamic or personalized page content. Keep credentials out of shared artifacts, and avoid treating a successful image response as proof that the page passed functional or accessibility checks.

10. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. One GET request returns a PNG, JPEG, WebP, or PDF. Its API accepts the parameter names used by other screenshot APIs, which can make switching easier. See the ScreenshotNeo API documentation for request options.

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

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)

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 fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each of those steps can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

Start with 1,000 free screenshots a month, with no card required.

FAQ

Are these opinions proven to be unpopular?

No. The source is a collection of opinions solicited from Agile Testing Days community members, not a survey measuring how common each view is across the software industry.

Does shared testing mean a team does not need testers?

No. It means testing can involve the team. Specialist skills and clear ownership may still be needed, and a dedicated tester does not necessarily need to personally test every feature.

Should teams stop automating regression tests?

The collection raises concerns about excess effort and maintenance; it does not support a blanket rule against regression testing or automation. Evaluate whether each check supplies useful risk coverage for its ongoing cost.

Do TDD and exploratory testing conflict?

The roundup includes both advocacy for TDD and concern that exploratory testing can be overshadowed. They can serve different feedback and learning needs; select a mix that addresses your product’s risks.