How to test a telemedicine app

Shipped untested, a telemedicine app keeps charging a patient while a membership cancellation requested in the app is still pending and lets its visit and refill flows distribute a stimulant such as Adderall over the internet, in the membership and refill flows. 9 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: one pass from intake through a video visit to a pharmacy prescription shows whether a stimulant refill is held until a clinician documents a new assessment.

9 mandatory testsfirst: end-to-end functional tests

What counts as a telemedicine app

A telemedicine app here means an iOS, Android or web product where patients consult clinicians by video or chat, receive prescriptions and see visit records. It counts when the app handles PHI, ships through app stores and runs live visits on scheduled slots. A patient portal that shows records and messages without live visits is out of scope, and so is a self-guided therapy app with no prescribing clinician.

Adjacent product types not covered here

patient portal: A patient portal shows records and messages from an existing provider and carries no live video visit, appointment-slot load or prescribing risk.
mental health app: A mental health app centres on mood data and therapy subscriptions, where the main exposure is questionnaire answers reaching ad platforms rather than controlled-drug prescriptions.
pharmacy delivery app: A pharmacy delivery app receives and dispenses prescriptions, so its risks sit in refill limits and the prescription gate rather than the visit that produced them.

Risk map

7 risks attached to telemedicine app with evidence. Sorted by severity.
Risk		Grade	Note	Evidence
Physical or psychological harm to a user user-harm	harm	practitioner single incident, no second source	Online visit and refill flows are used to distribute a stimulant such as Adderall over the internet, the scheme federal prosecutors alleged against one digital health company's founder and clinical president.	ev-0175
Money leaves or fails to arrive money-loss	money	primary	A patient asks to cancel the monthly care membership in the app, the cancellation runs through several steps, and the card is charged for next month's visits while the request is pending.	ev-0142
Accessibility complaint or lawsuit accessibility-liability	legal	primary	A patient using a screen reader cannot find the join-visit button in the waiting room or read the clinician's in-call chat messages.	ev-0016
Fine or enforcement by a regulator regulatory-penalty	legal	primary	The symptom questionnaire before a video visit fires an ad pixel with the patient's answers, or a controlled-drug prescription goes out without the prescriber's DEA status recorded.	ev-0170 ev-0174
Personal or sensitive data exposed data-breach	data	primary	A shared login session opens another patient's visit notes, and a clinician who left the practice can still read charts from past video visits.	ev-0142
Outage during a demand peak outage-under-load	outage	practitioner single incident, no second source	A release before morning clinic leaves too few servers, and patients booked for the first slots cannot check in to the virtual waiting room.	ev-0173
App rejected or removed by a store store-rejection	distribution	secondary by design analysis	The store reviewer signs in with the demo account, finds no clinician available to start a visit, and rejects the build as incomplete.	ev-0001 ev-0002

Mandatory tests (9)

Step 1: release smoke tests
Why:store-rejection outage-under-load
Done when: On the release build, a test patient books a visit, enters the waiting room and sees and hears the test clinician once the clinician admits them.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 2: end-to-end functional tests
Why:user-harm regulatory-penalty
Done when: A test patient completes intake, a video visit and a prescription to the chosen pharmacy, and a stimulant refill request is held until a clinician documents a new assessment.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 3: payment and money-flow testing
Why:money-loss
Done when: After a test patient cancels the membership in the app, the payment sandbox shows no further charge on the next billing date.
Tool class: API client. Who usually runs it: QA engineer.
Step 4: compliance checks
Why:regulatory-penalty data-breach
Done when: A reviewer confirms that every controlled-substance prescription record shows the prescriber's registration and the patient's state, and that the HIPAA risk analysis covers the video and chat services.
Tool class: test management. Who usually runs it: product manager.
Step 5: analytics and event tracking tests
Why:data-breach regulatory-penalty
Done when: A network capture of sign-up, symptom intake, booking and visit screens shows no symptom, drug name or visit reason sent to any advertising or analytics domain.
Tool class: proxy. Who usually runs it: QA engineer.
Step 6: accessibility testing
Why:accessibility-liability
Done when: A screen reader user books a visit, joins the video room and reads the clinician's chat messages without sighted help.
Tool class: accessibility checker. Who usually runs it: accessibility specialist.
Step 7: security scanning
Why:data-breach
Done when: The scan report for the app, API and video signalling service lists no open high-severity finding on the release date.
Tool class: DAST scanner. Who usually runs it: security specialist.
Step 8: penetration testing
Why:data-breach
Done when: A tester logged in as patient A cannot open patient B's visit notes, prescriptions or chat, and a deactivated clinician account cannot open any chart.
Tool class: proxy. Who usually runs it: security specialist.
Step 9: performance and load testing
Why:outage-under-load
Done when: With as many test patients as join in the busiest appointment slot, every one reaches the waiting room and the clinician admits each without an error.
Tool class: load generator. Who usually runs it: developer.

