Quality Assurance Testing Services: The Checks a Release Has to Pass

Updated November 2026 · Written and maintained by the Progression Agency strategy team

On a desktop the checkout works. On a phone the Pay button sits under a chat widget that never moves, and customers who cannot reach it leave without a word. Quality assurance testing services exist to find that before customers do: a release gate of functional, regression, device, accessibility and performance checks, each with a clear rule for what stops a release. WCAG 2.2 even names this kind of problem, focus that is hidden behind other content. Progression’s team is based in New York and tests websites and apps for US companies, including software another team built.

A Pay button nobody on a phone could reach

A hypothetical store’s checkout was tested only on desktops, and it worked. On a narrow phone, a fixed chat widget covers the Pay button. Customers who cannot reach it leave without a word, and nothing in the logs says why.

Two WCAG 2.2 criteria touch this problem: 2.4.11 Focus Not Obscured (Minimum) and 2.5.8 Target Size (Minimum). A gate check on one phone size would have caught it before anyone paid for the traffic.

Why do desktop tests miss it?

Because the layout changes with the screen. A widget that sits in a corner on a wide window can land on top of the main button on a narrow one.

What quality assurance testing services check before a release

The page is organized as a gate. Each check has what it catches, whether it is manual or automated, who runs it and what stops the release. The table lists them in the order they run.

Regression: the features nobody changed

A regression check runs the things that worked last time. It is where most surprises are found, because the change that broke checkout was made in a different feature.

The device and browser matrix

The matrix lists the phones, tablets and browsers the release is tested on. It is set from your own analytics so it matches the people who use the product.

• Pick the matrix from your analytics, not a generic list.
• Include at least one small phone and one older browser in use.
• Test on real devices for anything touch based.
• Review the matrix every quarter.

Is quality assurance the same as testing?

No. Testing finds defects in a build. Quality assurance sets the process that keeps defects out: what is tested, when, and what stops a release. Testing is one part of it.

For where testing sits in the wider build process, see the software development life cycle.

Which one does a team usually lack?

The process. Many teams test, but few have written down what stops a release.

Accessibility in the gate: what WCAG 2.2 added

WCAG 2.2 builds on and is backwards compatible with WCAG 2.1, so a page that conforms to 2.2 is at least as accessible as one that conforms to 2.1. It adds nine success criteria and removes one, 4.1.1 Parsing.

• 2.4.11 Focus Not Obscured (Minimum), Level AA.
• 2.4.12 Focus Not Obscured (Enhanced), Level AAA.
• 2.4.13 Focus Appearance, Level AAA.
• 2.5.7 Dragging Movements, Level AA.
• 2.5.8 Target Size (Minimum), Level AA.
• 3.2.6 Consistent Help, Level A.
• 3.3.7 Redundant Entry, Level A.
• 3.3.8 Accessible Authentication (Minimum), Level AA.
• 3.3.9 Accessible Authentication (Enhanced), Level AAA.

Criterion 2.5.8 says the size of the target for pointer inputs is at least 24 by 24 CSS pixels, with listed exceptions that the W3C page sets out. The plain advice: automated checkers catch some issues and keyboard and screen reader passes catch the rest. Legal questions go to counsel. See ADA compliant website design for accessible builds.

Does the gate make us compliant?

No. A test result is not a legal finding. The gate finds barriers against WCAG 2.2 and gives the team a list to fix.

Manual testing or test automation

Automate stable, repeated paths such as login and checkout. Keep new features and visual and exploratory checks manual, because a person notices what a script was never told to look for.

Quality assurance vs test automation is a false choice. Automation is a tool inside the process, and tests that are not kept current become a cost of their own: a suite that fails for old reasons teaches the team to ignore it.

Who keeps automated tests current?

Whoever changes the feature changes its tests. A suite owned by nobody decays.

Software quality assurance testing services for a team you already have

An outside testing team joins sprints the way another developer would. Test cases are written from each ticket, a test environment is agreed, defects go into your tracker and a sign off step sits before release.

• Test cases written from the ticket’s acceptance steps.
• A test environment that matches production closely.
• Defects filed in the team’s own tracker, with severity.
• A sign off step before any release.

See software development life cycle for the sprint and release stages this plugs into.

Who writes the test cases?

The testing team, from the ticket, with the product owner confirming the acceptance steps.

Pricing QA and software testing

Pricing depends on scope, is subject to change and is set in the written proposal. Device lab or testing tool subscriptions are priced by the vendor.

• Ask which checks from the gate the quote includes.
• Ask how many devices and browsers the matrix assumes.
• Ask how a re-test after fixes is counted.
• Ask what happens to the automated tests when you leave.

How to compare a quality assurance testing company

Four questions tell quality assurance testing companies apart, and each ties back to the gate. Which checks do they run by default? Which phones and browsers do they test on? How do they report a defect? Who decides a release is blocked?

What if they test only on emulators?

Emulators are useful but miss behavior on real hardware. Ask for real devices on touch based paths.

What each test cycle hands back

Every cycle ends with one report, written to be read quickly. It says what was tested, what failed and what the team needs to decide.

• What was tested and on which devices.
• Defects by severity.
• What passed and what blocked the release.
• Regression suite changes.
• Open risks.

Who reads it?

The product owner and the lead developer, so a release decision and the fixes behind it are made together.

Defects and severity: how a block is decided

A release is blocked when a defect crosses a line agreed before testing began. Severity levels make that line plain.

Agreeing the levels in advance prevents arguments on release day.

Who can override a block?

The product owner, in writing, with the risk recorded in the report.

Test environments and test data

A test is only as good as the environment it runs in. A staging copy that differs from production hides defects, and test data that is too tidy hides the ones real customers find.

• Keep staging close to production in configuration.
• Use test data that includes awkward names, long text and odd addresses.
• Never test with real customers’ personal data.
• Reset the environment before each cycle.

A short note on how the environment differs from production is included in each report.

What about payments in testing?

Payment steps are tested with the provider’s test mode, never with real cards.

Security smoke checks in plain terms

A security smoke check looks for obvious gaps, not for every possible attack. It asks whether a private page can be opened without signing in, whether a form accepts what it should not, and whether one user can reach another’s data.

• Can a signed out visitor open a private page?
• Can one user see or change another user’s data?
• Do forms reject input they should refuse?
• Do error messages reveal more than they should?

A deeper security review is a separate engagement, and the gate marks where a smoke check stops.

Is a smoke check a security audit?

No. It is a quick look for obvious problems before release, and it does not replace a full review.

Frequently asked questions