Optimo
Optimo is the all-in-one service-automation testing framework ELO built for Hyundai HATA in California, still used there to test the online architecture behind their connected-cars ecosystem. One platform covers three surfaces that normally need three separate test stacks — IoT devices, the web portal, and the mobile app — including human-to-device voice conversations against Alexa and Google Home. Fauzul was active in the early scope definition, wrote test cases, designed the test workflows, defined the APIs, and managed the development team delivering it.
Why a connected car is hard to test
A single connected-car journey — "Alexa, ask Blue Link to remote start my car" — crosses a voice assistant, an IoT platform, several service back-ends, and the telematics unit in the vehicle itself, then comes back the same way. Any hop can be the one that breaks, and none of them can be verified from a browser.
Hyundai needed that whole chain regression-tested continuously, across distributors and environments, by a QA organisation where not everyone writes code. Optimo was built to be that instrument: a single framework where a test author configures a run — functional or performance, API / voice / speech, Google or Amazon device, staging / production / QA, per distributor — and the platform generates and drives the underlying scripts.
What Optimo does
- Human–IoT conversation simulation. Alexa and Google Home dialogues driven as test steps, so the voice services offered to customers are exercised the way a customer actually reaches them.
- Excel-driven test authoring. A customised pseudo-syntax lets QA write test scripts in a spreadsheet; Optimo generates JMeter, Appium, and Selenium scripts on the fly from it.
- Step-timed run traces. Every request/response hop between the IoT platform, the service back-ends, and the vehicle telematics unit is recorded in order with its own latency, so a failure is attributed to a hop rather than to "the system".
- Machine monitoring and load balancing. A distributed-system management tool tracks the test machines and spreads load across them.
- Scheduled runs and reporting. Automated scheduled testing with step-by-step report generation and PDF emailing to the stakeholders who never open the tool.
Where I sat
- Early scope definition. Shaped what the framework had to cover before it was built — which surfaces, which environments, which distributor permutations.
- Test cases and workflows. Wrote test cases and designed the test workflows the spreadsheet syntax had to express.
- API definitions. Defined the API contracts between the framework, the IoT platform, and the service back-ends under test.
- Development team management. Ran the engineering team delivering the platform against a client QA organisation as the counterpart.
High-calibre architecture decisions.
Technical Highlights
- Spreadsheet pseudo-syntax compiled to JMeter, Appium, and Selenium scripts at run time.
- Voice-assistant conversation simulation (Alexa / Google Home) as first-class test steps.
- Per-hop request/response tracing across the IoT platform, service back-ends, and vehicle telematics unit.
- Run configuration matrix across reporting type, automation type, device, environment, and distributor.
- Machine-monitoring and load-balancer tooling for distributed test execution.
- Scheduled runs with step-by-step reports and automated PDF distribution.
Key Decisions & Rationale
The people who know the connected-car service behaviour are not all script authors. Making Excel the input and generating JMeter/Appium/Selenium underneath kept authorship with the domain experts instead of bottlenecking on an automation team.
The failure modes worth catching live in the seams between surfaces. Three separate tool stacks would have tested three halves of the journey and none of the joins.
Connected-car regressions usually present as "sometimes slow", not "broken". Recording each hop with its own latency turns that into an attributable number a team can act on.
By the numbers.
Optimo — Test Authoring & Run Traces
Two surfaces from the framework: the run-configuration wizard where a test is defined across reporting type, automation type, device, environment and distributor, and the run trace where every request/response hop of a connected-car journey is timed in order.
Test Cases — IoT run configuration: functional/performance reporting, API/voice/speech automation, Google or Amazon device, staging/production/QA, per distributor.
If we worked together.
I bring high-leverage product engineering and absolute operational discipline: shipping weekly, pressure-testing user inputs, and automating delivery pipelines.
Singistic
Cross-platform video & karaoke social platform serving 10,000+ active users, engineered using Flutter. Features AI-powered vocal/instrument separation pipelines to generate karaoke tracks from licensed masters, sub-50ms native audio-video playback sync, AirPlay/Chromecast integration, and automated serverless/EC2 media transcoding queues for processing user recordings cost-effectively at scale.