Voice Messages Testing Checklist (2026)

Voice Messages Testing Checklist (2026) provides a comprehensive, actionable list for verifying voice message functionality across mobile and web applications. In 2026, voice messaging remains a core

Voice Messages Testing Checklist (2026) – Overview and Scope

Voice Messages Testing Checklist (2026) provides a comprehensive, actionable list for verifying voice message functionality across mobile and web applications. In 2026, voice messaging remains a core communication channel in social, collaboration, and customer‑support apps, driven by richer media experiences and tighter integration with AI‑powered transcription. A robust checklist ensures that teams catch regressions early, meet accessibility mandates, and protect user privacy while maintaining high performance. This guide groups 30+ concrete test items into logical areas—happy path, error handling, edge/boundary cases, accessibility, security/privacy, performance, and release readiness—each with clear pass criteria and real‑world examples. After the detailed sections, a quick‑reference table summarizes the checklist for easy copy‑paste into test management tools, and a final section shows how autonomous exploration with the SUSATest platform can cover most of these items in a single pass, generating regression scripts automatically.

What Constitutes a Voice Message Feature

A voice message feature typically includes: a record button that captures audio from the device microphone, a preview waveform or amplitude indicator, a send/upload action that transmits the audio blob to a backend service, a playback control in the conversation view, and UI elements that signal sending, delivering, and read states. Depending on the product, additional capabilities may exist: voice‑to‑text transcription, optional encryption, duration limits, and the ability to attach voice messages to other media (images, locations). The checklist below assumes a baseline implementation but notes variations where relevant.

Why a Checklist Matters in 2026

Regulatory pressure around accessibility (WCAG 2.2) and data protection (GDPR, CCPA, emerging AI‑act clauses) has increased, making ad‑hoc testing insufficient. Moreover, voice messages introduce unique failure modes—such as partial uploads caused by intermittent connectivity or battery‑saver throttling—that are not exercised by traditional UI‑only test suites. A structured checklist translates these risks into verifiable steps, enabling both manual testers and automation engineers to work from the same source of truth. It also serves as a training artifact for new hires and a communication bridge with product owners who need evidence of compliance before a release.

Scope of the Checklist

The items cover functional correctness, usability under constraints, non‑functional qualities, and operational readiness. While the list is exhaustive for most consumer‑grade apps, teams developing specialized voice‑centric products (e.g., dictation software, voice‑driven IoT controls) may need to add domain‑specific tests such as speaker identification or noise‑cancellation validation. Each item includes a pass criterion phrased as a observable outcome, making it straightforward to automate or execute manually.

Voice Messages Testing Checklist (2026) – Happy Path Test Cases

Happy‑path testing validates that the core voice‑message flow works as expected under normal conditions. The following sub‑sections break the flow into discrete, verifiable steps.

Sending a Voice Message

1. Record Initiation – Tapping the record button changes its visual state (e.g., fills with a red circle) and starts audio capture within 200 ms. Pass criterion: the app displays a recording indicator and begins showing a live waveform.
2. Audio Capture Quality – Recorded audio is saved in the configured format (e.g., Opus in an Ogg container, 48 kHz, mono) with no clipping. Pass criterion: a post‑record analysis shows peak amplitude below -3 dBFS and no audible distortion.
3. Cancel During Recording – Swiping left or tapping a cancel button discards the buffer and returns to the idle state without sending. Pass criterion: no network request is made, and the UI reverts to the default record button appearance.
4. Send Action – Upon releasing the record button (or tapping a separate send icon), the app uploads the audio file to the messaging endpoint using HTTPS with appropriate headers (Content‑Type: audio/ogg). Pass criterion: a 200‑OK response is received within 5 seconds on a stable Wi‑Fi network, and the message bubble transitions to a “sending” state.

Receiving and Playback

1. Incoming Message Indicator – When a voice message arrives, the conversation list shows a badge or icon (e.g., a microphone) and the message bubble appears with a play button. Pass criterion: the UI updates within 1 second of the push notification arrival.
2. Playback Controls – Tapping the play button starts audio output through the selected audio route (speaker, headset, or Bluetooth). Pass criterion: audio begins within 300 ms, waveform animation syncs with playback, and the button toggles to a pause icon.
3. Seek and Pause – Dragging the seek bar moves playback to the requested timestamp; pausing halts audio and retains the seek position. Pass criterion: seek accuracy within ±5 % of total duration, and resume continues from the exact point.
4. Completion State – After playback reaches the end, the button reverts to the play icon, and a “played” visual cue (e.g., faint fill) appears. Pass criterion: no auto‑replay occurs unless the user explicitly repeats.

