How to test an EV charging app
Direct answer
Shipped untested, an EV charging app keeps billing per kWh after a stop tap that never reached the charger, and shows the price per kWh only after the driver taps start at a public charger. 8 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with resilience and failure testing: a stop tap lost when the roaming network or charger link drops is where billing keeps running, so the cut-link case comes before any receipt or payment check.
8 mandatory testsfirst: resilience and failure testing
What counts as an EV charging app
An EV charging app here is an iOS and Android app that drivers use to find a station on a map, start and stop a session on a charger and pay for the energy delivered, either on the operator's own chargers or through a roaming partner. It covers live charger status, price display before start, pre-authorisation and billing per kWh or per minute. Firmware running inside the charger and the operator's back-office tools for site maintenance are out of scope.
Adjacent product types not covered here
- smart home or IoT app: An IoT companion app controls a device the user owns at home, so camera account takeover and vendor cloud outages lead instead of billing for energy on a shared public charger.
- fleet and logistics tracking: Fleet tracking reads positions from trackers in vehicles a company owns and can send them commands, so cross-tenant access and engine cut-off replace per kWh billing and roaming payment.
- ride-hailing app: A ride-hailing app matches riders with drivers it onboards, so GPS-spoofed trips and automatic driver deactivation replace mismatches between a charger's meter values and the receipt.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Money leaves or fails to arrive money-loss | money | secondary by design analysis | A session the charger ends early still bills the full pre-authorised amount, or a stop tap that never reaches the charger keeps billing per kWh. | |
| Accessibility complaint or lawsuit accessibility-liability | legal | primary | The in-app start and pay flow at a federally funded station cannot be completed with a screen reader, where payment must be accessible to people with disabilities. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | The price per kWh appears only after the driver taps start, a roaming driver has no way to pay at a public charger, or the operator does not publish its compliance with the rapid charger reliability requirement. | |
| Third-party dependency fails dependency-failure | outage | primary | The roaming partner's network or the charger's backend link drops, and the app cannot start, stop or bill a charger it still shows as available. | |
| App rejected or removed by a store store-rejection | distribution | secondary by design analysis | A reviewer without a car or charger cannot reach the start-session screen, so the build needs a demo station and a test account. | |
| Users or operators act on wrong numbers wrong-decisions | trust | primary | The map shows a charger as available while it reports out of order, and a driver low on range detours to a dead bay. |
Mandatory tests (8)
Step 1: release smoke tests
Done when: On the release build, using the demo station and test account given to store review, a test driver finds a station on the map, starts a session on a test charger, stops it and receives a receipt, and billing on the receipt stops at the stop tap.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 2: resilience and failure testing
Why:dependency-failuremoney-loss
Done when: With the roaming network or charger link cut mid-session, the app shows the session as interrupted, billing stops, and the receipt matches the energy delivered before the cut.
Tool class: chaos tool. Who usually runs it: developer.
Step 3: data integrity and migration testing
Why:money-loss
Done when: For a sample of sessions, the kWh on each receipt matches the charger's meter values and the amount charged matches the price shown at start.
Tool class: data validation. Who usually runs it: developer.
Step 4: payment and money-flow testing
Why:money-loss
Done when: A session stopped early, a session the charger aborts and a declined card each end with one charge matching the energy delivered and no held amount left on the test card.
Tool class: API client. Who usually runs it: QA engineer.
Step 5: end-to-end functional tests
Why:wrong-decisionsregulatory-penalty
Done when: The price per kWh shows before the driver taps start, and a charger the backend marks out of order shows as unavailable on the map.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 6: accessibility testing
Done when: A screen reader user finds a station, starts a session and pays in the app without sighted help.
Tool class: accessibility checker. Who usually runs it: accessibility specialist.
Step 7: compliance checks
Done when: A signed checklist for each market shows price display before start, accepted payment methods and the published reliability data, with a screenshot or link for each.
Tool class: test management. Who usually runs it: product manager.
Step 8: integration tests
Done when: Start, stop and meter messages between the backend and a test charger, and through a roaming partner, produce the same session record on both sides.
Tool class: API client. Who usually runs it: developer.
Recommended and optional tests
regression suiterecommended
Becomes mandatory when charger firmware and app release on separate schedules.
contract testsrecommended
Becomes mandatory when more than one roaming partner is connected.
device and browser compatibilityrecommended
Becomes mandatory when the app runs on in-car screens.
performance and load testingrecommended
Becomes mandatory when the network serves motorway sites with holiday peaks.
security scanningrecommended
Becomes mandatory when the app stores payment cards or account credentials itself.
penetration testingrecommended
Becomes mandatory when charger-impersonation or session-hijack evidence is recorded for this product type, or when the operator runs its own charger backend.
offline and poor-network testingrecommended
Becomes mandatory when chargers in the network sit where mobile coverage is missing.
exploratory testingoptional
May help: physical misuse at the charger produces states no script covers.
Not needed and why
Not needed: no evidence ties harm to first-use confusion here beyond the accessibility case. Becomes recommended when a new start flow ships.
Not needed while the app ships in one market, language and currency. Becomes recommended when the app serves a second country or currency.
analytics and event tracking tests
Not needed: reliability data comes from charger status, not app analytics. Becomes recommended when app events feed published reliability figures.
Order of work
First release
- release smoke tests: On the release build, sign in with the demo station and test account given to store review, find a station on the map, start a session on a test charger, stop it and check that the receipt stops billing at the stop tap.
- resilience and failure testing: Cut the roaming network and the charger link mid-session and confirm the app marks the session interrupted and bills only the energy delivered before the cut.
- data integrity and migration testing: Compare the kWh and amount on a sample of receipts with the charger's meter values and the price shown at start.
- payment and money-flow testing: Run a session stopped early, a session the charger aborts and a declined card through the payment sandbox and confirm no pre-authorised amount stays held.
- end-to-end functional tests: Check that the price per kWh appears before the start tap and that a charger the backend marks out of order shows as unavailable on the map.
- accessibility testing: Find a station, start a session and pay with a screen reader at a test station set up as federally funded.
- compliance checks: Complete and sign a checklist per market covering price display before start, accepted payment methods and published reliability data, with a screenshot or link for each line.
- integration tests: Send start, stop and meter messages between the backend and a test charger, directly and through a roaming partner, and compare the session record on both sides.
Ongoing cadence
- release smoke tests: On every release build before store submission.
- data integrity and migration testing: After each change to tariffs, pricing rules or meter value handling.
- payment and money-flow testing: When the payment provider changes its API version or pre-authorisation rules.
- integration tests: When a roaming partner or charger model is added, or a charger protocol version changes.
- compliance checks: When charging regulations change in a market the app serves, and before launch in a new market.
- regression suite: On every release once charger firmware and the app release on separate schedules.
- contract tests: Before each new roaming partner goes live.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of EV charging app (ios, android). 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
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
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
- 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
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- XCTestApple's framework for unit and UI tests. iosopen-source
accessibility testing
- Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JUnitTest framework for the JVM. apiandroidopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
regression suite
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
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
security scanning
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 EV charging app has the same 8 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the EV charging app is accepted when a test driver can find a station, start and stop a session on a test charger and receive a receipt whose kWh matches the charger's meter values and whose amount matches the price shown before the start tap. A session cut off from the roaming network or charger link stops billing and leaves no pre-authorised amount held on the test card. A charger reported out of order shows as unavailable on the map.
Brief
# Test brief: EV charging app Product type: EV charging app. Locate, start and pay for charging sessions. Risk map and evidence: https://howtotestaproduct.com/how-to-test/ev-charging-app/ Printable checklist: https://howtotestaproduct.com/checklists/ev-charging-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, money-loss). Tool class: mobile automation. Usually run by: QA engineer. Done when: On the release build, using the demo station and test account given to store review, a test driver finds a station on the map, starts a session on a test charger, stops it and receives a receipt, and billing on the receipt stops at the stop tap. 2. resilience and failure testing (risks: dependency-failure, money-loss). Tool class: chaos tool. Usually run by: developer. Done when: With the roaming network or charger link cut mid-session, the app shows the session as interrupted, billing stops, and the receipt matches the energy delivered before the cut. 3. data integrity and migration testing (risks: money-loss). Tool class: data validation. Usually run by: developer. Done when: For a sample of sessions, the kWh on each receipt matches the charger's meter values and the amount charged matches the price shown at start. 4. payment and money-flow testing (risks: money-loss). Tool class: API client. Usually run by: QA engineer. Done when: A session stopped early, a session the charger aborts and a declined card each end with one charge matching the energy delivered and no held amount left on the test card. 5. end-to-end functional tests (risks: wrong-decisions, regulatory-penalty). Tool class: mobile automation. Usually run by: QA engineer. Done when: The price per kWh shows before the driver taps start, and a charger the backend marks out of order shows as unavailable on the map. 6. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist. Done when: A screen reader user finds a station, starts a session and pays in the app without sighted help. 7. compliance checks (risks: regulatory-penalty). Tool class: test management. Usually run by: product manager. Done when: A signed checklist for each market shows price display before start, accepted payment methods and the published reliability data, with a screenshot or link for each. 8. integration tests (risks: dependency-failure). Tool class: API client. Usually run by: developer. Done when: Start, stop and meter messages between the backend and a test charger, and through a roaming partner, produce the same session record on both sides. Acceptance criteria wording: A release of the EV charging app is accepted when a test driver can find a station, start and stop a session on a test charger and receive a receipt whose kWh matches the charger's meter values and whose amount matches the price shown before the start tap. A session cut off from the roaming network or charger link stops billing and leaves no pre-authorised amount held on the test card. A charger reported out of order shows as unavailable on the map. 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 an EV charging app
What testing does an EV charging app need?
8 tests are mandatory, each tied to one of the 6 risks in the map, such as billing that continues after a lost stop tap or a map that shows a broken charger as available. They start with a release smoke check and a resilience test that cuts the roaming network and charger link mid-session. Regression, contract, compatibility, performance, security scanning, penetration and offline tests are recommended, each with the event that makes it mandatory.
What is the minimum testing for an EV charging app at MVP stage?
The minimum is the 8 mandatory tests, because their conditions apply from the first paid session: drivers are billed per kWh or per minute, sessions run through chargers or roaming partners the app does not run, and live status and prices are shown. Exploratory testing of physical misuse at the charger is optional. Usability, localization and analytics tests are not needed until the conditions on the page change.
What gets an EV charging app rejected by an app store?
The map marks store rejection as a by design analysis risk: a reviewer without a car or charger cannot reach the start-session screen. The build needs a demo station and a test account, and the release smoke check on every build confirms that a test driver using that demo station and test account can start, stop and get a receipt. Compatibility testing becomes mandatory when the app runs on in-car screens.
Which tests in a vendor test plan for an EV charging app are not needed?
Usability testing is not needed because no evidence ties harm to first-use confusion here beyond the accessibility case, and it becomes recommended when a new start flow ships. Localization is not needed while the app ships in one market, language and currency. Analytics tests are not needed because reliability data comes from charger status, not app events.
When is test automation worth it for an EV charging app?
The release smoke check runs on every build that goes to the stores. The regression suite of early-stop, aborted-session and declined-card payment cases becomes mandatory when charger firmware and the app release on separate schedules. Contract tests become mandatory when more than one roaming partner is connected.
Evidence
ev-0235regulatorprimary
23 CFR Part 680: National Electric Vehicle Infrastructure Standards and Requirements, U.S. Federal Highway Administration (eCFR)
The price for charging must be displayed prior to initiating a charging transaction and be based on the price for electricity to charge in $/kWh.
The US rule for federally funded chargers requires price shown before a session starts, payment methods accessible to people with disabilities, OCPP between charger and network, network-to-network roaming and real-time port status for third-party apps.
published undated · verified 2026-10-07
ev-0236regulatorprimary
The Public Charge Point Regulations 2023, UK Government (legislation.gov.uk)
The UK regulations for public charge points set contactless payment, payment roaming, reliability, a helpline, open charge point data and price transparency, with an enforcement schedule, so the driver app and its data feed fall in scope.
published undated · verified 2026-10-07
ev-0238regulatorprimary
The Public Charge Point Regulations 2023, regulation 7: Reliability of rapid charge points, UK Government (legislation.gov.uk)
The charge point operator must publish information on its compliance with the reliability requirement on its website.
Reliability is measured from each charger's reported status (inoperative or out of order), so the status shown and published by the operator is a regulated figure, not a convenience.
published undated · verified 2026-10-07
ev-0237regulatorprimary
The Public Charge Point Regulations 2023, regulation 6: Payment roaming, UK Government (legislation.gov.uk)
Operators must let drivers pay through a third-party roaming provider, so a charging app depends on another company's network to start and bill sessions.
published undated · 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.