Software quality assurance that helps teams ship: what QA has taught us

We have been testing software since before "shift left" was a phrase people said out loud in meetings. Tools have changed, and software quality assurance now includes AI agents that write tests. A few things have held up through all of it.

These are the lessons that shape how we run QA and test automation for the teams we work with.

What software quality assurance actually covers

Software quality assurance, or SQA, is everything a team does to make sure software works before customers find out that it does not. Software testing is the largest part of it, but not all of it. In practice it covers:

• Test strategy: deciding what to test, how deeply and in what order.
• Manual and exploratory testing: a person using the product the way a customer would, looking for what nobody thought to write down.
• Test automation: scripts in tools such as Playwright, Cypress and Selenium that repeat the important checks on every change.
• Regression, smoke and sanity testing: making sure a new release did not break what already worked.
• API and performance testing: checking the backend directly and under load.
• CI/CD: running all of it automatically in GitHub Actions, Jenkins or Azure DevOps.

Coverage is a proxy, not a goal

Ninety percent line coverage on a payment flow with no negative-path tests is worse than forty percent with them, because the number buys false confidence from people who do not read the report.

This is the case for risk-based testing. Start from what would hurt most if it broke: taking payment, signing in, anything that touches customer data. Test those deeply, including the ways they should fail, before spending time on pages that rarely change and rarely matter.

The test suite is a product

It has users: the developers waiting on it. If it is slow, flaky, or unclear about why it failed, they will route around it. Every flaky test you tolerate spends credibility you will need later.

We saw the cost of this on a suite of 2,400 tests we inherited. It ran overnight, failed most mornings, and every failure was dismissed as "probably flaky." After the rebuild, the nightly regression run went from 6 hours to 11 minutes, the flake rate from 40% to 0.8%, and escaped defects per quarter fell by 64%.

Flaky tests are a state problem

That rebuild taught a narrower lesson. The fix was not better waits or more retries. It was removing shared state: every test created its own data and cleaned up after itself. Once tests no longer depended on each other, they could run in parallel, and the runtime fell on its own.

If your regression testing is slow, look at test independence before you look at hardware. We cover the same point for backend suites in API testing with Jest and Supertest.

Automate the boring, judge the rest

Automation is very good at telling you something changed. It is bad at telling you something is wrong. That second part is still the job.

AI has moved this line without removing it. An AI agent can now explore an application and write the tests, which used to be the slow part. It still cannot decide whether the behaviour is right for your business. Our view of where that boundary sits is in AI test automation with Playwright.

Quality is a property of the process, not a phase

Testing at the end finds bugs when they are most expensive to fix. The teams that ship calmly do three things earlier:

1. QA reads the requirement before code is written. Many bugs are questions nobody asked.
2. Tests run on every pull request, not on a release branch a week later.
3. A failing test blocks the merge. A suite that is allowed to fail stops being read.

None of this needs a large QA team. It needs the suite to be fast and trusted, which brings it back to the two lessons above.

When to bring in outside QA help

Building QA in-house is the right long-term answer for many products. Outside QA services make sense in a few specific situations:

• There is no QA yet, and developers are testing their own work before each release.
• Manual regression takes days, and releases are slowing down because of it.
• An automation suite exists but nobody trusts it, so it gets ignored.
• The team needs a skill it does not have, such as Playwright, API test automation or CI/CD setup.

Good outside help leaves you with something you own: a test suite in your repository, running in your pipeline, that your team can read and extend. QA outsourcing that keeps the knowledge outside your company is worth avoiding.

How we start with a new team

We begin by finding out what the application does today, not by writing a plan. Our AutoQA Agent explores the application, writes a first set of tests and reports what it finds. A QA engineer reviews the results, and the conversation about test strategy starts from real findings instead of assumptions.

Frequently asked questions

What is software quality assurance?

Software quality assurance, or SQA, is everything a team does to make sure software works before customers use it. It includes test strategy, manual and exploratory testing, test automation, regression testing, API and performance testing, and running those checks in a CI/CD pipeline.

What is the difference between QA and software testing?

Software testing is the activity of checking that the software behaves correctly. Quality assurance is wider: it also covers how requirements are reviewed, when tests run and what happens when a test fails, so that quality is built into the process.

How do you reduce flaky tests?

Remove shared state first. When every test creates and cleans up its own data, tests stop depending on each other and can run in any order and in parallel. Extra waits and retries hide the problem without fixing it.

When should a company outsource QA?

Outside QA help makes sense when there is no QA yet, when manual regression testing takes days, when an existing automation suite is not trusted, or when the team needs a skill it does not have. Good help leaves the test suite in your repository and your pipeline.

Is test coverage a good measure of quality?

Not on its own. High coverage with no negative-path tests gives false confidence. Coverage is more useful when it is combined with risk-based testing, where the parts of the product that would hurt most if they broke are tested most deeply.

Want to know where your application stands? Our free test run gives you a tested application and a report in 48 hours, or you can talk to us about QA for your team.