UI Indicators and Notification Handling

1. Sending State Animation – While uploading, a spinner or progress bar appears on the message bubble. Pass criterion: the animation is smooth (60 fps) and disappears only after the server ACK.
2. Delivery and Read Receipts – Upon server confirmation of storage, the bubble shows a single check; upon recipient playback, a double check appears. Pass criterion: checkmarks update within 2 seconds of the respective events.
3. Notification Tapping – Tapping a voice‑message notification opens the conversation at the exact message and auto‑starts playback if the app is in the foreground. Pass criterion: the conversation scrolls to the message, and playback begins without extra taps.
4. Background Playback – If the user navigates away while a voice message plays, audio continues in the background and respects system audio focus rules (ducks when another app requests focus). Pass criterion: audio persists, and the notification panel shows a persistent playback control.

Storage Persistence

1. Local Cache – Sent and received voice messages are stored encrypted in the app’s sandbox for offline replay. Pass criterion: files are accessible only via the app’s private directory, and attempting to read them with a file manager yields “permission denied”.
2. Sync Across Devices – When the user logs into a secondary device, previously sent/received voice messages appear in the conversation history. Pass criterion: messages appear within 10 seconds of login, and playback works identically to the primary device.

Each happy‑path item can be automated using UI‑driven frameworks (Appium for native, Playwright for web) combined with audio‑validation libraries (e.g., pydub for waveform analysis, ffmpeg to verify codec). The next sections extend this baseline to failure modes and edge conditions.

Voice Messages Testing Checklist (2026) – Error Handling and Failure Scenarios

Error handling ensures the app degrades gracefully when something goes wrong, preserving data integrity and providing clear feedback to the user.

Network Failure

1. Loss of Connectivity During Upload – Simulate turning off Wi‑Fi or enabling airplane mode after the record button is released but before the server ACK. Pass criterion: the app shows a “failed to send” toast, retains the message in a draft queue, and retries automatically when connectivity restores.
2. Intermittent Packet Loss – Use a network‑throttling tool (e.g., tc on Linux or Network Link Conditioner on macOS) to inject 10 % loss. Pass criterion: upload completes (thanks to retransmission at the transport layer) or fails with a clear error after a configurable timeout (e.g., 15 seconds).
3. DNS Resolution Failure – Point the device to an invalid DNS server. Pass criterion: the app displays a network‑error dialog with an option to retry, and no crash occurs.

Server‑Side Errors

1. HTTP 500 Internal Server Error – Mock the backend to return 500. Pass criterion: the app treats it as a transient failure, shows a generic “try again later” message, and queues the message for retry.
2. HTTP 413 Payload Too Large – Send a voice message that exceeds the server’s max size limit (e.g., 25 MB). Pass criterion: the app validates size client‑side, blocks the send, and shows an informative toast (“Message too large – limit 25 MB”).
3. Invalid Content‑Type Response – Server replies with text/html instead of expected JSON. Pass criterion: the app detects the mismatch, logs an error, and falls back to a safe UI state without crashing.

Client‑Side Validation Errors

1. Missing Microphone Permission – Deny permission at runtime. Pass criterion: tapping the record button prompts a system permission dialog; if denied, the app shows a permanent inline explanation (“Enable microphone to send voice messages”) and disables the record button.
2. Unsupported Audio Format – Attempt to send a pre‑recorded file with an unsupported codec (e.g., WAV PCM 16‑bit). Pass criterion: the app rejects the file, displays “Unsupported format”, and does not crash.
3. Zero‑Length Recording – User taps record and immediately releases. Pass criterion: the app treats this as an invalid attempt, shows a toast (“Recording too short”), and does not create a network request.

User‑Initiated Aborts

1. Swipe to Cancel While Uploading – Allow the user to drag the message bubble away during upload. Pass criterion: upload is aborted, any partial server storage is cleaned up (backend must support DELETE on upload‑ID), and the UI returns to the idle state.
2. Force‑Close App During Recording – Kill the process via recent‑apps swipe. Pass criterion: on relaunch, the app recovers to a clean state with no orphaned audio file left in temporary storage; any ongoing upload is treated as failed and queued for retry.

