How to test a messaging app

Direct answer

Shipped untested, a messaging app lets a child account be pulled into a group chat or call with an adult the parent never approved, and leaves chat history, attachments or contact lists on the phone readable by other apps or copied into an unprotected backup. 8 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with end-to-end functional tests: a group invite from an approved friend is the path that puts a child account in a chat with an unapproved adult, so it is tested before notices, scans or load.

8 mandatory testsfirst: end-to-end functional tests

What counts as a messaging app

A messaging app here is a chat product on iOS, Android, desktop and web for one-to-one and group conversations with photos, voice notes and calls, often with end-to-end encryption and contact upload from the address book. It covers delivery, attachments, chat history stored on the phone, contact sync, push alerts, supervised child accounts and reconnect behaviour after peaks. Social networks with a public ranked feed and team collaboration suites sold to companies are out of scope.

Adjacent product types not covered here

  • social network: A social network ranks public posts in a feed for users who include teens, so what the algorithm suggests and public-by-default profiles lead instead of address book notices and reconnect storms.
  • dating app: A dating app connects strangers and sells premium features, so romance scams and disputed renewals replace contact-upload notices and group invites to child accounts.
  • video conferencing tool: A video conferencing product runs scheduled meetings with join links, so uninvited joiners and missing captions lead instead of address book uploads and group invites to child accounts.

Risk map

6 risks attached to messaging app with evidence. Sorted by severity.
RiskGradeNoteEvidence
Physical or psychological harm to a user
user-harm
harmprimaryA child account added to a group chat or group call by an approved contact ends up talking to an adult the parent never approved.
Fine or enforcement by a regulator
regulatory-penalty
legalprimaryThe privacy notice does not tell users, or the non-users whose numbers arrive in uploaded address books, what is shared with group companies.
Personal or sensitive data exposed
data-breach
datasecondary
by design analysis
Chat history, attachments or contact lists stored on the phone are readable by other apps or copied into an unprotected backup when the phone is lost or shared.
Third-party dependency fails
dependency-failure
outagepractitioner
single incident, no second source
A cloud network gateway in front of the chat backend fails to scale with reconnect traffic.
Outage during a demand peak
outage-under-load
outageprimaryAfter a holiday every client reconnects at once with a cold cache and downloads channel history, and the reconnect storm takes the service down.
App rejected or removed by a store
store-rejection
distributionprimaryA build without report and block inside a conversation is rejected under the user-generated content rules.

Mandatory tests (8)

  1. Step 1: release smoke tests

    Why:store-rejection

    Done when: On the release build, two test users on different platforms exchange a text, a photo and a voice note, each item shows as delivered, and report and block appear in the chat.

    Tool class: mobile automation. Who usually runs it: QA engineer.

  2. Step 2: end-to-end functional tests

    Why:user-harm

    Done when: A child account cannot be added to a group, call or chat by anyone outside its approved contacts, including through a group invite from an approved friend.

    Tool class: mobile automation. Who usually runs it: QA engineer.

  3. Step 3: compliance checks

    Why:regulatory-penaltystore-rejection

    Done when: A reviewer confirms the privacy notice states what happens to uploaded address books and what is shared with group companies, and report and block appear in every one-to-one and group chat.

    Tool class: test management. Who usually runs it: product manager.

  4. Step 4: security scanning

    Why:data-breach

    Done when: The scan report shows no open finding on message, attachment and contact-sync endpoints, and the scan of each app build flags no chat data written to shared storage or left in unprotected backups.

    Tool class: DAST scanner. Who usually runs it: security specialist.

  5. Step 5: penetration testing

    Why:data-breach

    Done when: A tester with one account cannot fetch another user's attachment by guessing its link, cannot read another user's chat history from the server, and finds no chat content in the phone's shared storage or unprotected backup.

    Tool class: proxy. Who usually runs it: security specialist.

  6. Step 6: resilience and failure testing

    Why:dependency-failureoutage-under-load

    Done when: With the network gateway or cache tier throttled, clients back off, connected users keep sending messages, and the service recovers without manual restarts.

    Tool class: chaos tool. Who usually runs it: developer.

  7. Step 7: integration tests

    Why:dependency-failure

    Done when: With the cloud network gateway in front of the chat backend switched off in staging and then restored, phones reconnect without the app freezing, every message sent during the outage arrives once and each recipient gets one notification.

    Tool class: API client. Who usually runs it: developer.

  8. Step 8: performance and load testing

    Why:outage-under-load

    Done when: A reconnect of all simulated clients at once, with empty caches, completes without errors and without new logins being refused.

    Tool class: load generator. Who usually runs it: developer.

