Turning a testing request into a name a vendor recognizes

A buying team that says it needs testing has stated a goal. A service name is a narrower statement: it names the method used to reach that goal, such as a person running a script, an automated suite, or a conformance audit against a written standard. The goal, software that behaves as expected once it ships, can be reached through several distinct services, and a request written around the wrong one produces a shortlist of candidates who cannot actually do the intended work. This page separates a task description from a service name, sets out four pairs of services that get requested as if they were one, covers the case where a single task genuinely calls for two named services, and closes with a question that checks whether a vendor's idea of a service name matches the buyer's own.

A task description names a goal, a service name names a method

"We need testing before the release" states a goal: nothing should break once the release ships. A vendor's catalog listing is organized around a different unit than a goal, the method used to reach it. A goal can be reached by a person following a written script, by an automated suite running inside a build pipeline, or by a structured session that observes real users attempting a task. Each of those methods has a separate name in a vendor's list of services, and a request that only states the goal leaves the vendor to guess which one applies.

Adding detail to the goal narrows it without turning it into a service name. "We need testing on the checkout page before the release" still names an outcome. Naming the service means saying whether the checkout page needs a person clicking through it once, an automated script wired into the pipeline that runs on every commit, or a check that the page renders and behaves the same across a defined set of browsers and screen sizes. The last three sentences describe three different services, and the difference is worth stating in the first message instead of left for a vendor to infer from context.

Four service pairs that get requested as one

Several service names sound close enough that a request written around one word can reach the wrong list of candidates.

Usability testing and accessibility testing both study how a real person uses an interface, and the two get treated as one request more often than any other pair on this list. Usability testing observes a general user attempting a task and records where they hesitate or fail. Accessibility testing checks the same interface against a written standard, most often WCAG, using assistive technology such as a screen reader, and reports conformance instead of observed friction. A request for one does not cover the other, since a page can pass a usability session while failing several WCAG criteria that a sighted, unassisted participant would never trigger.

Compatibility testing and mobile app testing get confused for the opposite reason: both cover a build running somewhere other than the one machine it was built on, and the "somewhere" is what separates them. Compatibility testing runs the same build across combinations of browser, operating system, and screen size, much of it in simulated or virtual environments. Mobile app testing runs the build on physical handsets or on a device cloud, which is where faults tied to a specific chipset, sensor, or firmware version show up. A request written as "device testing" reaches neither list cleanly: the catalog keeps that wording for connected hardware under the name IoT and device testing, which covers firmware, a companion app, and the cloud service behind them together.

API testing and performance testing both send requests to a service interface, which is why a request for one often arrives worded as the other. API testing checks whether each call returns the correct contract, handles a malformed request, and fails in a defined way. Performance testing sends a high volume of the same calls to measure throughput, latency, and resource use as volume rises. A vendor can confirm every contract is correct under API testing and still have never measured what happens to the same interface under load. The catalog carries the second one under the name performance testing, so a request worded as load testing, stress testing, or scalability testing reaches the same list of candidates as a request worded around performance.

Acceptance testing and regression checking both run late in a release cycle, which is the source of the confusion between them. Acceptance testing checks a build against a list of business conditions agreed in advance, usually with the customer present or reviewing the result directly. A regression check confirms that functionality already working in production has survived a recent change, against conditions nobody re-agrees for each cycle. A build can pass every acceptance condition and still carry a regression the acceptance list was never written to catch. The second half of that pair has no separate service name in the catalog: a request worded as regression testing reaches the manual testing list, and a buyer who wants it running automatically on every commit has to say so, since that scope belongs to test automation.

When one task calls for two service names

A single business task can require two services named separately in the request, and writing it as one produces a proposal that only covers half the work. A release aimed at several language markets is a common case: the translated build needs a check for layout, truncated text, and locale-specific formatting, which the catalog lists as localization testing, and it separately needs a functional check confirming the build still behaves correctly in each target locale, which falls under manual testing or test automation depending on what already exists for that product. A request that only says "test the French version" can be answered with either half alone, and both halves are needed before a market launch.

The same pattern shows up wherever a release combines a new capability with a strict non-functional requirement, such as a checkout flow that both needs new functional coverage and has to hold up under a traffic spike on launch day. Writing the request as two named services, each with its own scope line, produces a proposal that prices and staffs them separately, instead of one blended estimate that a buyer cannot later break apart to check.

Confirming a vendor means the same service

Two vendors that both list the same service name on their site do not necessarily deliver the same set of checks under that name, since no regulator fixes the boundary of what counts as usability testing or compatibility testing. Before a contract is signed, ask the vendor to describe what the deliverable for the named service contains and what it explicitly excludes. An answer for accessibility testing should name the standard checked against and state whether assistive-technology testing with real screen-reader software is included or billed as a separate add-on. An answer for API testing should state whether the deliverable includes a load figure at all, since a report with no load numbers in it is still a complete API testing deliverable.

A vendor that cannot list what falls outside the deliverable is answering from the same vague level as the original task description, and the naming problem this page opened with has not actually been solved. A vendor that lists specific exclusions has translated the request into the same terms the buyer used to write it, which is the point at which a shortlist can be compared on the same service instead of on five different guesses at what the word meant.