Each error case should be verified with both manual injection (using device settings) and automated scripts that manipulate network interfaces or mock servers (e.g., using mitmproxy or WireMock). Clear, user‑friendly messages and absence of crashes are the core pass criteria.

Voice Messages Testing Checklist (2026) – Edge and Boundary Conditions

Edge/boundary tests push the feature to its limits, exposing issues that rarely appear in everyday use but can cause severe defects in production.

Duration Limits

1. Minimum Viable Duration – Record for the shortest allowable time (often 0.5 s). Pass criterion: the app accepts the clip, uploads it, and the recipient can play it back without audible glitches.
2. Maximum Allowed Duration – Record up to the configured ceiling (e.g., 10 minutes). Pass criterion: recording does not drop frames, the file size stays within the expected limit, and playback is smooth end‑to‑end.
3. Beyond Maximum Duration – Attempt to record past the limit (e.g., hold record for 12 minutes when max is 10). Pass criterion: the app automatically stops recording at the limit, shows a toast (“Maximum length reached”), and sends the truncated clip.

File Size and Storage Pressure

1. Low Storage Condition – Fill the device’s internal storage to leave < 10 MB free. Pass criterion: recording still succeeds (audio cached temporarily), but the app warns the user (“Low storage – may affect saving”) and, if unable to persist the file, prevents sending and offers to free space.
2. Concurrent Recordings – In a multi‑chat scenario, start recording in one conversation, then switch to another and start a second recording before the first is sent. Pass criterion: each recording is isolated; the app either disallows concurrent recordings with a clear message or queues them sequentially, ensuring no cross‑talk or corrupted files.

Background and Foreground Transitions

1. App Sent to Background Mid‑Record – Press home while the record button is held. Pass criterion: recording pauses, the UI shows a persistent notification with a resume button, and audio capture resumes when the app returns to foreground.
2. Screen Orientation Change – Rotate device while recording or playback. Pass criterion: the waveform view adapts without losing audio sync, and no UI elements are clipped.
3. Multi‑Window Mode – Run the app in split‑screen with another app that also uses the microphone (e.g., a VOIP call). Pass criterion: the system correctly routes audio focus; your app either yields the mic gracefully (pausing recording) or notifies the user of the conflict.

Locale and Language Variations

1. Right‑to‑Left (RTL) Layout – Switch device language to Arabic or Hebrew. Pass criterion: all icons (record, send, play) mirror correctly, and touch targets remain accessible.
2. Non‑Latin Characters in Transcription – If voice‑to‑text is enabled, speak a phrase in Japanese or Hindi. Pass criterion: the returned text matches the spoken content within an acceptable word error rate (< 15 %).

Accessibility Overlays

1. TalkBack/VoiceOver Interaction – Enable a screen reader and navigate to the record button. Pass criterion: the button is labeled (“Record voice message, double tap to start”), and gestures (double‑tap, long‑press) trigger the expected actions without ambiguous announcements.
2. Font Size Scaling – Increase system font to 200 %. Pass criterion: all labels and buttons scale proportionally, no text is truncated, and the waveform view remains usable.

These edge cases are often missed by scripted UI tests that follow a single happy path. Incorporating them into a combinatorial test matrix (e.g., using pairwise testing tools) dramatically increases defect detection early in the cycle.

Voice Messages Testing Checklist (2026) – Accessibility (WCAG) Considerations

Accessibility testing verifies that people with disabilities can perceive, operate, and understand the voice‑message feature. The checklist maps directly to WCAG 2.2 success criteria.

Perceivable

1. Non‑Text Contrast – The waveform or play button must have a contrast ratio of at least 3:1 against its background. Pass criterion: measured with a contrast analyzer, all states (idle, active, disabled) meet the threshold.
2. Audio‑Only Alternative – Provide a visible transcript or caption toggle for each voice message. Pass criterion: activating the toggle shows synchronized text that highlights the current spoken word ( karaoke style ) and can be copied to clipboard.
3. Resizable Text – Ensure that any textual UI (e.g., “Send”, “Playing…”) respects the user’s preferred text size without breaking layout. Pass criterion: at 200 % scaling, no horizontal scrolling is required and all controls remain tappable.

Operable

