EV Charging Software Acceptance Testing Checklist

1. Define the test scope before connecting chargers

Start with the business process rather than the feature list. A public charging site needs a different acceptance plan from a private depot. Write down who can charge, how they identify themselves, who pays, which tariff applies and who responds when something fails. Make each requirement observable.

Create an equipment matrix containing manufacturer, model, firmware, connector identifiers, communication method and supported protocol version. Two chargers from the same brand can behave differently after a firmware change. Treat a materially different configuration as a separate test case instead of assuming that one successful session covers the entire network.

Assign an owner to every test. The operator should approve the business outcome, while the software provider, charger manufacturer, payment integrator and installer supply evidence for their respective parts. Record dependencies early so a missing merchant account does not look like a platform defect.

2. Verify charger integration beyond the online indicator

The first checks should cover identity and status. Confirm that the correct charger, site and connector appear in the platform. Compare the physical label with the dashboard and driver interface. A driver scanning connector two must not accidentally start connector one.

Test boot registration, status changes, meter reporting and transaction completion. Then test the commands included in your contract, such as remote start, remote stop and retrieving diagnostics. A command marked “accepted” is only one piece of evidence; verify that the intended physical outcome actually occurred.

The Open Charge Alliance explains that OCPP 1.6 and 2.0.1 are not compatible. A platform serving both needs appropriate implementations and charger-level validation. Ask which functions were tested on your exact equipment rather than accepting a broad compatibility statement.

For background on the integration scope, review TRENDPOWER’s published OCPP support guidance. Keep the agreed model and firmware matrix attached to the acceptance record.

3. Test access and the complete driver journey

Walk through the process as a new driver, not as an administrator who already knows where every button is. Find the site, identify the connector, read the price, authenticate, start charging and obtain the final record. Check the mobile experience on the devices and browsers your audience actually uses.

Include valid and invalid credentials, expired access, a connector already in use and repeated start requests. Verify that unauthorized drivers receive a useful explanation without exposing account information. Where RFID, a web interface or a branded app is included, test each route separately.

For shared sites, test permissions from both sides. Confirm that an approved visitor can charge and that an expired visitor cannot. Then confirm that changing access does not retroactively alter the historical record of an earlier session.

4. Recalculate billing and payment results independently

Choose a small group of sessions with known inputs. Use a simple energy-only tariff first, then test any agreed connection fee, time component, discount or idle fee. Calculate the expected charge separately and compare it with the platform, receipt and payment provider record.

Include boundary conditions: a tariff changing at midnight, a session spanning two pricing periods, a zero-energy session and rounding at the smallest supported currency unit. Record the applicable timezone and the policy for sessions already in progress when a tariff changes.

Payment tests should include authorization success, authorization failure, a failed charging start and a delayed provider notification. Check that repeated callbacks do not produce repeated charges. For a wider view of the commercial setup, use the EV charging payment solution overview alongside your provider’s own integration requirements.

5. Validate load controls under realistic conditions

If load management is in scope, test it with the site engineer and agreed instrumentation. Define the control boundary clearly: a charger group, a feeder or the whole building. A dashboard total based only on charger data cannot prove that the entire building remains within its limit.

Use a controlled test to add charging demand and change any relevant building load. Compare the requested limit, the charger’s response and the measured result. Allow for the documented response interval and measurement tolerance; do not invent a universal threshold that the equipment cannot meet.

Test the agreed fallback when the site meter, local controller or cloud connection becomes unavailable. Record who receives the alert and how operations resume. Software scheduling supports the engineered control strategy; it does not replace electrical protection or an approved site design.

6. Run failure and recovery scenarios

A production network needs predictable behavior when components disappear. Interrupt the charger’s internet connection, restart the application where permitted, and simulate a missed notification in a controlled environment. Check the driver view, operator alert and eventual reconciliation.

Offline behavior depends on charger capabilities and configuration. Do not assume that a session can start offline simply because an existing session continued. Separate those cases and state exactly which access methods and local controls are expected to work.

After reconnection, inspect the timeline for gaps, duplicates and incorrect timestamps. Read the existing offline EV charging guide when defining these cases. Include recovery evidence in the handover, not just a screenshot of the charger returning online.

7. Check permissions, exports and operational handover

Log in as a site host, support agent, finance user and administrator. Test both allowed and blocked actions, including tariff changes, refunds, exports and remote commands where those functions exist. A role should have enough access to do its job without becoming a shortcut to every site’s data.

Export the test sessions and compare totals with the dashboard. Check connector identity, timestamps, energy units, currency, tax fields where applicable and financial status. Ask how corrections appear and whether an audit trail identifies the person or system responsible.

Finally, let the people who will operate the network perform the routine tasks. They should know how to investigate a failed start, contact the right supplier, find a payment reference and explain a pending payment to a driver. A technically complete platform can still fail its handover if those steps remain unclear.

8. Agree on release criteria and staged rollout

Use written release criteria agreed before testing. For example, your project might require every critical workflow to pass, all blocking defects to close and any accepted minor issue to have an owner and target date. These are project decisions, not an industry-wide certification scheme.

Start with a small pilot that represents the wider network. Include the charger types, access methods and payment journeys that carry the most operational risk. Expand only after reviewing live records and confirming that support teams can handle the issues observed.

The acceptance pack should contain the equipment matrix, test cases, results, defect log, configuration baseline, operating contacts and rollback procedure. This becomes a useful reference when a later firmware update or tariff change introduces unexpected behavior.

Frequently asked questions

Is an OCPP connection test enough for acceptance?

No. It confirms only part of the system. You still need to verify the agreed driver journeys, tariffs, payment outcomes, permissions, reports and recovery procedures on the actual project configuration.

Should every charger receive the same testing?

Every installed unit needs the agreed commissioning checks. The depth of repeated software testing can follow a risk-based sampling plan, but distinct models, firmware versions and unusual site configurations need explicit coverage.

Who signs off the software?

The operator should nominate an accountable approver. Suppliers provide evidence for their own scope, while electrical and safety acceptance remain with the appropriately qualified parties. Make those responsibilities part of the project agreement.