How to Write Test Cases for Voice Messages (With Examples)

How to Write Test Cases for Voice Messages (With Examples):

How to Write Test Cases for Voice Messages (With Examples):

This guide gives you a complete, practical method for creating high‑value test cases for voice‑message features in mobile or web applications. You will learn the anatomy of a test case, how to derive positive, negative, edge, and boundary scenarios, how to set up test data, prioritize effort, and trace each case to requirements. A worked matrix of 20+ concrete examples is provided, followed with a checklist and a short takeaway section you can bookmark for future reference.

How to Write Test Cases for Voice Messages (With Examples) – Test Case Anatomy

A test case is a structured artifact that tells a tester *what* to do, *under what conditions*, and *what to expect*. For voice messages the artifact must capture audio‑specific dimensions such as file format, duration, encoding, and transmission path.

Elements of a test case

When you write the steps, use imperative verbs and keep each action atomic. Avoid bundling multiple UI interactions into a single step; this makes failures easier to locate. For voice messages, include a step that explicitly checks the audio payload (e.g., “Verify that the uploaded file is a valid Opus‑encoded .ogg file”).

Writing steps for voice interactions

Because voice input is temporal, you must specify how the tester will produce the audio. Options:

• Manual speaking – instruct the tester to say a specific phrase (“Hello test”) for a measured duration.
• Pre‑recorded file – use a tool like adb push to load a .wav/.ogg file onto the device and then invoke a “play file” command that the app treats as microphone input (some test frameworks allow injecting audio).
• Silence or noise – generate a file of known silence or white noise to test edge cases.

Document the exact method in the “Steps” column so that another engineer can reproduce the test without ambiguity.

Expected result details

For voice messages the expected result often has multiple facets:

1. UI – the message bubble appears, waveform or play button is shown.
2. Metadata – duration, timestamp, sender ID are correct.
3. Media – the file can be downloaded, played back without distortion, and matches the original input (bit‑for‑bit or perceptually similar).
4. Side effects – push notification sent, recipient sees unread badge, storage quota updated.

List each facet as a bullet under “Expected result” to avoid missing any during execution.

How to Write Test Cases for Voice Messages (With Examples) – Positive Test Cases

Positive tests verify that the happy path works as intended. They form the baseline confidence that the core voice‑message flow is functional.

Successful recording and sending

• ID: VM‑001
• Preconditions: User A is logged in, microphone permission granted, network Wi‑Fi connected.
• Steps:

1. Navigate to a one‑on‑one chat with User B.
2. Press and hold the voice‑record button.
3. Speak the phrase “Positive test message” for approximately three seconds.
4. Release the button.
5. Tap the send icon that appears.

• Expected result:
• A voice‑message bubble appears in the chat view for User A.
• The bubble shows a waveform and a duration label of “0:03”.
• The message is transmitted to the server and appears in User B’s chat within two seconds.
• User B receives a push notification (if enabled).
• Tapping the bubble plays the audio with no audible distortion.

Playback controls

• ID: VM‑002
• Preconditions: A voice message of known duration (e.g., 0:07) exists in the chat.
• Steps:

1. Tap the voice‑message bubble to open the playback UI.
2. Press the play button.
3. After two seconds, press the pause button.
4. Press the seek bar to jump to five seconds.
5. Press play again.

• Expected result:
• Audio plays from start, pauses at the correct timestamp, resumes from the seek position, and finishes at the end.
• The UI updates the elapsed time label accordingly.
• No crash or ANR occurs during any interaction.

Receiving and downloading

• ID: VM‑003
• Preconditions: User A has sent a voice message; User B is offline at the moment of sending.
• Steps:

1. User B comes online and opens the chat.
2. Wait for the message to appear (may require pull‑to‑refresh).
3. Tap the download icon (if the app does not auto‑download).

• Expected result:
• The message downloads fully (progress bar reaches 100%).
• The file size on disk matches the server‑sent size (within 5 % tolerance).
• Playback works identically to the sender’s version.

These three cases cover the core loop: record → send → receive → play. They are usually automated first because they have deterministic outcomes.

How to Write Test Cases for Voice Messages (With Examples) – Negative and Invalid Input Cases

Negative tests confirm that the app handles erroneous conditions gracefully, without crashing or corrupting data.

Missing microphone permission

• ID: VM‑010
• Preconditions: App installed, user logged in, microphone permission denied (set via device settings).
• Steps:

1. Open a chat and tap the voice‑record button.