1. Keyboard Navigation – On WebView, or hybrid apps** – All voice‑message controls must be reachable via Tab and activatable via Enter or Space. Pass criterion: logical tab order follows visual flow, and focus rings are visible.
2. Adequate Touch Target Size – Record, play, and cancel buttons must be at least 48 × 48 dp (or equivalent CSS pixels). Pass criterion: measured with a UI inspector, no target falls below the threshold.
3. Adjustable Timing – If the app auto‑advances to the next message after playback, provide a way to extend or disable the timer. Pass criterion: a user‑accessible setting lets them set the interval to “off” or a minimum of 10 seconds.

Understandable

1. Clear Labels and Instructions – Icons alone are insufficient; each button must have an accessible label. Pass criterion: screen readers announce “Record voice message button”, “Play voice message button”, etc.
2. Error Identification – When a voice message fails to send, the error message must describe the problem and suggest a fix. Pass criterion: toast or dialog contains text like “Failed to send – check your connection and try again”.
3. Consistent Navigation – The location of voice‑message controls should be consistent across chat screens. Pass criterion: automated visual regression tests confirm that the record button appears in the same corner (±5 dp) on all conversation pages.

Robust

1. Compatibility with Assistive Technologies – Test with the latest versions of TalkBack, VoiceOver, Switch Control, and Android Accessibility Suite. Pass criterion: all core tasks (record, send, playback, cancel) are achievable without sighted assistance.
2. Status Updates for Dynamic Content – When a message transitions from sending to delivered, the change must be announced. Pass criterion: screen readers speak “Message sent” or “Message delivered” as appropriate.

Automated accessibility audits can be run with tools like axe-core (for web) or Accessibility Test Framework (ATF) for Android, integrated into CI pipelines. Manual exploratory sessions with users who rely on assistive tech remain indispensable for validating nuanced interactions.

Voice Messages Testing Checklist (2026) – Security and Privacy Checks

Voice messages often contain personal or sensitive information; therefore, security and privacy testing is non‑negotiable.

Transport Security

1. TLS Enforcement – Verify that all audio uploads and downloads use TLS 1.2 or higher. Pass criterion: packet capture (e.g., with Wireshark) shows no plain‑text HTTP and the TLS version is ≥ 1.2.
2. Certificate Pinning – If the app pins the server certificate, test that a man‑in‑the‑middle attempt with a self‑signed cert is blocked. Pass criterion: the network request fails with a clear SSL handshake error, and the app does not fall back to insecure mode.

End‑to‑End Encryption (E2E) – Optional but Increasingly Common

1. Encryption Key Exchange – If E2E is offered, confirm that keys are generated via a authenticated Diffie‑Hellman exchange and that the private key never leaves the device. Pass criterion: inspecting app memory (via adb shell run-as) shows no plain‑text key material after session establishment.
2. Ciphertext Verification – Send a voice message and capture the network payload. Pass criterion: the uploaded blob is indistinguishable from random noise (entropy > 7.5 bits/byte) and does not contain the original audio signature.
3. Key Rotation – Simulate a long‑running conversation; after a set number of messages, verify that the app negotiates new session keys. Pass criterion: subsequent payloads differ in IV/nonce and decrypt correctly only with the new key.

Permission and Data Minimization

1. Just‑In‑Time Permission Request – The app should request microphone access only when the user attempts to record. Pass criterion: no permission prompt appears at app launch; the prompt appears after tapping the record button, and the rationale string explains why the mic is needed.
2. Metadata Stripping – Ensure that uploaded audio files do not embed device‑identifying metadata (e.g., GPS coordinates, device model) unless explicitly required. Pass criterion: using ffprobe on the uploaded file shows no comment or location tags.

Secure Storage

1. Encryption at Rest – Stored voice messages in the app’s sandbox should be encrypted with a device‑bound key (e.g., Android Keystore or iOS Keychain). Pass criterion: attempting to copy the file to external storage results in unreadable binary; decryption only succeeds via the app’s API.
2. Automatic Deletion – After a message is played and the user opts to delete it, the file should be securely erased (overwritten) rather than merely unlinked. Pass criterion: forensic recovery tools cannot retrieve the original audio from the freed blocks previously deleted file locations.

Replay Attack Mitigation

