How do you test voice search automatically?
Voice search testing verifies the full path from a spoken query to the results on screen: the app heard the query, recognised it correctly, and returned what the user asked for. QA.tech automates it by playing a recorded query into the browser's microphone during a test run and asserting on the results, the same way it tests any other search. The capability behind it is covered on the voice testing product page.
Sub-use-cases
Covers Spoken product queries, recognised-query checks, results assertions, search-request payloads and conversational queries.
- 01
What voice search testing should cover
A voice search has two halves, and each fails differently. The recognition half turns speech into a query, and it breaks when a model or SDK changes how it hears things. The search half is your ordinary search stack, and it breaks the way search always breaks: ranking changes, filters misfire, an index goes stale. Typed-search tests only cover the second half – they never exercise recognition, the mic permission flow, or the glue code between them.
- 02
How does an agent run a spoken query?
You record the queries you care about and attach them to your project as Audio Input configs. In the test, one natural-language step plays the clip into the browser microphone right after the mic is activated. The agent handles the permission grant itself, waits for the results, and verifies them. There is no fake-device flag to maintain and no WebRTC mocking – your app processes genuine microphone input in Chrome. Because the clips are yours, the queries are real ones: your top searches, the product names your speech model keeps mishearing, the query from last quarter's bug report.
- 03
What to assert on: results, recognised query, request
A test that only checks the recognised query stops one step short. Assert the results themselves (a spoken product query returns that product – this catches recognition drift and search regressions in one test), the recognised query where your UI shows it, and the search request your browser sent with the recognised query in the payload. Failures come back with screenshots and the network log, so "voice search returned nothing" arrives as a diagnosable trail.
- 04
When to run voice search tests
A small scheduled regression plan holds the voice searches that must never break, plus dynamic tests on every pull request that touches search or speech code. A voice query test sits in the same plan as your typed search and filter tests, and with PR testing a harmless-looking speech SDK bump triggers a real spoken query against the preview deployment before anyone merges.
- 05
How QA.tech helps
The failure mode teams describe is silence: not an error, just a search feature that gradually gets worse at understanding people while the typed-search suite stays green. A developer saying two phrases at a laptop covers two phrases. QA.tech runs your real queries, spoken, on every trigger you already use.
FAQ
Common questions
- How do you test voice search automatically?
- Record the query as an audio clip and attach it to your QA.tech project as an Audio Input config. The agent plays it into the browser's microphone during the test, then asserts on the results page, the recognised query, or the request your app sent to its search endpoint.
- Which queries should a voice search test use?
- Start with your highest-volume searches and the ones that have failed before. Because you supply the recordings, tests can use your real product vocabulary, tricky brand names, and longer conversational queries rather than a vendor's demo phrases.
- Can voice search tests run on every pull request?
- Yes. Voice tests are regular test cases, so they run in AI PR reviews against preview deployments, from CI after a deploy, or on a schedule alongside the rest of your regression plan.
- Does it work outside Chrome?
- Audio input testing runs in Chrome today, against a web page's microphone. Telephony and IVR flows are out of scope.
Related use cases
AI Test Generation
QA.tech generates tests five ways, so coverage can grow from wherever your team already works: a plain-language description, a crawl of your app, an issue tracker, your pull requests, or the API. You review and approve rather than author from scratch, which removes the slowest step in growing coverage.
ReadExploratory Testing
Exploratory testing means investigating an application to discover how it behaves and where it breaks, rather than following a fixed script. AI can do this: an agent clicks through a new or changed feature, finds the flows and edge cases, and proposes test cases for what it sees. With QA.tech this runs automatically when a feature lands.
ReadQA for AI-Generated Code & Agentic SDLC (MCP)
AI coding tools ship faster but don't always see the cross-cutting effects of a change, so bugs accumulate faster too. QA.tech adds the quality layer: connect it via MCP and your coding agent (Claude Code, Cursor, Codex or Continue) can trigger tests, read results, and fix issues – an agentic feedback loop for AI-built features. The `qatech init` command generates Claude Code subagent and skill files directly in your repo, so the build-test-fix loop is usable immediately.
Read
Voice Command Testing
Your team moves fast. Can your testing keep up?
QA.tech agents test your product autonomously, so moving fast never means shipping broken. See how it works in a 30-minute demo.