• Expected result:
• A system‑level permission dialog is shown (or the app shows a custom rationale).
• No recording starts; the button returns to idle state.
• No error toast appears that reveals stack traces.

Exceeding maximum file size

• ID: VM‑011
• Preconditions: App configured with a maximum voice‑message size of 256 KB. A test audio file of 300 KB is ready.
• Steps:

1. Use adb to push the 300 KB file to /sdcard/Download/big.ogg.
2. In the chat, choose “Attach file” → select the big.ogg file as a voice message (if the UI allows file attachment for voice).

• Expected result:
• The app shows an inline error: “Voice message too large (max 256 KB)”.
• The message is not sent.
• No crash occurs; the UI remains responsive.

Unsupported file format

• ID: VM‑012
• Preconditions: User has microphone permission.
• **granted.
• Steps:

1. Start recording.
2. While recording, rename the temporary file on the filesystem to .txt (using a root shell or a test harness that can intercept the file‑file:///

(If the app writes, you may attempt to send after recording.)

Expected result:

• The app detects the invalid format upon attempting to upload.
• It shows a toast: “Unsupported audio format”.
• The recording is discarded and the UI returns to ready state.

Network loss during upload

• ID: VM‑013
• Preconditions: User logged in, microphone granted, Wi‑Fi connected.
• Steps:

1. Begin recording a five‑second message.
2. After two seconds of recording, disable Wi‑Fi (or enable airplane mode).
3. Finish recording and attempt to send.

• Expected result:
• The app detects no network and shows a retryable error: “Failed to send voice message. Check connection.”
• The message is stored locally in an outbox queue.
• When network is restored, the app automatically retries and sends the message successfully.

These negative cases protect against common failure modes: permission problems, size limits, format mismatches, and intermittent connectivity.

How to Write Test Cases for Voice Messages (With Examples) – Edge and Boundary Cases

Edge cases push the system to its limits, often revealing bugs that only appear under unusual but realistic conditions.

Zero‑duration (tap‑and‑release instantly)

• ID: VM‑020
• Preconditions: User logged in, microphone permission granted.
• Steps:

1. Tap the voice‑record button and release it immediately (less than 0.1 s).

• Expected result:
• The app either discards the attempt and shows a hint: “Message too short” or accepts a zero‑length file and sends it.
• In either case, the app does not crash.
• If accepted, the recipient sees a bubble with duration “0:00” that plays silently.

Maximum allowed duration

• ID: VM‑021
• Preconditions: Configured maximum voice‑message length = 60 seconds.
• Steps:

1. Press and hold the record button.
2. Speak continuously for 60 seconds (use a metronome app to keep steady speech).
3. Release the button exactly at 60 s.

• Expected result:
• Recording stops automatically at the limit (if the UI enforces a hard stop).
• The sent message shows duration “1:00”.
• Playback lasts exactly 60 seconds without truncation.

Exceeding maximum duration

• ID: VM‑022
• Preconditions: Same as VM‑021.
• Steps:

1. Record for 65 seconds (continue speaking after the UI indicates limit).

• Expected result:
• The app either stops recording at 60 seconds and ignores extra input, or it shows an error: “Maximum length exceeded”.
• No crash; the UI stays usable.

Silent audio (noise floor)

• ID: VM‑023
• Preconditions: Microphone permission granted.
• Steps:

1. Cover the microphone with a finger to produce near‑silence.
2. Record for three seconds.
3. Send the message.

• Expected result:
• The transmitted file contains audio samples near zero amplitude.
• Playback produces no audible sound but the duration is correct.
• The waveform display shows a flat line.

Background noise and music

• ID: VM‑024
• Preconditions: Microphone permission granted, ambient music playing at 70 dB.
• Steps:

1. Record a spoken phrase while music continues.
2. Send the message.

• Expected result:
• The uploaded file contains both voice and background music.
• Playback is intelligible; voice is not completely masked.
• No clipping or distortion beyond what is expected from the codec.

Concurrent recordings (fast double‑tap)

• ID: VM‑025
• Preconditions: User logged in.
• Steps:

1. Tap the record button twice in quick succession (< 200 ms between taps).

• Expected result:
• The app prevents a second recording session while one is active (either ignores the second tap or shows a toast: “Already recording”).
• Only one voice message is created.

Interrupt handling (incoming call)

• ID: VM‑026
• Preconditions: User logged in, microphone granted.
• Steps:

1. Start recording a voice message.
2. After two seconds, simulate an incoming call (using adb shell am broadcast -a android.intent.action.PHONE_STATE).
3. End the call.

• Expected result:
• Recording pauses when the call starts.
• After call ends, the app either resumes recording (if allowed) or discards the partial recording and shows: “Recording interrupted”.
• No crash or leaked audio resources.

Locale‑specific characters in voice‑message transcription (if applicable)

• ID: VM‑027
• Preconditions: App provides speech‑to‑text transcription for voice messages; device locale set to Japanese.
• Steps:

1. Record a phrase containing kana and kanji: “こんにちは、テストです”.
2. Send the message.

• Expected result:
• Transcription text matches the spoken phrase (allowing for reasonable recognition error).
• The UI displays the text correctly without garbled characters.

These edge cases help you uncover timing, resource, and concurrency bugs that often slip through basic positive/negative suites.

How to Write Test Cases for Voice Messages (With Examples) – Data Setup and Test Environment

Reliable voice‑message testing depends on reproducible audio artifacts and controlled device states.

Generating test audio files

Use command‑line tools to create predictable files:

# 1‑second silent PCM wav (16‑bit, 44.1kHz)
silence=$(ffmpeg -f lavfi -i anullsrc=r=44100:cl=mono -t 1 -qscale:a 0 -ar 44100 -ac 1 -f wav silence.wav 2>/dev/null)

# 5‑second sine wave at 440 Hz (A4)
ffmpeg -f lavfi -i "sine=frequency=440:duration=5" -ar 44100 -ac 1 -f wav tone_440hz.wav

# White noise 10 seconds
ffmpeg -f lavfi -i "anoisesrc=color=white:duration=10" -ar 44100 -ac 1 -f wav white_noise.wav

Store these files in a version‑controlled test-data/audio/ directory. Reference them by relative path in your test‑management tool or test script.

Device preparation

• Permissions – Grant or revoke microphone via adb shell pm grant android.permission.RECORD_AUDIO or revoke.
• Network simulation – Use tools like tc (Linux traffic control) or Facebook’s Network Link Conditioner to emulate latency, packet loss, or bandwidth limits. Example:

# Limit to 100 kbps uplink, 200 ms latency
tc qdisc add dev wlan0 root netem rate 100kbit delay 200ms

• Locale & timezone – Set via adb shell setprop persist.sys.language ja and adb shell setprop persist.sys.region JP, then reboot.

Test‑data versioning

Because audio files can be large, store them in Git LFS or an internal artifact repository. Tag each set with a version (e.g., audio-set-v1.2) and reference that version in the test case’s “Test data” field. This makes it trivial to reproduce a failure months later.

Mock server for upload/download

If you want to avoid hitting a real backend during CI, spin up a lightweight mock using Node.js and Express:

const express = require('express');
const multer  = require('multer');
const upload = multer({ dest: 'uploads/' });
const app = express();

app.post('/api/voice', upload.single('voice'), (req, res) => {
  // Echo back file metadata
  res.json({ size: req.file.size, mimetype: req.file.mimetype });
});

app.get('/api/voice/:id', (req, res) => {
  // Serve a pre‑stored file
  res.sendFile(__dirname + `/uploads/${req.params.id}.ogg`);
});

app.listen(3000, () => console.log('Mock voice API listening on :3000'));

Point the app under test to http://10.0.2.2:3000 (Android emulator host alias) via a DNS override or API‑endpoint configuration flag.

How to Write Test Cases for Voice Messages (With Examples) – Prioritization and Traceability

Not all test cases carry equal weight. Use a risk‑based matrix to decide which to automate first, which to keep manual, and which to de‑prioritize.

Prioritization criteria

Calculate a priority score = Σ (factor rating × weight). Cases scoring ≥ 15 are high priority, 10‑14 medium, < 10 low.

Traceability to requirements

Create a simple requirements‑to‑test matrix. Example requirement IDs from a hypothetical spec:

Maintain this matrix in a spreadsheet or a test‑management tool (e.g., TestRail, Zephyr). When a requirement changes, you can instantly see which test cases need review.

How to Write Test Cases for Voice Messages (With Examples) – Manual and Automated Approaches

Combining manual exploratory testing with automated regression yields the best coverage for voice messages.

Manual exploratory testing

• Session‑based test charters – Allocate 45‑minute sessions with a specific focus, e.g., “Test voice‑message behavior under fluctuating network”.
• Heuristics to apply –
• *Interrupted*: Simulate calls, alarms, or other apps taking audio focus.
• *Varied input*: Whisper, shout, speak in different languages, hum.
• *Device states*: Low battery, storage nearly full, overheating.
• Observation checklist – While exploring, note:
• Does the UI give immediate feedback when recording starts/stops?
• Are there any visual glitches in the waveform renderer?
• Does the app respect the system’s “Do not disturb” mode (no notification sound while recording)?

Manual testing shines for discovering UX friction, unexpected audio clipping, and accessibility issues that automated scripts may miss because they rely on deterministic assertions.

Automated regression with scripting

For repeatable validation of the happy path and defined negative cases, write scripts that drive the UI and verify audio artifacts.

#### Appium (Android) example

@Test
public void testSendVoiceMessage() throws Exception {
    // Assume driver is set up and user is logged in
    MobileElement recordBtn = driver.findElementById("com.example.app:id/voice_record");
    recordBtn.click(); // start recording (long press simulated by TouchAction)
    new TouchAction(driver)
        .press(recordBtn)
        .waitAction(Duration.ofMillis(3000))
        .release()
        .perform();

    MobileElement sendBtn = driver.findElementById("com.example.app:id/voice_send");
    sendBtn.click();

    // Wait for message bubble to appear
    WebDriverWait wait = new WebDriverWait(driver, 10);
    MobileElement bubble = wait.until(
        ExpectedConditions.visibilityOfElementLocated(By.id("com.example.app:id/voice_bubble"))
    );

    // Verify duration text
    assertEquals("0:03", bubble.findElementById("com.example.app:id/duration").getText());

    // Pull the uploaded file from device storage for bit‑check
    String remotePath = "/sdcard/Android/data/com.example.app/files/voice/msg_123.ogg";
    String localPath = "build/voice/msg_123.ogg";
    PullFile pull = driver.pullFile(remotePath);
    Files.write(Paths.get(localPath), pull.getContent(), StandardOpenOption.CREATE);
    // Compare with original tone file (pre‑generated)
    assertTrue(Files.mismatch(Paths.get(localPath), Paths.get("src/test/resources/tone_440hz.wav")) == -1);
}

*The script records by holding the button for three seconds, sends, then pulls the resulting file from the device to compare with a reference.*

#### Playwright (Web) example

If your product also offers a web client, you can automate voice capture via the MediaRecorder API using a fake stream:

test('can send voice message on web', async ({ page }) => {
  await page.goto('https://app.example.com/chat');
  await page.click('#voice-record');

  // Provide a fake audio stream (silence) to the page
  await page.evaluate(() => {
    const fakeStream = new MediaStream([
      new AudioTrack({ enabled: true, label: 'fake', kind: 'audio' })
    ]);
    // Override getUserMedia to return our fake stream
    navigator.mediaDevices.getUserMedia = () => Promise.resolve(fakeStream);
  });

  await page.waitForTimeout(3000); // record 3 s
  await page.click('#voice-send');

  const bubble = page.locator('.voice-bubble');
  await expect(bubble).toBeVisible();
  await expect(bubble.locator('.duration')).toHaveText('0:03');

  // Optionally, intercept the upload request and validate the blob
  await page.route('**/api/voice', route => {
    const request = route.request();
    const form = new FormData();
    form.append('voice', new Blob([new Uint8Array(0)], { type: 'audio/ogg' }));
    return route.fulfill({ status: 200, body: JSON.stringify({ok:true}) });
  });
});

Leveraging SUSA for autonomous exploration

SUSA can be pointed at the APK or the web URL and will autonomously generate interaction sequences that include voice‑message actions. After a run, SUSA outputs:

• A set of discovered flows (e.g., “Record → Send → Play → Delete”).
• Regression scripts in Appium (Android) and Playwright (Web) format, ready to commit to your CI pipeline.
• A coverage report showing which screens and edge conditions (like permission denial or network throttling) were exercised.

To incorporate SUSA into your workflow:

# Install the agent
pip install susatest-agent

# Run against an Android APK
susatest run --app ./app-release.apk \
    --device emulator-5554 \
    --output ./susa-report \
    --formats appium,playwright

# For a web target
susatest run --url https://chat.example.com \
    --browser chrome \
    --output ./susa-report \
    --formats playwright

The generated Appium/Playwright scripts can be merged with the manual test cases you wrote earlier, giving you a hybrid suite that benefits from both directed verification and exploratory discovery.

How to Write Test Cases for Voice Messages (With Examples) – Worked Test Matrix (20+ Examples)

Below is a consolidated table that you can copy into a test‑management tool. Each row includes ID, preconditions, steps, and expected result. Feel free to add columns for priority, tags, or linked requirement IDs as needed.