1. Nonce/Timestamp in Request – Each upload should include a server‑generated nonce or timestamp that is checked for freshness. Pass criterion: replaying a captured request results in a 401 Unauthorized response with a “nonce expired” message.
2. Rate Limiting – Attempt to send a high volume of voice messages (e.g., 100 per minute) from a single account. Pass criterion: the server responds with 429 Too Many Requests after a configured threshold, and the client backs off exponentially.

Privacy Policy and User Controls

1. Transparency About Retention – The app’s settings must disclose how long voice messages are retained on the server and provide a control to delete history. Pass criterion: navigating to Settings → Privacy shows a clear statement and a “Delete all voice messages” button that removes server‑side copies upon confirmation.
2. Do‑Not‑Track / Analytics Opt‑Out – If analytics collect voice‑message metadata (e.g., length, frequency), provide an opt‑out. Pass criterion: toggling the opt‑out stops the transmission of analytics events related to voice messages, verified via network inspection.

Security testing often benefits from automated scanners (OWASP ZAP, MobSF) combined with manual pen‑testing for logic flaws (e.g., permission bypass). The pass criteria above are observable, making them suitable for both automated assertions and manual checklists.

Voice Messages Testing Checklist (2026) – Performance and Load Testing

Performance testing ensures that voice‑message features do not degrade the app’s responsiveness or device battery life under realistic loads.

Launch and Responsiveness

1. Impact on App Startup – Measure cold start time with and without the voice‑message module initialized (e.g., via lazy loading). Pass criterion: the difference is ≤ 150 ms on a mid‑tier device (Snapdragon 7 Gen 2 or equivalent).
2. UI Thread Load During Recording – Capture the main‑thread frame timing while recording a 30‑second message. Pass criterion: 95 % of frames stay under 16 ms (60 fps) with occasional spikes allowed only during permission dialogs.

Resource Consumption

1. CPU Usage – Use adb shell top or Instruments to sample CPU while recording, uploading, and playing back. Pass criterion: average CPU usage ≤ 25 % of a single core during active recording; ≤ 10 % during idle playback.
2. Memory Footprint – Track heap growth via Android Studio Profiler or Xcode Memory Graph. Pass criterion: no unbounded increase; temporary buffers are released after each operation, leaving a steady‑state increase of ≤ 5 MB.
3. Battery Drain – Run a script that simulates sending and receiving 50 voice messages over 30 minutes with screen off. Pass criterion: battery loss ≤ 5 % compared to a baseline idle run on the same device.

Network Efficiency

1. Upload Throughput – On a stable 5 Mbps uplink, time the upload of a 2‑minute Opus file. Pass criterion: upload completes within 110 % of the theoretical file‑size‑over‑bandwidth time (allowing for TCP overhead).
2. Adaptive Bitrate – If the app adapts audio codec based on network quality, throttle the connection to 200 kbps and verify that the selected bitrate drops accordingly without breaking playback. Pass criterion: the server receives a file with a lower bitrate (e.g., 16 kbps Opus) and the client can still decode it.

Concurrency and Stress

1. Multiple Simultaneous Conversations – Open five chat windows, each with an ongoing voice‑message exchange (send/receive every 10 seconds). Pass criterion: UI remains responsive, no audio dropouts, and message ordering is preserved per conversation.
2. Stress Under Background Audio – Play a music stream from another app while recording a voice message. Pass criterion: the recording captures only the user’s voice (background music is attenuated by ≤ 20 dB) and the system correctly handles audio focus (your app may lower its volume or pause recording per policy).

Performance validation is best automated with CI‑friendly tools like gradle’s connectedAndroidTest combined with adb shell am profile start/stop or Xcode’s xcodebuild test with signpost intervals. Baselines should be established on representative devices (low‑end, mid‑tier, flagship) to catch regressions early.

Voice Messages Testing Checklist (2026) – Release Readiness and Regression Automation

Release readiness consolidates all previous areas into a shippable state, ensuring that the team can confidently promote a build to production.

Test Suite Coverage

1. Unit Test Ratio – Aim for ≥ 80 % unit‑test coverage on voice‑message‑related classes (audio encoder, network client, state machine). Pass criterion: coverage report shows the threshold met; new code must not decrease overall coverage.
2. Integration Test Scenarios – Maintain a set of end‑to‑end tests that cover happy path, two error cases, and one edge case per major release. Pass criterion: all integration tests pass on the CI pipeline for every commit to main.
3. Flakiness Mitigation – Identify and eliminate non‑deterministic tests (e.g., those depending on exact timing). Pass criterion: each test exhibits a pass rate ≥ 98 % over 50 consecutive runs on a clean agent.

