How do you test speech-to-text and dictation automatically?
Speech-to-text testing verifies what happens after a user talks to your app: that dictated words land in the right field, that a longer recording produces a usable transcript, and that your app sent the right request to its transcription endpoint. QA.tech automates it by streaming a real audio clip into the browser's microphone during a test run, then asserting on the outcome like any other test. The capability behind it is covered on the voice testing product page.
Sub-use-cases
Covers Dictation into form fields, long-recording transcription, voice notes and messages, transcript accuracy and ASR request assertions.
- 01
What speech-to-text testing covers
Three kinds of flow, in practice. Dictation, where a user speaks into a form field and expects to see their words appear. Transcription, where a longer clip becomes a note, a summary or a document. And voice messages, where the recording itself is the payload and the app has to capture, store and play it back to someone else. They share one property: the input is a microphone, so the usual test tooling can't reach them. A scripted framework can fill a text field in milliseconds. It cannot speak.
- 02
How does an agent test dictation without mocking WebRTC?
The traditional route is to fake the microphone: launch the browser with a fake-device flag, feed it a file, and maintain the WebRTC plumbing that holds it together. QA.tech skips the plumbing. You attach the clip to your project as an Audio Input config, then write one natural-language step: play the audio into the microphone, then check the transcript. The agent grants the mic permission itself, streams the file as live microphone input at the right moment, and carries on with the rest of the flow. You supply the clips, which is a feature rather than a chore – your product's vocabulary, your users' phrasing, the accents that show up in support tickets.
- 03
What to assert on: the transcript, the field, the request
The clip going in is the easy half. Assert the visible result (the dictated text appears where it should), the triggered behaviour (dictating an address fills the address form), and the network layer (the browser called your transcription endpoint with the right method and payload and got the response your app expects). When the UI looks fine but the ASR call silently failed over to a fallback, that last assertion is the one that catches it. Every run comes with the full evidence trail – steps, screenshots and the network log.
- 04
When to run dictation tests
Put the dictation flows that must never break in a small scheduled regression plan, and let PR testing run dynamic checks on changes that touch the speech path. A pull request that bumps your speech SDK is precisely the one that should trigger a mic test before merge.
- 05
How QA.tech helps
Most teams with a mic button test it by talking at a laptop before release, so a model swap, an SDK update or a prompt tweak degrades the feature quietly while every scheduled suite stays green. QA.tech runs the real spoken flow as an ordinary test case on the AI QA testing platform, with the transcript, the UI outcome and the request all assertable in one run.
FAQ
Common questions
- How do you test dictation automatically?
- Attach an audio file of the phrase to your project as an Audio Input config. During the run, the QA.tech agent grants microphone permission, streams the clip into the browser's mic input, and then asserts that the dictated text appeared where it should. To the app, it is indistinguishable from a person speaking.
- Can QA.tech verify transcription accuracy?
- Yes, at the level a tester would: the test asserts that the transcript in the UI contains what the clip said, or that specific phrases came through correctly. You define the bar in the test. For deeper checks, assert on the request and response your app exchanged with its transcription endpoint.
- Does speech-to-text testing work in native mobile apps?
- Audio input testing runs in Chrome against a web page's microphone, so it covers web apps, including mobile-web viewports. For voice features inside a native iOS or Android app, see mobile testing and talk to us about your setup.
- Can the agent assert on audio your app plays back?
- Not yet. Voice testing currently covers audio going in; output validation isn't part of it. Verify the result through UI state or network traffic instead.
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
Smoke Testing
Next →Subscription & Billing Flow 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.