Recommended and optional tests

  • unit testsrecommended

    Becomes mandatory when encryption, ordering or delivery receipt logic changes.

  • regression suiterecommended

    Becomes mandatory when more than one client team ships to the same release.

  • accessibility testingrecommended

    Becomes mandatory when the app is offered in a market where an accessibility law covers it or a complaint arrives.

  • device and browser compatibilityrecommended

    Becomes mandatory when out-of-order or missing messages between clients appear in support tickets.

  • offline and poor-network testingrecommended

    Becomes mandatory when lost or duplicated messages on mobile networks show up in support tickets.

  • contract testsoptional

    May help when desktop and web clients release on a different schedule from the API.

  • usability testingoptional

    May help when users miss group privacy settings in research sessions.

  • localization testingoptional

    May help when the app ships right-to-left languages.

Not needed and why

  • exploratory testing

    Not needed: users only chat with contacts they already have. Becomes recommended when the app adds public channels or discovery of strangers.

  • data integrity and migration testing

    Not needed: message history stays in one store. Becomes recommended when message history migrates to a new store.

  • analytics and event tracking tests

    Not needed: no ad or analytics SDK reads chat data. Becomes recommended when an ad or attribution SDK is added.

Order of work

First release

  1. release smoke tests: On the release build, have two test users on different platforms exchange a text, a photo and a voice note, check each shows as delivered and check that report and block appear in the chat.
  2. end-to-end functional tests: Try to add a test child account to a group, call or chat from outside its approved contacts, including through a group invite from an approved friend.
  3. compliance checks: Confirm the privacy notice states what happens to uploaded address books and what is shared with group companies, and that report and block appear in every one-to-one and group chat.
  4. security scanning: Scan the message, attachment and contact-sync endpoints and close every open finding.
  5. penetration testing: Have a tester with one account try to fetch another user's attachment by guessing its link and read another user's chat history from the server, then search the test phone's shared storage and its unprotected backup for chat content.
  6. resilience and failure testing: Throttle the network gateway and the cache tier and confirm clients back off, connected users keep sending and the service recovers without manual restarts.
  7. integration tests: Switch off the cloud network gateway in front of the chat backend in staging, send messages, restore it and confirm phones reconnect without freezing, every message sent during the outage arrives once and each recipient gets one notification.
  8. performance and load testing: Reconnect all simulated clients at once with empty caches and confirm no errors and no refused logins.

Ongoing cadence

  • release smoke tests: On every client build before store submission or desktop release.
  • performance and load testing: Before each holiday period, public event or other expected reconnect peak.
  • penetration testing: After each change to attachment links, server-side chat history access or how the app stores chats on the phone.
  • compliance checks: When the privacy notice, contact upload or data sharing with group companies changes.
  • integration tests: When the cloud network gateway in front of the chat backend or its configuration changes.
  • unit tests: On every merge that changes encryption, ordering or delivery receipt logic.
  • regression suite: On every release once more than one client team ships to the same release.

Tools

Listed alphabetically inside each test type, filtered to the tests above and to the platforms of messaging app (ios, android, desktop, web). Not recommendations.

37 tools shown

release smoke tests

  • Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
  • TestRailTest case and run management. webiosandroidapicommercial
  • XrayTest management inside Jira. webiosandroidapicommercial

end-to-end functional tests

  • AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
  • ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
  • BrowserStackCloud of real devices and browsers. webiosandroidcommercial
  • CypressBrowser-based end-to-end testing with a visual runner. webfreemium
  • DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
  • EspressoAndroid UI testing framework from Google. androidopen-source
  • LambdaTestCloud browser and device grid. webiosandroidcommercial
  • MaestroMobile UI flows written in YAML. iosandroidfreemium
  • PercyVisual review of UI changes. webcommercial
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
  • Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
  • SeleniumWebDriver-based browser automation. webopen-source
  • XCTestApple's framework for unit and UI tests. iosopen-source

security scanning

  • Burp SuiteProxy and scanner for web application security testing. webapifreemium
  • mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
  • MobSFStatic and dynamic analysis for mobile binaries. iosandroidopen-source
  • OWASP ZAPDynamic application security scanner. webapiopen-source
  • SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
  • SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium

penetration testing

  • Burp SuiteProxy and scanner for web application security testing. webapifreemium

integration tests

  • Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
  • JestJavaScript test runner with mocking and snapshots. webapiopen-source
  • JUnitTest framework for the JVM. apiandroidopen-source
  • VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
  • XCTestApple's framework for unit and UI tests. iosopen-source