Recommended and optional tests

integration testsrecommended
Becomes mandatory when prescriptions go to pharmacies through an e-prescribing network rather than by fax or phone.
exploratory testingrecommended
Becomes mandatory when the app adds asynchronous visits where a clinician prescribes from a questionnaire alone.
resilience and failure testingrecommended
Becomes mandatory when the video service is a third-party provider with a history of incidents that blocked visits.
device and browser compatibilityrecommended
Becomes mandatory when support tickets show video or camera permission failures on specific devices.
data integrity and migration testingrecommended
Becomes mandatory when visit notes are exported to a partner EHR or migrated between systems.
offline and poor-network testingrecommended
Becomes mandatory when evidence shows visits dropping on mobile networks and patients losing their place in the queue.
unit testsoptional
May help on the scheduling code that maps appointment times across the patient's and clinician's time zones.
regression suiteoptional
May help once intake, booking and prescribing flows change every release and past fixes start to reappear.

Not needed and why

contract tests
Not needed while the app and its backend are built and released by the same team. Becomes recommended when a pharmacy, lab or EHR partner consumes the visit API.
usability testing
Not needed as a separate study while booking and joining are covered by end-to-end and accessibility tests. Becomes recommended when patients abandon the waiting room before the clinician joins.
localization testing
Not needed while intake and visits run in one language. Becomes recommended when intake or interpreter booking ships in a second language.

Order of work

First release

release smoke tests: Book a visit as a test patient on the release build, enter the waiting room and confirm the patient sees and hears the test clinician after being admitted.
end-to-end functional tests: Take a test patient through intake, a video visit and a prescription to the chosen pharmacy, then request a stimulant refill and confirm it is held for a new assessment.
payment and money-flow testing: Cancel a test membership in the app and confirm the payment sandbox shows no charge on the next billing date.
compliance checks: Review every controlled-substance prescription record for the prescriber's registration and the patient's state, and check that the HIPAA risk analysis covers the video and chat services.
analytics and event tracking tests: Capture network traffic across sign-up, symptom intake, booking and visit screens and look for any symptom, drug name or visit reason sent to an advertising or analytics domain.
accessibility testing: Have a screen reader user book a visit, join the video room and read the clinician's chat messages without sighted help.
security scanning: Scan the app, API and video signalling service and clear every open high-severity finding before the release date.
penetration testing: Sign in as patient A and try to open patient B's visit notes, prescriptions and chat, then try to open any chart with a deactivated clinician account.
performance and load testing: Fill the waiting room with as many test patients as join in the busiest appointment slot and confirm the clinician admits each one without an error.

Ongoing cadence

release smoke tests: On every store build.
end-to-end functional tests: After each change to intake, prescribing or refill rules.
analytics and event tracking tests: When any analytics or ad SDK is added or updated in the app or website.
payment and money-flow testing: After each change to membership plans or billing dates.
compliance checks: When controlled-substance prescribing rules change or the app starts serving a new state.
performance and load testing: Before a release that changes server capacity or the appointment slot layout.
penetration testing: When a new role or clinician offboarding path ships.

Tools

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

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

payment and money-flow testing

Adyen test environmentTest cards and scenarios for Adyen integrations. webapiiosandroidcommercial
Stripe test modeTest cards and scenarios for Stripe integrations. webapiiosandroidfreemium

analytics and event tracking tests

AvoTracking plan and event validation. webiosandroidfreemium
Segment ProtocolsTracking plan validation for Segment events. webiosandroidcommercial

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

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

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

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

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 telemedicine app has the same 9 items with checkboxes.

