QA Automation Engineer / SDET
I build reliable automation that turns test results into clear release decisions.
QA Automation Engineer / SDET in Los Angeles, combining full-stack debugging with risk-based UI, API, and CI coverage.
Start with a verified cross-browser system, then explore the quality experiments and products behind my engineering range.
Showing 5 projects
A Chrome and Firefox extension that connects Seerr with seven movie and TV platforms, adds rating overlays, watchlists, and bulk request flows.
A progressively enhanced portfolio with a command palette, on-demand GitHub pulse, accessible 3D toy, QA simulator, and flake-cost calculator.
A compact set of experiments around progressive web app behavior, resilience, and testability.
An actively developed Next.js trip-planning app with authenticated AI itineraries, maps, weather, and PostgreSQL-backed features.
A neon puppy platformer with double jump, dash, coyote time, jump buffering, particles, and mobile support.
I came to quality engineering through full-stack development—and that changes how I test.
I can follow a failure across the browser, service, data, and CI layers, then improve testability at the source instead of adding another brittle check around the edge.
What I use each part of the toolkit to accomplish—not a wall of keywords.
Exercise critical journeys with stable locators, reusable fixtures, and cross-browser evidence.
Validate contracts, negative paths, and test data explicitly so failures have one understandable cause.
Turn coverage into a release decision through risk mapping, flake ownership, and clear evidence.
Keep feedback fast with focused gates, parallel execution, and artifacts attached when a build turns red.
Use the product’s own stack to diagnose defects and make the system easier to test.
Three principles behind the automation I want teams to rely on.
Map the critical journeys, failure modes, and customer impact before choosing what to automate.
A red build should arrive with enough context—logs, traces, screenshots, and clean test data—to make the next action obvious.
Use full-stack context to improve testability at the source, not just add more checks around brittle behavior.
This site ships with an evidence trail instead of a vague “built with care” claim.
Last checked
A tiny interactive test-runner simulator. The pipeline is simulated; the tradeoffs are very real.
Balanced: broad browser signal with one retry and useful failure evidence.
Run the simulated release gate to generate a verdict and a copyable report.
This mirrors the decisions I make in real suites: what belongs in the release gate, what evidence a failure needs, and where speed is actually worth buying.
Talk qualityA UI test passes locally but fails in CI after navigation. The trace shows the target appears late. What is the best first fix?
Estimate how much flaky reruns eat from team throughput.
Let’s talk quality systems, automation, and calmer releases.