QA & test automation · software × hardware
I break things on purpose. Then I prove they're fixed.
I'm Rogelio, a test engineer who works where software meets hardware: embedded Linux boxes, TVs, audio gear, cloud services, and the code that ties them together. At BarBoards I was the first QA engineer, built the testing practice from zero, and ended up owning two features from end to end.
tone fired slot 21 corr=a1b2c3d4 playback_state state=ad confirmed ad after 0.1s PASS video/play ad_display video/finished within budget PASS returned to broadcast PASS tone mid-playback 0 new plays PASS
BarBoards · July 2026 to now
What I built and found
BarBoards puts interactive ads and games on TVs in bars and venues. Each screen runs on a small embedded Linux computer (a "box") wired to TVs, speakers, and a cloud backend. When something breaks, a guest sees it on a TV. That is the standard I test to.
Building QA from zero
The first QA engineer on the team. I wrote the templates, run logs, and release criteria that turned "it seems fine" into evidence.
Taking over Music Mode and Pods
Two features in development, one with no documentation. I reverse-engineered it, wrote the docs, moved into a developer role, and drove both to release.
The Music Mode test harness
A Python and pytest harness that fires real tones at a live box and follows each event through the whole playback chain.
Four more harnesses
An ad scheduler, a new hardware generation, a USB audio interface, and a live patron game. Each answers a plain question: is this safe to ship?
Finding the holes before a guest does
Unprotected game actions that let anyone with a room code change live game data, plus an operator who could wipe another venue's content.
Video freezes that looked like a software bug
Reproduced a field problem on demand, proved the real cause was memory eviction, and fixed it. Also tracked down a silent audio bug present on 13 of 14 branches.
Test report
The suites at a glance
Every harness runs against real hardware or a real backend, writes down what it expects, and reports what happened with logs attached.
| Suite | Cases | What it answers |
|---|---|---|
| Music Mode | ~90 | Does a tone in the music switch the TV to the right ad and back, every time, on a live box? |
| Ad scheduler | 154 | Does the box do what the schedule says, including when schedules conflict? |
| v3 box | 115 | Is this box fit to ship? |
| 3.1 audio interface | 75 | Does sound reach the right place at the right level, at every layer? |
| Stadium Squares (live game) | 160 | Does the game work end to end, hold 50 patrons, and survive 14 hours? |
Experience
Where I've worked
BarBoards
QA / Test Automation Engineer · Austin, TX
- First QA engineer: built the QA process from zero (validation scope, regression coverage, edge cases, success criteria, test plans, and run logs). My test plans became the source for the software documentation.
- Took over Music Mode and Pods while they were in development, moved into a developer role to ship them, reverse-engineered the undocumented code, and led demos.
- Built a Python and pytest harness for Music Mode on live Jetson hardware that runs on demand and in CI. It found 50+ bugs.
- Built harnesses for the ad scheduler, the v3 box, and a live patron game, and found 3 high and 2 medium security flaws in the game API.
- Traced video freezes to memory eviction and deployed the fix to live boxes. Found a missing audio setting in 93% of branches.
Meta via Wipro
Test Engineer
- Drove end-to-end validation of Meta's Ray-Ban AR glasses and the Neural EMG wristband, executing test plans across embedded systems, hardware, firmware, and mobile applications on development builds.
- Tested LLM and multimodal system behavior across hallucination detection, speech-to-intent accuracy, and action routing logic, including decisions for audio responses, app navigation, and device actions.
- Validated cross-device media and messaging experiences across Spotify and Meta apps (WhatsApp, Instagram, Messenger), covering Bluetooth connectivity, pairing stability, playback behavior, and message synchronization across app and device-side systems.
- Tested EMG-based wearable input systems by validating gesture recognition accuracy, biosignal interpretation, and haptic feedback response latency across real-time input-to-action workflows.
York Space Systems
Test Automation Engineer Intern
- Wrote Python test automation for satellite payload, telecommunications, and RF subsystems, running most validation in simulated environments. Worked with the Flight Software (FSW) and Ground Software (GSW) teams on system verification and validation (V&V), test cases, subsystem integration, and hardware-software interfaces.
- Built the initial stages of a Freeboard-based GUI that links simulated environments to automated test cases, letting engineers trigger tests and monitor telemetry, and easing the move from simulation to HIL and FlatSat integration.
Habits
How I work
Reproduce before reporting
A bug report that says "it froze once" is a rumor. I make the failure happen on demand, so a developer can watch it fail and then watch it pass.
Test the whole chain
A tone is not "tested" when the ad plays. It is tested when every hop from trigger to broadcast behaved: message bus, controller, player, audio, and back. I tag each event with a correlation ID and follow it.
Make failures say where they hurt
Every harness reports the failing step, the expected value, the actual value, and the logs. Nobody should need me in the room to read a result.
Write down what you proved
Test plans, run logs, runbooks, and findings pages. If a result only lives in my head, it did not happen.
About
Who's behind the tests
I'm based in Austin, Texas. I studied Computer Science in the Honors College at Texas State University (class of 2025), with coursework in AI, computer vision, computer architecture, and systems security.
Before BarBoards I wrote Python test automation for satellite subsystems at York Space Systems, mostly in simulation, with a view into hardware-in-the-loop and FlatSat integration.
The common thread is the gap between code and the physical world. That gap is where the interesting bugs live.
Contact
Let's talk about what you're shipping
If you have a product that has to work in the real world, I would like to hear about it.