Two Different Jobs
The OCPP Compliance Testing Tool from the Open Charge Alliance serves a specific purpose: certifying that a product meets the OCPP specification before it goes to market. It's thorough, official, and designed to produce a compliance result that means something to procurement teams.
It is not designed for development workflows. That's not a criticism — it's just a different tool for a different job.
Understanding the difference saves a lot of frustration.
What OCTT Does Well
OCTT runs a comprehensive, standardized test suite against your implementation. The tests cover the required and optional features of the spec in a structured way. When you pass, you have documented evidence of compliance that carries weight with enterprise customers and utilities.
The process is also a useful forcing function. Having to formally certify your product means you can't ship with "good enough" protocol compliance. The bar is well-defined.
Where OCTT Doesn't Fit Development
The certification process is designed around a milestone model: you build a thing, you test the thing, you certify the thing. Development is iterative. You're testing after every meaningful change, not once at the end.
OCTT also requires coordination — scheduling test sessions, getting access to the tooling, submitting results. This overhead is acceptable for a certification milestone. It's intolerable as a daily development loop.
The Gap in the Middle
What developers actually need is something that:
- Runs immediately, with no scheduling overhead
- Gives fast feedback on specific message exchanges
- Works in CI environments
- Provides enough detail to debug failures quickly
This is the gap OCPP Tester is designed to fill. It doesn't replace OCTT — if you need OCA certification, you still need to go through that process. But it handles the 95% of your testing that happens before you're ready for formal certification.
A Typical Workflow
In practice, the workflow looks something like this:
- Development: Run OCPP Tester in your local environment. Test every message flow as you implement it. Use it in CI to catch regressions.
- Pre-certification: Run OCPP Tester with your full implementation to do a pre-flight check. Fix anything that fails.
- Certification: Submit to OCA OCTT. At this point, you should already know you pass the core flows.
- Post-certification: Continue using OCPP Tester for development on the next version. Certification is a snapshot; development is ongoing.
Practical Notes on OCTT Integration
If you're preparing for OCTT certification, a few things are worth knowing:
The test suite is organized by profile (Core, Remote Trigger, Smart Charging, etc.). Make sure you know which profiles you're claiming compliance with before you start the process.
OCTT tests edge cases that your normal test runs might not hit — error responses, unexpected state transitions, missing optional fields. Run your implementation against as many of these scenarios as possible in development.
Keep your test logs. When something fails in formal certification, having detailed logs from your development testing makes root cause analysis much faster.