How to Improve the Software Testing Process

Improve a software testing process by treating it as a repeatable risk-management loop: understand what could fail and how much it matters, choose tests that address those risks, place feedback where it can guide development and release decisions, automate checks when their value exceeds their upkeep, and adjust based on evidence. Start with one costly or confusing part of the current process, make a bounded change, and review what happened before expanding it.

There is no universally correct test mix or a reliable percentage by which these practices improve quality. The right process depends on the product, its users, its delivery model, and the consequences of failure. ISO/IEC/IEEE 29119 provides adaptable concepts and process guidance; it is a reference for tailoring, not a requirement to add identical paperwork to every team.

1. Find the risks and bottlenecks that matter

Before adding tests or buying tools, map how a change moves from idea to production and where teams lose useful feedback. Talk with developers, QA, product owners, support, operations, and people who understand the consequences of failure. Include actual user and business outcomes, not only technical components.

Sketch the delivery path. Note where requirements, code, review, tests, deployment, and production feedback occur. Mark handoffs and queues where work waits.
List important outcomes. Examples include creating an account, completing a payment, exporting customer data, or meeting an accessibility need. Choose examples that actually fit your product.
Describe plausible failures. Consider incorrect results, unavailable services, data loss or exposure, degraded performance, confusing behavior, and regressions in common workflows.
Estimate likelihood and consequence. Use a simple shared scale if exact probabilities are unavailable. Record assumptions; the goal is a useful prioritization conversation, not false precision.
Locate process friction. Find late test results, flaky checks, duplicated effort, unclear release criteria, difficult environments, and failures discovered by customers.

ISO/IEC/IEEE 29119-1:2022 describes risk-based testing as a recommended strategy and says, “Testing is the primary approach to risk treatment in software development.” This supports prioritizing by risk; it does not mean that testing removes all risk or can prove software has no defects. ISO/IEC/IEEE 29119-1:2022

2. Match test activities to risk

For each high-priority risk, ask what evidence would make the team more confident, when that evidence is needed, and what the test would leave uncovered. Build a balanced strategy from checks that fit the product and lifecycle.

Activity	Useful when	Questions to settle
Static review	A requirement, design, code change, or configuration can be inspected before execution.	Who reviews it? What risk or defect class should the review catch?
Unit or component checks	Small pieces of behavior need fast, repeatable feedback.	Are important rules and edge cases covered? Is the expected result clear?
Integration checks	Failures may arise where services, databases, queues, or external systems meet.	Does the test represent the contract and failure modes that matter?
End-to-end or system checks	A critical user journey depends on multiple parts working together.	Is the journey important enough to justify the greater runtime and maintenance cost?
Non-functional checks	Performance, security, accessibility, compatibility, resilience, or usability is a meaningful product risk.	What conditions, thresholds, and supported environments are relevant?
Exploratory testing	Behavior is uncertain, changes interact, or human observation can reveal unexpected problems.	What area and question guide exploration? How will useful findings be recorded?

These categories are not a mandated sequence or a universal test pyramid. Put feedback early when it is useful there, and retain later checks for risks that require a realistic system or environment. ISO distinguishes test levels and types, and addresses both static and dynamic testing. ISO/IEC/IEEE 29119-1 and the ISO/IEC/IEEE 29119 series overview describe the series’ concepts, processes, documentation, and test-design techniques.

For each risk, keep a lightweight note such as: risk; consequence; check or other treatment; when feedback arrives; owner; known blind spots; and follow-up decision. A small traceable record can help teams make release decisions without requiring a large documentation system.

3. Put feedback into the development lifecycle

Testing helps most when its result reaches the person who can act on it before the relevant decision is made. Fit checks into the team’s workflow and delivery model rather than leaving all verification to a late, separate phase.

During refinement: clarify examples, acceptance conditions, failure behavior, data needs, and non-functional expectations. Resolve uncertainty while changes are still easy.
During implementation: use appropriate code checks, reviews, and fast automated tests to catch local mistakes close to their source.
In continuous integration: run dependable, relevant checks when changes are proposed or integrated. Make failures visible and actionable, and keep the slowest or most environment-dependent checks at suitable stages.
Before release: verify remaining high-impact risks, release conditions, supported environments, and any required operational readiness. Make explicit what has and has not been checked.
After release: use incidents, support reports, monitoring, and user feedback to find missing risks and improve future checks.

Continuous integration and delivery are useful contexts for organizing feedback. Google Cloud’s DevOps documentation discusses DORA-identified capabilities and CI/CD practices; it should be read as process guidance, not proof that a particular testing change causes a fixed outcome. Google Cloud: DevOps culture and organizational performance

Agile teams can adapt this approach too: ISO/IEC TR 29119-6:2021 provides guidance on applying the series in agile lifecycles. Teams using another lifecycle can tailor the same principles to their planning, review, and release points.

4. Automate deliberately

Automate a check when its repeatability, speed, frequency, and value of earlier feedback justify its implementation and maintenance costs. Installing a test tool or increasing the number of automated checks is not itself a process improvement.

Choose an objective. For example, reduce repeated manual verification of a critical rule or get faster feedback on a frequent integration risk.
Pick a bounded candidate. Favor behavior that is sufficiently understood, repeatable, and possible to check with a trustworthy expected result.
Estimate total cost. Include design, fixtures, environment setup, integration, runtime, failure investigation, skills, and ongoing updates as the product changes.
Assign ownership. Decide who maintains the check, who responds to failures, and how obsolete tests are removed or repaired.
Plan its place and report. Choose when it runs and what information a developer or release decision-maker needs from the result.
Review after use. Keep, adapt, or remove the automation based on whether it catches relevant problems and provides useful feedback for its cost.