Download the checklist Markdown CSV Brief (Markdown)

Acceptance criteria wording

A release of the telemedicine app is accepted when a test patient books, waits and joins a video visit with the clinician, and a stimulant refill is held until a clinician documents a new assessment. A membership cancelled in the app produces no further charge, and no symptom, drug name or visit reason reaches an advertising or analytics domain. A deactivated clinician account cannot open any chart.

Brief

# Test brief: telemedicine app

Product type: telemedicine app. Video or chat consultations with clinicians, prescriptions and records.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/telemedicine-app/
Printable checklist: https://howtotestaproduct.com/checklists/telemedicine-app/

Run these 9 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, outage-under-load). Tool class: mobile automation. Usually run by: QA engineer.
Done when: On the release build, a test patient books a visit, enters the waiting room and sees and hears the test clinician once the clinician admits them.
2. end-to-end functional tests (risks: user-harm, regulatory-penalty). Tool class: browser automation. Usually run by: QA engineer.
Done when: A test patient completes intake, a video visit and a prescription to the chosen pharmacy, and a stimulant refill request is held until a clinician documents a new assessment.
3. payment and money-flow testing (risks: money-loss). Tool class: API client. Usually run by: QA engineer.
Done when: After a test patient cancels the membership in the app, the payment sandbox shows no further charge on the next billing date.
4. compliance checks (risks: regulatory-penalty, data-breach). Tool class: test management. Usually run by: product manager.
Done when: A reviewer confirms that every controlled-substance prescription record shows the prescriber's registration and the patient's state, and that the HIPAA risk analysis covers the video and chat services.
5. analytics and event tracking tests (risks: data-breach, regulatory-penalty). Tool class: proxy. Usually run by: QA engineer.
Done when: A network capture of sign-up, symptom intake, booking and visit screens shows no symptom, drug name or visit reason sent to any advertising or analytics domain.
6. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist.
Done when: A screen reader user books a visit, joins the video room and reads the clinician's chat messages without sighted help.
7. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist.
Done when: The scan report for the app, API and video signalling service lists no open high-severity finding on the release date.
8. penetration testing (risks: data-breach). Tool class: proxy. Usually run by: security specialist.
Done when: A tester logged in as patient A cannot open patient B's visit notes, prescriptions or chat, and a deactivated clinician account cannot open any chart.
9. performance and load testing (risks: outage-under-load). Tool class: load generator. Usually run by: developer.
Done when: With as many test patients as join in the busiest appointment slot, every one reaches the waiting room and the clinician admits each without an error.

Acceptance criteria wording:
A release of the telemedicine app is accepted when a test patient books, waits and joins a video visit with the clinician, and a stimulant refill is held until a clinician documents a new assessment. A membership cancelled in the app produces no further charge, and no symptom, drug name or visit reason reaches an advertising or analytics domain. A deactivated clinician account cannot open any chart.

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 telemedicine app

What testing does a telemedicine app need?

9 mandatory tests cover the 7 risks in the map, from shared sessions exposing visit notes and ad pixels on symptom intake to stimulants handed out through refill flows and memberships still charged while a cancellation is pending. They run as release smoke, end-to-end, payment sandbox, compliance, analytics tracking, accessibility, security scanning, penetration and performance tests. Integration with an e-prescribing network becomes mandatory when prescriptions stop going by fax or phone.

What gets a telemedicine app rejected by an app store?

The risk map records a rejection when the store reviewer signs in with the demo account, finds no clinician available to start a visit and marks the build incomplete. This risk is labelled by design analysis. The release smoke test covers it: on the release build a test patient books a visit, enters the waiting room and is admitted by a test clinician.

What does HIPAA mean for testing a telemedicine app?

The compliance check is mandatory while the app handles PHI for a covered entity, and its done condition includes a reviewer confirming that the HIPAA risk analysis covers the video and chat services. The analytics tracking test checks that symptom intake sends nothing to ad or analytics domains. The penetration test checks that one patient cannot open another patient's visit notes.

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

Contract, usability and localization tests are marked not needed while one team builds the app and backend, booking and joining are covered by end-to-end and accessibility tests, and visits run in one language. Contract tests become recommended when a pharmacy, lab or EHR partner consumes the visit API.

