QA Rating

A step-by-step process for buying testing services

QA Rating is published independently, and its publisher owns no company listed in this catalog.

A procedure for scoping a testing engagement, building a shortlist, and checking vendor profile fields before signing a contract.

A testing budget gets committed long before any contract is signed. It gets committed in the internal question a buying team answers first, in the fields checked on each candidate, and in the order those fields are checked. This page lays out that order, from defining the need to acting on the answers collected from a shortlist. It does not compare individual companies. It describes what to ask, what counts as a confirmed answer, and what an empty field on a profile means for the decision.

Which QA company should I hire?

No page in this catalog answers that with a single company name, and one that did would be guessing about a need it cannot see. The question resolves into a chain: the service that has to leave the building, the delivery model that fits how the work will be run day to day, and then the fields on each candidate that carry a source. Two teams that both open with "we need QA" end up with different suppliers once that chain runs, because one needs regression coverage before a release train and the other needs a framework wired into a build pipeline. The rest of this page is that chain in order. Working through it produces a shortlist of two or three names, and those names are the answer to the question as asked.

Separate the testing need from the delivery model

The first decision has nothing to do with any vendor: what kind of work needs to leave the building. A team that needs coverage for a release cycle or regression checks before a launch is looking for manual testing capacity. A team that needs scripts and a framework wired into a build pipeline is looking for test automation capacity. These are two different services in a vendor's catalog listing, and a request that mixes both without saying which one matters more produces a shortlist that fits neither need well.

A shortlist built around a manual coverage need can start from vendors listed in the manual testing ranking. A shortlist built around an automation need can start from vendors listed in the test automation ranking. If the need is a narrow, standalone service, such as a one-time security assessment or a load test ahead of a release, say so explicitly in the first outreach message: a vendor sized for ongoing manual coverage may quote a standalone engagement differently than one built around it.

Adjust the short list to company stage

A vendor evaluated for a company with an established QA function is not evaluated the same way as one evaluated for a company signing its first testing contract. Budget size and the scale of engagement a vendor can take on both change with the stage of the buying company. A buying team inside an early-stage company can narrow the field further by starting from vendors listed in the startup stage ranking and then applying the service filter from the first step on top of that list.

Read a vendor profile field by field, in a fixed order

Once a shortlist exists, the profile of each candidate is read completely and in a fixed order. Fields that establish fit come first, fields that establish compliance come second, and commercial fields come last:

  • Is the listed service the exact one defined in the first step?
  • Do the listed frameworks match what the internal team already uses or plans to adopt?
  • Is the delivery model, whether a dedicated team or a fixed-scope engagement, compatible with how the work will be managed day to day?
  • Is a listed certification linked to a verification source, or listed on its own without one?
  • Is the regulatory readiness field populated for the regime that applies to this project, or left empty?
  • Are named clients and review scores present, and do they carry a source behind them?

Reading fields in this order keeps a commercial detail, such as a rate, from settling the decision before a service or compliance mismatch has been ruled out.

Treat every claim as unverified until it has a source

A catalog field is only as useful as the source behind it. A certification or a named client that links to something outside the vendor, such as a certifying body or a public case study, can be checked independently. A review score is checked the same way, against the platform it is aggregated from. A claim of the same kind made only on a vendor's own site belongs in a follow-up question sent directly to the vendor. Ask for the document behind a certification and the account behind a named client, then record the answer once it has been checked against the source the vendor points to.

Decide what an empty field is telling you

An empty field on a profile means a fact has not been confirmed by a source, not that the vendor lacks that capability. A vendor with no published rate may still quote one on request. A vendor with no populated regulatory readiness field may still be eligible for that regime once asked directly. Empty fields become a list of questions sent to the vendor before a candidate is dropped from consideration. A candidate is dropped for a service mismatch or a certification that cannot be verified; an unpopulated field alone only raises a question to send.

Turn shortlist answers into a decision

Once fields are read and follow-up questions are answered, compare the remaining candidates only on the fields tied to the need defined in the first step: the correct service and a compatible delivery model, plus, where relevant, a confirmed certification or regulatory readiness. A candidate that matches on service and delivery model but leaves a compliance field unconfirmed after direct questions carries more risk than one that answered the same question with a document. Rank the shortlist on those confirmed answers alone.

How to choose a software testing vendor when two finalists look identical

Two candidates can arrive at the end of this process matching on service, delivery model and every verified field, which means the fields have stopped separating them and something else has to. Three things usually do. The first is how each one answered the follow-up questions raised by empty fields: a supplier that sent a certificate document within a day and a supplier that answered the same question with a sentence on a call are not in the same position, whatever their profiles show. The second is who would be staffed on the work, which is a question about named people and the weeks they are free, a different question from total headcount. The third is what happens when the scope changes mid-engagement, which belongs in the commercial discussion rather than the profile. None of these three is a catalog field, and all three are answerable before signature by asking.

The comparison above narrows a shortlist to one or two finalists. Contract terms and data handling are a separate check that follows this step and is not covered here. What belongs here is the confirmed set of facts each finalist has provided: the service and delivery model, along with any certification or regulatory readiness claim backed by a source. That set of facts is the reference sheet a buying team carries into the contract discussion.

Published by QA RatingPublished on September 3, 2026Updated on September 3, 2026

How this catalog decides what goes into a ranking, and on what basis rows are ordered, is on the methodology page. Every fact about a company comes from a listed source. A field without a source stays empty. A certificate counts as confirmed only when a registry, certificate or auditor report backs it; a certificate the company only claims about itself is published separately, under that label. Vendors can request a correction at hello@qa-rating.com. A correction is applied when it comes with a public source.