Keep human-led testing where context, judgment, observation, or investigation adds value. Automation and manual work can complement one another. The ISTQB automation strategy material treats automation as a strategy that includes viability, costs and risks, metrics, implementation, deployment, reporting, and transition from manual testing. ISTQB Certified Tester Advanced Level Test Automation Engineering

5. Review evidence and improve in small steps

Use information that helps the team decide what to change. No single metric or dashboard applies to every product; a number can be misleading when treated as the goal instead of evidence.

Useful review prompts include:

Which important risks have checks, and where are the known blind spots?
How soon do relevant failures reach someone who can act?
Which customer-facing problems escaped, and what part of the process might have revealed them earlier?
Which checks are flaky, slow, duplicated, or expensive to maintain?
Where do work, test environments, or release decisions wait?
Do reports explain failures well enough to make a decision?

These are practical prompts, not a source-prescribed KPI set or universal formula. Avoid optimizing raw test counts or pass rates without examining risks and outcomes. Pick one concrete pain point, record a baseline in whatever evidence is available, make a limited change, and review the result with the people affected. Retain, adapt, or reverse the change, then choose the next improvement.

6. Use standards as adaptable references

ISO/IEC/IEEE 29119 organizes concepts and terminology in Part 1, generic test processes in Part 2, documentation in Part 3, and test-design techniques in Part 4. The series overview also points to ISO/IEC 20246 for static testing. Part 2 describes generic processes for governance, management, and implementation across software development lifecycle models; the technical report in Part 6 gives agile application guidance. ISO/IEC/IEEE 29119 series overview and IEEE listing for ISO/IEC/IEEE 29119-2-2021

Use these materials to clarify terms, identify activities or techniques worth considering, and tailor a process to your context. Do not assume every team needs every artifact. If you intend to make a formal conformance claim, check the applicable edition and its exact requirements: the standard distinguishes informative and normative parts and describes conditions for tailored conformance. This article is practical process guidance, not a compliance assessment.

7. A practical 30-day starting plan

Week 1 — Map: draw the change-to-release path, identify one important user outcome, and agree on its most consequential plausible failures.
Week 2 — Focus: inspect the existing checks for that outcome. Record useful coverage, late or unreliable feedback, and known blind spots.
Week 3 — Change: make one bounded adjustment, such as clarifying an acceptance condition, moving a reliable check earlier, or automating a stable repeatable check.
Week 4 — Learn: review failures detected, feedback timing, upkeep, and team experience. Keep the change, adjust it, or undo it, then select the next risk or bottleneck.

This is a convenient cadence, not a guaranteed improvement timeline. Adapt it to release frequency, team size, and risk.

Or skip the browser setup

If screenshot verification is one part of your testing process, you can capture a page with a browser automation library or call ScreenshotNeo, a website screenshot API and MCP server for developers. The API returns an image or PDF from one GET request. See the ScreenshotNeo API documentation.

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,
)
r.raise_for_status()
with open("shot.webp", "wb") as shot:
    shot.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 image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

Cookie and consent banners are accepted as a visitor and removed, along with 60+ known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Troubleshooting a testing process

Symptom	Likely cause	Useful next step
Problems still reach users despite many tests	Test count is not aligned with important risks, or checks use weak expected results.	Review escaped problems against user impact; identify which risk or oracle was missing and add a targeted check or other treatment.
CI is slow or blocks changes for long periods	Too many expensive checks run at the earliest stage, or feedback and environment setup are inefficient.	Measure where time is spent; keep useful fast checks early and place slower system-dependent checks at an appropriate stage.
Flaky tests erode trust	Uncontrolled time, shared state, unstable dependencies, or environment variability can make outcomes nondeterministic.	Capture diagnostic data, isolate causes, stabilize dependencies, and assign ownership. Quarantine only with visibility and a plan to resolve the risk.
Automated tests break after ordinary changes	Checks are coupled to incidental implementation details or fixtures are hard to maintain.	Prefer assertions on meaningful behavior and contracts; simplify brittle setup and reassess whether the check’s value justifies upkeep.
Teams disagree about release readiness	Risk acceptance, required evidence, or known blind spots are implicit.	Agree on decision criteria before release and make residual risks and evidence visible to the decision-maker.
Testing happens late and creates a queue	Requirements are unclear, feedback is postponed, or roles and environments create handoff delays.	Move suitable review and checks earlier, clarify examples during refinement, and address the specific queue or handoff.
Dashboards look healthy but outcomes do not improve	A proxy such as pass rate is being optimized without connection to risk or customer outcomes.	Pair the measure with concrete failure and feedback evidence, then change the decision or metric if it does not help.

FAQ

Does improving testing mean testing every possible input?

No. Exhaustive testing is generally infeasible. Choose representative checks based on risk, expected behavior, and available evidence, and record important remaining uncertainty.

Is a test strategy useful for a small team?

Yes. It can be a short, shared account of important risks, chosen checks, timing, ownership, and blind spots. The useful size is the smallest one that supports decisions.

Should a team adopt ISO/IEC/IEEE 29119 to improve?

Not necessarily. Its concepts and processes can provide reference material, but teams can tailor what is useful to their product and lifecycle. A formal conformance claim has separate requirements.

Does more automation always mean better quality?

No. Automation is useful when its results justify setup and maintenance costs. It does not remove the need for thoughtful test design, investigation, or human judgment.

Where can someone study test automation strategy?

The ISTQB automation engineering syllabus and recommended reading are an optional self-study starting point; certification or training is not a prerequisite for improving a team’s process. ISTQB test automation engineering