Software QA Process - 7 Stages, Best Practices, and Examples

The QA process encompasses all activities that ensure software meets quality standards before production release. It spans requirements analysis, test planning, test design, execution, defect management, and continuous improvement. Traditional QA processes create bottlenecks through manual test creation, brittle automation, and reactive defect detection. Modern development velocity demands intelligent QA processes where AI automates test generation, execution adapts continuously, and quality validation happens at the speed of development.

What is the QA Process in Software Testing?

The QA process is the systematic approach to validating software quality throughout the development lifecycle. It defines how teams plan testing activities, create test scenarios, execute validation, manage defects, and continuously improve quality practices.

QA, QC and Testing

These three terms are often used interchangeably, but they cover different things.

Testing is one part of quality control, and both sit inside quality assurance. QA aims to prevent defects by building quality into how software is made, rather than only catching problems at the end.

What a Good QA Process Achieves

• Prevents defects through clear standards, reviews and early testing, so fewer problems reach later stages

• Confirms the software meets the business requirements it was built for

• Supports frequent releases without lowering quality, through automation and risk-based priorities

• Gives stakeholders a clear view of quality, coverage, defect trends and release readiness

• Puts testing effort where business risk is highest, while keeping critical features fully covered

The 7 Stages of the QA Process

Stage 1: Requirements Analysis and Test Planning

This stage works out what needs testing and how the testing will happen.

Key Activities

• Review requirements, user stories, acceptance criteria and specifications to understand expected behaviour, and flag anything unclear or untestable

• Define the test strategy, including test types (functional, performance, security), test levels (unit, integration, system, acceptance) and the approach (risk-based, continuous testing in CI/CD)

• Decide scope and priorities based on business risk, and agree the quality gates a release must pass

• Plan people, skills, tools, environments and timelines

• Identify quality risks and technical challenges, with ways to reduce them

• Agree how success will be measured, such as defect escape rate, coverage of critical journeys and testing cycle time
  ‍

Common Bottlenecks and How AI Helps

Stage 2: Test Design and Test Case Creation

This stage turns requirements into test scenarios that cover every requirement and the journeys users depend on.

Key Activities

• Identify the end-to-end journeys and business processes that need testing

• Write test cases with preconditions, steps, test data and expected results

• Prepare realistic test data, including edge cases and boundary values

• Link each test case to the requirement it proves, for coverage and compliance

• Set up test environments that reflect production, with the integrations they need

Common Bottlenecks and How AI Helps

Stage 3: Test Execution

This stage runs the tests, checks the results and finds defects.

Key Activities

• Check test environments are configured correctly and available

• Run manual tests, recording actual results against expected ones

• Run automated suites in the CI/CD pipeline or on demand

• Carry out exploratory testing to find problems scripted tests miss

• Test across the browsers and operating systems your users rely on

• Check performance against expected load, using specialist load testing tools

• Test APIs for correct responses, error handling and response times

• Record outcomes and keep evidence, such as screenshots and logs

Common Bottlenecks and How AI Helps

‍Stage 4: Defect Management

This stage tracks, prioritises and resolves the defects found during testing.

Key Activities

• Log defects with reproduction steps, screenshots, environment details, severity and priority

• Triage defects to confirm they’re real, assess their impact and set priorities

• Investigate the root cause and fix the underlying problem

• Verify each fix, and check it hasn’t broken anything else

• Track defect trends, such as how many are found, how fast they’re fixed and how many reopen

Common Bottlenecks and How AI Helps

Stage 5: Regression Testing

This stage makes sure new changes haven’t broken features that already worked.

Key Activities

• Keep the regression suite up to date as the application changes

• Run regression automatically on every build or deployment

• Compare results against previous runs to spot regressions

• Choose which tests to run based on what changed, for smaller releases

• Run a small set of critical checks against production to confirm key journeys still work

Common Bottlenecks and How AI Helps

Stage 6: Test Reporting and Quality Metrics

This stage gives stakeholders a clear view of quality and how well testing is working.

Key Activities

• Report pass and fail rates, run times and coverage

