Engineering-led quality
How I think about risk, automation, and collaboration—grounded in years building production software, now aimed squarely at QA and quality engineering roles.
I am a software engineer choosing quality engineering as my next chapter—not because I could not build product code, but because that background is exactly what makes me dangerous in QA.
I do not rebrand past titles: my résumé is engineering leadership and full-stack delivery. What I am offering hiring teams is that same rigour applied to gates, automation, and release confidence.
Why an engineer in a QA seat is leverage
I read the implementation
I trace failures through TypeScript and Python services, auth, queues, and data—not only through the browser. That shortens the loop from red build to root cause.
I design for testability before the suite exists
Selectors, seams, fixtures, and environment parity are architecture concerns. I have shipped enough production systems to negotiate those with developers without slowing them down arbitrarily.
I speak both languages
Clear repro steps and risk framing for product; precise logs, artifacts, and PR feedback for engineering. Remote teams move faster when quality is a partner, not a gatekeeper caricature.
Where I go deep
End-to-end automation
Playwright-first mindset: stable locators, parallelisation, traceability on failure, and suites split by risk (smoke vs regression) so CI stays trustworthy.
API and contract testing
REST and GraphQL flows, auth and idempotency, error semantics, and staging data—especially around money and integrations where the UI is only the last mile.
CI/CD as a product
GitHub Actions and pipeline design so the right tests run at the right time, with artifacts people actually open when something breaks.
Flake and noise as engineering work
Flaky tests get the same treatment as production incidents: reproduce, fix the root cause, add guardrails. I do not silence failures—I make them meaningful.
How I work with a team
- Risk-based coverage: critical paths and contracts first; breadth where it earns its keep.
- Definitions of done that include observable quality—not checkbox coverage for a dashboard.
- Documentation and handoffs that survive time zones: what ran, what failed, what I need next.
- Constructive review of developer tests: I extend and harden rather than duplicate blindly.
Proof you can inspect
This portfolio runs Playwright end-to-end checks (including contact form validation). The suite lives in the repository—automation I ship is real, not slide deck fiction.
What I am looking for
Full-time remote roles in QA automation, quality engineering, or SDET-style positions where depth in web, mobile, and API stacks matters. I want ownership of strategy and tooling—not only executing someone else’s scripts.