performance and load testing

  • ArtilleryLoad testing with YAML scenarios. apiwebfreemium
  • GatlingLoad testing with Scala, Java or Kotlin scenarios. apiwebfreemium
  • JMeterLoad testing tool from the Apache Foundation. apiwebopen-source
  • k6Load testing scripted in JavaScript. apiwebopen-source
  • LighthouseAudits for accessibility and performance in Chrome. webopen-source
  • LocustLoad testing scripted in Python. apiwebopen-source

unit tests

  • JestJavaScript test runner with mocking and snapshots. webapiopen-source
  • JUnitTest framework for the JVM. apiandroidopen-source
  • VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
  • XCTestApple's framework for unit and UI tests. iosopen-source

regression suite

  • CypressBrowser-based end-to-end testing with a visual runner. webfreemium
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
  • TestRailTest case and run management. webiosandroidapicommercial
  • XrayTest management inside Jira. webiosandroidapicommercial

accessibility testing

  • Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
  • axe-coreAccessibility rules engine for automated checks. webopen-source
  • LighthouseAudits for accessibility and performance in Chrome. webopen-source
  • Pa11yCommand-line accessibility testing. webopen-source

device and browser compatibility

  • AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
  • ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
  • BrowserStackCloud of real devices and browsers. webiosandroidcommercial
  • Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
  • LambdaTestCloud browser and device grid. webiosandroidcommercial
  • PercyVisual review of UI changes. webcommercial
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
  • SeleniumWebDriver-based browser automation. webopen-source

offline and poor-network testing

  • Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
  • mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
  • Network Link ConditionerApple tool for simulating poor network conditions. iosopen-source

What to send to the person who will test

Send the checklist and the brief below. The printable checklist for messaging app has the same 8 items with checkboxes.

Download the checklistMarkdownCSVBrief (Markdown)

Acceptance criteria wording

A release of the messaging app is accepted when two test users on different platforms exchange a text, a photo and a voice note marked delivered, and report and block appear in every one-to-one and group chat. A child account cannot be added to a group or call from outside its approved contacts, no attachment or chat history of another user can be fetched with one test account, and no chat content is found in the phone's shared storage or unprotected backup. All simulated clients reconnecting at once with empty caches, and phones reconnecting after the cloud network gateway in front of the chat backend is restored, complete without errors, refused logins or duplicate notifications.

Brief

# Test brief: messaging app

Product type: messaging app. One-to-one and group chat with media and encryption.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/messaging-app/
Printable checklist: https://howtotestaproduct.com/checklists/messaging-app/

Run these 8 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: store-rejection). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: On the release build, two test users on different platforms exchange a text, a photo and a voice note, each item shows as delivered, and report and block appear in the chat.
2. end-to-end functional tests (risks: user-harm). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: A child account cannot be added to a group, call or chat by anyone outside its approved contacts, including through a group invite from an approved friend.
3. compliance checks (risks: regulatory-penalty, store-rejection). Tool class: test management. Usually run by: product manager.
   Done when: A reviewer confirms the privacy notice states what happens to uploaded address books and what is shared with group companies, and report and block appear in every one-to-one and group chat.
4. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist.
   Done when: The scan report shows no open finding on message, attachment and contact-sync endpoints, and the scan of each app build flags no chat data written to shared storage or left in unprotected backups.
5. penetration testing (risks: data-breach). Tool class: proxy. Usually run by: security specialist.
   Done when: A tester with one account cannot fetch another user's attachment by guessing its link, cannot read another user's chat history from the server, and finds no chat content in the phone's shared storage or unprotected backup.
6. resilience and failure testing (risks: dependency-failure, outage-under-load). Tool class: chaos tool. Usually run by: developer.
   Done when: With the network gateway or cache tier throttled, clients back off, connected users keep sending messages, and the service recovers without manual restarts.
7. integration tests (risks: dependency-failure). Tool class: API client. Usually run by: developer.
   Done when: With the cloud network gateway in front of the chat backend switched off in staging and then restored, phones reconnect without the app freezing, every message sent during the outage arrives once and each recipient gets one notification.
8. performance and load testing (risks: outage-under-load). Tool class: load generator. Usually run by: developer.
   Done when: A reconnect of all simulated clients at once, with empty caches, completes without errors and without new logins being refused.

Acceptance criteria wording:
A release of the messaging app is accepted when two test users on different platforms exchange a text, a photo and a voice note marked delivered, and report and block appear in every one-to-one and group chat. A child account cannot be added to a group or call from outside its approved contacts, no attachment or chat history of another user can be fetched with one test account, and no chat content is found in the phone's shared storage or unprotected backup. All simulated clients reconnecting at once with empty caches, and phones reconnecting after the cloud network gateway in front of the chat backend is restored, complete without errors, refused logins or duplicate notifications.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.

