How to test a pharmacy delivery app
Direct answer
Shipped untested, a pharmacy delivery app passes a controlled-substance refill past its refill limits or with no valid prescription without a pharmacist flag, and shows a blind patient a prescription confirmation whose dosage, quantity and refill date are an image, in the pharmacist review and order confirmation flows. 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 new patient's prescription upload, pharmacist approval, payment and courier delivery must each appear in the order history, which shows whether the prescription gate holds across the whole flow.
8 mandatory testsfirst: end-to-end functional tests
What counts as a pharmacy delivery app
A pharmacy delivery app here means an iOS, Android or web product for ordering prescription and over-the-counter medicines with delivery to the door. It counts when the app takes prescriptions, prices orders through insurance or cash, and takes card payments. An app where clinicians write the prescription in a visit is out of scope, and so is a delivery app that sells no prescription medicines.
Adjacent product types not covered here
- telemedicine app: A telemedicine app writes prescriptions in a video visit, so its risks sit in refill assessments and visit load rather than refill limits and the prescription gate.
- patient portal: A patient portal moves records and messages from a provider, while a pharmacy app dispenses medicine against prescription and refill-limit rules.
- ecommerce store: An ecommerce store sells items any shopper can buy, with no prescription gate, controlled-substance limit or insurance claim in checkout.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Accessibility complaint or lawsuit accessibility-liability | legal | primary | A blind patient cannot hear the dosage, quantity or refill date on the prescription confirmation screen because the label text is an image. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | A controlled-substance refill passes checkout past the refill limits its prescription allows, or with no valid prescription behind it, and the pharmacist queue never flags it. | |
| Personal or sensitive data exposed data-breach | data | primary | A patient opens their order history and sees another patient's medication list, or a former pharmacy technician still reads prescription records after offboarding, or medication pages send drug names to advertising platforms through tracking code. | |
| App rejected or removed by a store store-rejection | distribution | primary | A reviewer adds a prescription-only medicine to the cart and checks out without uploading or transferring a prescription, and the store pulls the app. |
Mandatory tests (8)
Step 1: release smoke tests
Why:store-rejection
Done when: On the release build, a prescription-only item cannot reach payment until a prescription is uploaded or transferred, and an over-the-counter item checks out without one.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 2: end-to-end functional tests
Why:regulatory-penaltystore-rejection
Done when: A new patient uploads a prescription, the pharmacist approves it, the patient pays and the courier marks it delivered, and each step appears in the order history.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 3: compliance checks
Why:regulatory-penaltydata-breach
Done when: A pharmacist-in-charge signs a checklist showing where the app enforces the prescription requirement, controlled-substance refill limits and patient consent for data sharing.
Tool class: test management. Who usually runs it: product manager.
Step 4: analytics and event tracking tests
Why:regulatory-penaltydata-breach
Done when: A network capture of browsing, adding and ordering a medication shows no drug name, condition or prescription detail sent to any advertising or analytics endpoint.
Tool class: proxy. Who usually runs it: security specialist.
Step 5: accessibility testing
Done when: A screen reader user hears the medicine name, strength, quantity, price and refill date on the cart and confirmation screens and completes an order.
Tool class: accessibility checker. Who usually runs it: accessibility specialist.
Step 6: data integrity and migration testing
Done when: A test controlled-substance refill past its prescription's refill limit, and one with no valid prescription on file, both stop in the pharmacist queue with a visible reason.
Tool class: data validation. Who usually runs it: QA engineer.
Step 7: security scanning
Why:data-breach
Done when: The scan report for the pharmacy app, ordering site and their API shows no open high-severity finding, and a disabled staff account cannot open any prescription record.
Tool class: DAST scanner. Who usually runs it: security specialist.
Step 8: penetration testing
Why:data-breach
Done when: A tester signed in as patient A cannot read patient B's prescriptions, insurance card or delivery address by changing an order or patient id.
Tool class: proxy. Who usually runs it: security specialist.
Recommended and optional tests
regression suiterecommended
Becomes mandatory when the prescription rules change more than once between releases.
exploratory testingrecommended
Becomes mandatory when reorder or one-tap refill ships.
device and browser compatibilityrecommended
Becomes mandatory when store reviewers or support report a device-specific upload failure.
integration testsrecommended
Becomes mandatory when the risk "Third-party dependency fails" or "Money leaves or fails to arrive" is attached to this product type with verified evidence (see the methodology).
contract testsrecommended
Becomes mandatory when a second claims or courier provider is added.
resilience and failure testingrecommended
Becomes mandatory when the risk "Third-party dependency fails" is attached to this product type with verified evidence (see the methodology).
payment and money-flow testingrecommended
Becomes mandatory when the risk "Money leaves or fails to arrive" is attached to this product type with verified evidence (see the methodology).
unit testsoptional
May help: checks days-supply arithmetic and refill-date calculation without a deployed build.
Not needed and why
Not needed for release: no evidenced risk depends on it. Becomes recommended when support logs show patients abandoning prescription upload.
Not needed: orders arrive at prescription pace with no drop or flash-sale peak. Becomes recommended when the app runs a public campaign or adds same-hour delivery in a large city.
Not needed: one language and one country's prescription rules. Becomes recommended when a second language or country ships.
Order of work
First release
- release smoke tests: On the release build, try to pay for a prescription-only item without a prescription and confirm checkout stops, then check out an over-the-counter item.
- end-to-end functional tests: Take a new patient from prescription upload through pharmacist approval, payment and courier delivery, and check each step in the order history.
- compliance checks: Have the pharmacist-in-charge sign a checklist of where the app enforces the prescription requirement, controlled-substance refill limits and data-sharing consent.
- analytics and event tracking tests: Capture network traffic while browsing, adding and ordering a medication and look for any drug name, condition or prescription detail sent to an advertising or analytics endpoint.
- accessibility testing: Have a screen reader user complete an order and hear the medicine name, strength, quantity, price and refill date on the cart and confirmation screens.
- data integrity and migration testing: Submit a controlled-substance refill past its prescription's refill limit and one with no valid prescription on file, and confirm both stop in the pharmacist queue with a visible reason.
- security scanning: Scan the pharmacy app, ordering site and their API, clear every open high-severity finding, and confirm a disabled staff account cannot open any prescription record.
- penetration testing: Sign in as patient A and try to read patient B's prescriptions, insurance card or delivery address by changing an order or patient id.
Ongoing cadence
- release smoke tests: Before each store submission.
- data integrity and migration testing: After each change to controlled-substance refill limits or the prescription check.
- analytics and event tracking tests: When any analytics, ad or attribution code is added or updated.
- compliance checks: When prescription or controlled-substance rules change in a state the app serves.
- accessibility testing: After each change to the cart, prescription confirmation or label text screens.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of pharmacy delivery 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
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
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
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
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
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
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for pharmacy delivery app has the same 8 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the pharmacy delivery app is accepted when a prescription-only item cannot reach payment without a prescription, and a controlled-substance refill past its limits or without a valid prescription stops in the pharmacist queue with a visible reason. A screen reader user hears the medicine name, strength, quantity, price and refill date on the cart and confirmation screens, and no drug name or prescription detail reaches an advertising or analytics endpoint.
Brief
# Test brief: pharmacy delivery app Product type: pharmacy delivery app. Prescription and OTC ordering with delivery. Risk map and evidence: https://howtotestaproduct.com/how-to-test/pharmacy-delivery/ Printable checklist: https://howtotestaproduct.com/checklists/pharmacy-delivery/ 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, a prescription-only item cannot reach payment until a prescription is uploaded or transferred, and an over-the-counter item checks out without one. 2. end-to-end functional tests (risks: regulatory-penalty, store-rejection). Tool class: browser automation. Usually run by: QA engineer. Done when: A new patient uploads a prescription, the pharmacist approves it, the patient pays and the courier marks it delivered, and each step appears in the order history. 3. compliance checks (risks: regulatory-penalty, data-breach). Tool class: test management. Usually run by: product manager. Done when: A pharmacist-in-charge signs a checklist showing where the app enforces the prescription requirement, controlled-substance refill limits and patient consent for data sharing. 4. analytics and event tracking tests (risks: regulatory-penalty, data-breach). Tool class: proxy. Usually run by: security specialist. Done when: A network capture of browsing, adding and ordering a medication shows no drug name, condition or prescription detail sent to any advertising or analytics endpoint. 5. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist. Done when: A screen reader user hears the medicine name, strength, quantity, price and refill date on the cart and confirmation screens and completes an order. 6. data integrity and migration testing (risks: regulatory-penalty). Tool class: data validation. Usually run by: QA engineer. Done when: A test controlled-substance refill past its prescription's refill limit, and one with no valid prescription on file, both stop in the pharmacist queue with a visible reason. 7. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist. Done when: The scan report for the pharmacy app, ordering site and their API shows no open high-severity finding, and a disabled staff account cannot open any prescription record. 8. penetration testing (risks: data-breach). Tool class: proxy. Usually run by: security specialist. Done when: A tester signed in as patient A cannot read patient B's prescriptions, insurance card or delivery address by changing an order or patient id. Acceptance criteria wording: A release of the pharmacy delivery app is accepted when a prescription-only item cannot reach payment without a prescription, and a controlled-substance refill past its limits or without a valid prescription stops in the pharmacist queue with a visible reason. A screen reader user hears the medicine name, strength, quantity, price and refill date on the cart and confirmation screens, and no drug name or prescription detail reaches an advertising or analytics endpoint. 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 pharmacy delivery app
What testing does a pharmacy delivery app need?
8 mandatory tests cover the 4 risks in the map: controlled-substance refills past their refill limits or without a valid prescription, one patient seeing another's medications or drug names reaching ad platforms, store removal over the prescription gate, and confirmation screens a blind patient cannot hear. They run as release smoke, data integrity, end-to-end, compliance, analytics tracking, accessibility, security scanning and penetration tests. Claims pricing integration and payment sandbox tests are recommended until their conditions apply.
What gets a pharmacy delivery app rejected by an app store?
The risk map records removal when a reviewer adds a prescription-only medicine to the cart and checks out without uploading or transferring a prescription. The release smoke test covers it: on the release build, a prescription-only item cannot reach payment until a prescription is uploaded or transferred.
Does a pharmacy delivery app need PCI DSS testing?
The risk map does not cite PCI DSS for this product type, and no mandatory test on this page targets payment card data. Card charges are covered by the recommended payment sandbox test, which becomes mandatory when a money-loss risk is attached with verified evidence.
Which tests in a vendor test plan for a pharmacy delivery app are not needed?
Usability, performance and localization tests are marked not needed: no evidenced risk depends on usability, orders arrive at prescription pace with no flash-sale peak, and the app runs in one language under one country's prescription rules. Performance becomes recommended when the app runs a public campaign or adds same-hour delivery in a large city.
How is the audit trail tested in a pharmacy delivery app?
The end-to-end test checks that prescription upload, pharmacist approval, payment and courier delivery each appear in the order history. The compliance check ends with a checklist signed by the pharmacist-in-charge showing where each prescription rule is enforced.
Evidence
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-0017regulatorprimary
Guidance on Web Accessibility and the ADA, U.S. Department of Justice
The Department of Justice states that the ADA applies to the websites of businesses open to the public and of state and local governments.
published undated · verified 2026-10-07
ev-0140regulatorprimary
21 U.S. Code 829: Prescriptions, Legal Information Institute, Cornell Law School (U.S. Code text)
No controlled substance that is a prescription drug as determined under the Federal Food, Drug, and Cosmetic Act may be delivered, distributed, or dispensed by means of the Internet without a valid prescription.
The Ryan Haight provision in subsection (e) makes internet delivery of a controlled substance without a valid prescription unlawful, which applies directly to any app that takes and delivers prescription orders. Subsection (b) also bars filling or refilling schedule III and IV prescriptions past the time and refill limits it sets unless the practitioner renews them.
published undated · verified 2026-10-07
ev-0141regulatorprimary
FTC Enforcement Action to Bar GoodRx from Sharing Consumers' Sensitive Health Info for Advertising, U.S. Federal Trade Commission
GoodRx violated the Health Breach Notification Rule by failing to notify consumers, the FTC, and the media about the company's unauthorized disclosure of individually identifiable health information to Facebook, Google, Criteo, Branch, and Twilio.
A prescription drug service sent users' medication data to advertising platforms through tracking tools; a pharmacy delivery app that fires ad or analytics events on medication pages carries the same enforcement risk.
published 2023-02-01 · 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-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-0143store-guidelineprimary
Health Content and Services, Google Play
We do not allow apps that facilitate the sale or purchase of prescription drugs without a prescription.
Google Play removes apps that let a user buy a prescription drug without a prescription, so the prescription gate in a pharmacy delivery app is a distribution requirement as well as a legal one.
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.