• Summarise defect trends, severity and how long fixes take

• Track coverage of requirements and critical user journeys

• Keep dashboards showing testing progress and release readiness

• Present quality status to leadership, development and business stakeholders in terms they understand

Common Bottlenecks and How AI Helps

Stage 7: Continuous Improvement

This stage improves the QA process based on what each release taught the team.

Key Activities

• Hold retrospectives on what worked, what didn’t and what to change

• Analyse testing efficiency, defect trends and bottlenecks

• Review whether tools still meet the team’s needs

• Train the team on new approaches and tools

• Simplify workflows and remove steps that don’t add value

Common Bottlenecks and How AI Helps

Quality Gates That Keep Releases on Track

Quality gates are checks a change must pass before it moves to the next stage. Agree them early, so nobody argues about them on release day.

QA Metrics That Drive Decisions

How QA Works in Agile and DevOps Teams

QA in Agile Sprints

In agile development, QA happens throughout each sprint rather than after development ends.

• Sprint planning: QA reviews stories and acceptance criteria, flags anything untestable and agrees the test approach with the team

• Development: developers write unit tests alongside code, QA builds automated scenarios, and tests run on every commit

• Sprint testing: QA checks completed stories, runs exploratory testing and regression, and business users confirm acceptance criteria

• Sprint review: the team demonstrates working software and gathers feedback

• Retrospective: the team agrees improvements to testing and automation

QA in DevOps Pipelines

DevOps teams build quality checks into the delivery pipeline itself.

• Continuous integration: unit and integration tests run on every commit, giving feedback within minutes

• Continuous testing: automated functional tests run in staging, alongside performance tests and security scans using specialist tools

• Continuous deployment: smoke tests confirm each deployment, while canary releases and feature flags limit how many users see a change at first

• Continuous monitoring: synthetic checks run key journeys in production, real user monitoring tracks actual experience, and the team can roll back quickly if quality drops

QA When AI Writes the Code

AI coding assistants let teams produce code much faster, which puts new pressure on the QA process. More changes arrive each sprint, and when an assistant writes both the code and its unit tests, both can share the same mistaken assumption and still pass.

That shifts what the QA process needs to prove. It’s no longer enough to know the tests passed. Teams need to know which requirements those tests checked, whether the tests still match what the business asked for, and who approved any changes to them. A QA process built for AI-speed delivery tests behaviour against requirements, keeps people in charge of the decisions that matter, and keeps a record of every decision for each release.

How the QA Process Looks in Different Industries

These examples are illustrative, showing how the same seven stages adapt to different risks.

Financial Services: A Trading Platform

In financial services, a single calculation error can mean regulatory breaches as well as lost money, so QA plans around accuracy and audit from the first stage. Our guide to banking application testing covers these risks in more depth.

• Requirements: business analysts document trading rules, regulatory obligations and performance targets, and QA reviews them for edge cases such as partial fills and market halts

• Test design: scenarios cover order placement, execution, settlement and regulatory reporting, with load tests simulating peak market conditions

• Execution: automated tests run on every code change, with regression run in parallel to keep feedback fast

• Defect management: any defect affecting order accuracy or reporting blocks the release

• Compliance: automated checks confirm reporting required under rules such as MiFID II still works after each release

Healthcare: A Patient Portal

Healthcare software handles sensitive data and supports care decisions, so privacy and workflow accuracy shape every stage. For a fuller picture, see our guide to healthcare application testing.

• Requirements: clinical and patient-experience teams define workflows for booking, test results and prescriptions, with privacy rules such as HIPAA built in

• Test design: end-to-end journeys cover every key patient task, plus integrations with scheduling, laboratory and pharmacy systems

• Execution: tests run on every configuration change and vendor upgrade

• Acceptance: clinical staff confirm workflows in realistic scenarios before release

• Production checks: synthetic tests run key journeys regularly, alerting the team before patients notice a problem

Retail: An Ecommerce Site

Retail QA centres on the path to purchase, where a broken step costs sales straight away. Our guide to ecommerce testing goes deeper into checkout, payments and peak-season readiness.