What goes on a testing checklist for a telemedicine app before launch?

The checklist is the 9 mandatory tests with their done conditions, starting with a release build where a test patient books, waits and is admitted to a video visit. It includes a stimulant refill held for a new assessment, a cancelled membership with no next charge, a network capture of symptom intake with no data sent to ad or analytics domains, and a waiting room filled to the busiest appointment slot.

Evidence

ev-0175court-or-fineprimary
Founder/CEO And Clinical President Of Digital Health Company Arrested For [amount] Adderall Distribution And Health Care Fraud Scheme, U.S. Department of Health and Human Services, Office of Inspector General
Federal enforcement summary: the founder of a digital health company and its clinical president were arrested over an alleged scheme to distribute Adderall over the internet and submit false claims for it. Supports user-harm and regulatory-penalty for telemedicine apps whose visit and refill flows issue controlled-substance prescriptions.
published 2024-06-13 · verified 2026-10-07
ev-0142regulatorprimary
Proposed FTC Order will Prohibit Telehealth Firm Cerebral from Using or Disclosing Sensitive Data for Advertising Purposes, and Require it to Pay [amount], U.S. Federal Trade Commission
The FTC complaint describes pharmacy and prescription information sent to third parties through tracking tools, a patient portal access method that exposed medications to other patients, a failure to block former employees from accessing medical records, and a cancel-anytime promise contradicted by a multi-step, often multi-day cancellation process during which consumers kept being charged. The first two transfer to pharmacy delivery apps; the cancellation finding transfers to any recurring subscription sold online.
published 2024-04-15 · verified 2026-10-07
ev-0016standardprimary
Web Content Accessibility Guidelines (WCAG) 2.2, W3C
WCAG 2.2 is the W3C standard that accessibility law and procurement rules reference; level AA is the usual target.
published undated · verified 2026-10-07
ev-0170regulatorprimary
Alcohol Addiction Treatment Firm will be Banned from Disclosing Health Data for Advertising to Settle FTC Charges that It Shared Data Without Consent, Federal Trade Commission
Monument used the information to target ads for its services to both current users who subscribe to the lowest cost memberships and to target new consumers, according to the complaint.
Enforcement against an online alcohol use disorder treatment service whose pixels and APIs sent intake and treatment events to ad platforms without consent. Supports data-breach and regulatory-penalty for telemedicine apps and for mental health apps, which collect the same kind of intake answers.
published 2024-04-11 · verified 2026-10-07
ev-0174regulatorprimary
Special Registrations for Telemedicine and Limited State Telemedicine Registrations, Drug Enforcement Administration, Federal Register
DEA proposed rule setting registrations for clinicians who prescribe controlled substances over telemedicine and for online platforms that facilitate dispensing. Supports regulatory-penalty for telemedicine apps that route controlled-substance prescriptions; the rule is proposed, so the note in the cell must not present it as final.
published 2025-01-17 · verified 2026-10-07
ev-0173post-mortemprimary
Doxy.me site not loading, Doxy.me Inc.
During the incident, users were unable to access doxy.me for telehealth sessions, leading to delayed or missed appointments and interruptions in patient care.
Official post-mortem from a telehealth video platform: a release lowered the number of active servers, morning traffic overwhelmed the rest, and patients could not check in to their visits. Supports outage-under-load for telemedicine apps, where demand is concentrated at scheduled appointment times.
published 2025-04-29 · verified 2026-10-07
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
ev-0002store-guidelineprimary
Developer Program Policy, Google Play
Google Play applies these policies to every Android app it distributes and can reject, suspend or remove apps that violate them.
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.

How to test a telemedicine app

01Direct answer

02What counts as a telemedicine app

Adjacent product types not covered here

03Risk map

04Mandatory tests (9)

Step 1: release smoke tests

Step 2: end-to-end functional tests

Step 3: payment and money-flow testing

Step 4: compliance checks

Step 5: analytics and event tracking tests

Step 6: accessibility testing

Step 7: security scanning

Step 8: penetration testing

Step 9: performance and load testing

05Recommended and optional tests

06Not needed and why

07Order of work