For founders: what to forward and what to ask back. For product managers: turning this page into tickets.

Questions about testing a messaging app

What testing does a messaging app need?

8 tests are mandatory, each tied to one of the 6 risks in the map, such as child accounts pulled into groups with unapproved adults, chat content left readable on the phone and reconnect storms that take the service down. Penetration testing checks guessed attachment links, access to other users' chat history and the phone's shared storage and backup. Unit, regression, accessibility, compatibility and offline tests are recommended, each with the event that makes it mandatory.

What gets a messaging app rejected by an app store?

The map attaches store rejection at primary grade: a build without report and block inside a conversation is rejected under the user-generated content rules. The release smoke check confirms report and block appear in the chat on every build, and compliance checks confirm them in every one-to-one and group chat.

What does GDPR mean for testing a messaging app?

The map cites the Irish Data Protection Commission's decision on a messaging app whose privacy notice did not tell users, or non-users whose numbers arrive in uploaded address books, what is shared with group companies. Compliance checks confirm the notice covers uploaded address books and sharing with group companies. Security scanning covers the contact-sync endpoint.

When is test automation worth it for a messaging app?

The release smoke check runs on every client build, and performance tests of a full reconnect with empty caches run before each expected peak. Unit tests of ordering and delivery receipts become mandatory when that logic changes. The regression suite becomes mandatory once more than one client team ships to the same release.

Which tests in a vendor test plan for a messaging app are not needed?

Exploratory testing is not needed while users only chat with contacts they already have, and becomes recommended when public channels or discovery of strangers are added. Data integrity testing is not needed while message history stays in one store. Analytics tests are not needed while no ad or analytics SDK reads chat data, and become recommended when an ad or attribution SDK is added.

Evidence

  1. ev-0285regulatorprimary

    FTC Proposes Blanket Prohibition Preventing Facebook from Monetizing Youth Data, Federal Trade Commission

    Supports user-harm for a messaging app with child accounts: a group chat and group call path let children reach contacts their parents had not approved.

    published 2023-05-03 · verified 2026-10-07

  2. ev-0284regulatorprimary

    Data Protection Commission announces decision in WhatsApp inquiry, Data Protection Commission (Ireland)

    The DPC's investigation examined whether WhatsApp has discharged its GDPR transparency obligations with regard to the provision of information and the transparency of that information.

    Supports regulatory-penalty for a messaging app: the inquiry covered what a chat app tells users and non-users about processing of their data, including sharing with group companies.

    published 2021-09-02 · verified 2026-10-07

  3. ev-0013standardprimary

    OWASP Mobile Application Security Verification Standard (MASVS), OWASP Foundation

    MASVS defines security requirements for mobile apps, including secure storage, network communication and authentication.

    published undated · verified 2026-10-07

  4. ev-0286post-mortemprimary

    Slack's Outage on January 4th 2021, Slack Engineering

    On January 4th, one of our Transit Gateways became overloaded. The TGWs are managed by AWS and are intended to scale transparently to us.

    Supports outage-under-load and dependency-failure for a messaging app: clients returning after the holidays reconnected with cold caches, and a cloud-managed network gateway did not scale with the surge.

    published 2021-02-01 · verified 2026-10-07

  5. ev-0287post-mortemprimary

    Slack's Incident on 2-22-22, Slack Engineering

    When the whole system is in overload, retries increase load and make recovery less likely, so clients should ideally avoid sending requests until the system has recovered.

    Supports outage-under-load for a messaging app: a cache tier emptied by restarts met peak traffic, and users whose chat client was not already connected could not connect.

    published 2022-04-26 · verified 2026-10-07

  6. ev-0001store-guidelineprimary

    App Review Guidelines, Apple

    Apple reviews every iOS, iPadOS and macOS App Store submission against these guidelines, including crashes and bugs at review, privacy disclosures, in-app purchase rules and extra rules for medical, financial and kids apps, and apps with user-generated content must let users report offensive content and block abusive users (guideline 1.2), and apps offering loot boxes or similar mechanisms must disclose the odds of each item type before purchase (guideline 3.1.1).

    published undated · verified 2026-10-07

  7. ev-0220store-guidelineprimary

    User Generated Content, Google Play

    Provides an in-app system for reporting and blocking objectionable UGC and users, and taking action against UGC or users where appropriate.

    Supports store-rejection: the policy requires report and block for features with one-to-one user interaction such as direct messages, which is the core of a dating app and a messaging app.

    published undated · verified 2026-10-07

Disclaimer

This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.