CI/CD Integration

1. Automated Build Gates – The pipeline blocks promotion if any voice‑message test fails, performance threshold is exceeded, or accessibility audit reports violations. Pass criterion: a red gate stops the merge request, requiring fixes before re‑run.
2. Canary Analysis – Deploy a canary build to 5 % of users and monitor key metrics (crash rate, ANR, voice‑message send latency). Pass criterion: canary metrics stay within 10 % of the baseline production metrics for a 24‑hour window.

Documentation and Knowledge Transfer

1. Test Artifacts Versioning – Store test plans, scripts, and baseline performance numbers in the repository under docs/voice-message-testing. Pass criterion: a new hire can clone the repo and run the full test suite with a single command (./gradlew voiceMessageTest).
2. Release Notes Includ­ing Test Summary – Each release notes section includes a bullet summarizing voice‑message test outcomes (e.g., “All 32 checklist items passed; performance within 5 % of baseline”). Pass criterion: release notes are generated automatically from the test‑run JSON artifact.

Rollback and Hotfix Procedures

1. Feature Flag for Voice Messages – Guard the voice‑message entry point with a remote‑config flag that can be toggled off without redeploy. Pass criterion: flipping the flag to off removes the record button and disables any related background services, verified by inspecting the UI and checking for absence of audio‑related wakelocks.
2. Hot‑Fix Validation – When a critical bug is found post‑release, the fix must be verified against the full checklist before being promoted. Pass criterion: the hot‑fix branch passes all checklist items on a clean staging environment before being merged to release.

By treating the checklist as a living document—updated whenever the voice‑message specification changes—teams maintain a reliable gate that catches regressions before they affect users.

Voice Messages Testing Checklist (2026) – Using Autonomous Exploration (SUSA) to Cover the Checklist

Autonomous testing platforms can exercise many of the checklist items without writing explicit test scripts. SUSATest, for example, explores an app by simulating real‑user behaviors across multiple personas, automatically detecting crashes, ANRs, accessibility violations, and more. When pointed at an APK or a web URL, it attempts to send and receive voice messages as part of its exploratory flows, generating a comprehensive report that can be mapped directly to the checklist.

How SUSA Explores Voice Messages

SUSA begins by crawling the UI to locate interactive elements that resemble a record button (based on content‑description, iconography, and position). Once found, it initiates a recording using the device’s microphone, captures the audio stream, and then attempts to send it via the app’s networking layer. The platform’s built‑in personas—such as “impatient” (quick taps, early cancels) and “elderly” (longer presses, deliberate navigation)—produce variations in timing and interaction patterns that surface edge cases like accidental cancels or delayed releases. Throughout the exploration, SUSA monitors system logs for crashes, ANRs, and excessive resource consumption, while also running an accessibility scanner (axe‑core for web, Android’s Accessibility Test Framework for native) on each visited screen.

Configuring Personas for Targeted Coverage

• Curious Persona – Explores every reachable screen, increasing the likelihood of finding hidden voice‑message entry points (e.g., inside a settings menu or attachment picker).
• Adversarial Persona – Sends malformed inputs, such as rapidly tapping the record button while the microphone permission dialog is visible, testing the app’s handling of race conditions.
• Power‑User Persona – Performs rapid successive recordings and sends, checking for buffer leaks or concurrency bugs under load.
• Accessibility Persona – Employs screen‑reader navigation and high‑contrast modes to verify that labels and touch targets meet WCAG criteria.

By enabling a combination of these personas in a single test run, the platform can cover happy‑path, error, and accessibility items simultaneously.

Automatic Regression Script Generation

After a run, SUSA exports the discovered flows as Appium (Android) or Playwright (Web) test scripts. For example, a generated Appium test might look like:

@Test
public void testVoiceMessageSendAndPlayback() {
    // Locate record button by accessibility id
    MobileElement recordBtn = driver.findElementByAccessibilityId("record_voice");
    recordBtn.click(); // start recording
    // Simulate a 3‑second recording
    Thread.sleep(3000);
    recordBtn.click(); // stop and send
    // Wait for