• Requirements: product teams write user stories with clear acceptance criteria, and QA joins story refinement

• Test design: scenarios cover catalogue, search, cart, checkout, payment and order fulfilment across every country and currency

• Execution: tests run on every pull request, with page performance checked against targets

• Visual checks: visual testing catches layout changes across browsers and screen sizes

• Peak preparation: load testing and resilience testing well before major sales events

Best Practices for an Effective QA Process

1. Shift Testing Left

Start quality work early. Review requirements for testability, write tests during development rather than after it, and let developers run tests locally.

2. Automate Where It Pays Off

Automate regression, frequently used journeys and tests that need to run across many browsers. Keep manual effort for exploratory testing and usability.

3. Make Ownership Clear

Decide who owns test creation, execution, maintenance, environments and defect resolution. When everyone is responsible, often nobody is.

4. Build Quality Gates into the Pipeline

Agree the criteria each change must meet before it moves on, and enforce them automatically.

5. Test According to Business Risk

Spend more effort on features that drive revenue or carry regulatory risk, and less on rarely used admin screens.

6. Measure What Changes Decisions

Track metrics the team will act on, such as defect escape rate, coverage of critical journeys and cycle time, rather than numbers that only look good on a dashboard.

7. Keep Feedback Fast

Developers should see test results within minutes, and stakeholders should see quality status without waiting for a report.

8. Invest in Environments and Test Data

Unreliable environments and poor test data undermine even the best test strategy. Treat them as part of the QA process, not an afterthought.

9. Keep a Record of What Was Tested

Link tests to requirements and record who approved them. When an auditor, customer or release board asks how a release was tested, the answer should take minutes to find.

Where Virtuoso QA Fits in Your QA Process

Virtuoso QA takes on the design, execution, regression and reporting stages for browser-based applications. What it adds to the QA process is a trail.

For any release, the team can open a run and see the requirement behind each test, how every step went and the reviewer who signed the test off, which turns the release decision in stage 6 into a matter of looking things up.

• In planning and design, Touchstone works through the stories and specifications already in Jira and proposes requirements and test cases from them. Each proposal points back to the document it came from, and nothing joins the suite until a named reviewer accepts it.

• During authoring, analysts and testers describe journeys in everyday English and watch each step execute against the live application as they type. StepIQ offers likely next checks based on the page they’re working on.

• In execution, one journey can move through the screens, call the services behind them and query the database. Business Process Orchestration chains processes that span several systems into a single run.

• In defect management, a failed run shows the broken step beside the same step from the most recent successful run, with the captured network and console data and an explanation of the probable cause.

• In regression, a UI change produces a suggested fix that waits in a review queue, so the suite stays current without anything changing unseen. A change to a shared component, such as login, is corrected once and carried into every journey that uses it.

• In the pipeline, runs start from Jenkins, Azure DevOps or GitHub Actions and spread across more than 2,000 browser and OS combinations.

Where QA Processes Are Heading

Governed Autonomy in QA

AI will take on more of the routine work in the QA process, such as drafting tests, keeping them current and investigating failures. The teams that benefit most will be those that keep people in charge of the decisions that matter, with AI proposing, a person approving and every decision recorded.

Predicting Risk Earlier

Teams will increasingly use data from past releases to predict which changes carry the most risk, and which tests deserve priority, before testing starts.

Testing That Continues After Release

Synthetic checks and monitoring will keep confirming that critical journeys work in production, with fast rollback when something breaks.

Evidence as a Standard Release Output

As more code is written by AI, a passing pipeline will stop being enough on its own. Release boards, auditors and customers will want to see what each release was tested against, which requirements those tests covered and who approved them. Collecting that record as part of every run, rather than piecing it together when someone asks, is what release evidence means in practice.

Related Reads

• ‍The Ultimate QA Checklist - From Strategy to Release
  
  

• What is Bug Life Cycle in Software Testing?‍‍
  
  

• Shift-Left Testing - Types, Benefits, and Best Practices‍
  
  

• What is Agile Testing - Principle, Life Cycle, Types, and Strategies