I make releases boring. I'm learning to decide what gets built.
Senior Automation Engineer at ZS Associates, five years into building test automation that teams actually trust. I own frameworks end to end — Java and Selenium at the bottom, CI pipelines at the top, and no flaky tests in between.
I've spent five years as the person who asks "but what happens if the user does this?" — and I've started treating that instinct as a career, not a habit. Senior SDET at ZS by day, deliberately building product muscle on the side.
📍 Delhi, India · UTC+5:30
A decorative terminal animation lists what I optimise for: trustworthy CI pipelines, fast regression feedback, zero tolerance for flaky tests, and asking why before how.
About
I'm Raghav Khullar, a Senior Automation Engineer at ZS Associates, where I've spent the last five years turning release nights from an event into a non-event. I design the frameworks, wire them into CI/CD, and own the signal — so when the pipeline goes green, people believe it.
My default questions are about failure modes: what breaks under load, what breaks on the third retry, what breaks only for the customer in a different timezone. That's the job. Anyone can automate a happy path; the value is in the tests that catch the thing nobody thought of.
Before QA I built full-stack apps and trained ML models — which is why I treat test code as production code: clean abstractions, real reviews, and pipelines that fail loudly and early.
I'm Raghav Khullar. Five years as an SDET at ZS Associates gave me an unusual entry point into product thinking: I read every requirement twice, because my job was to find where it was wrong.
An SDET sits in a strange, useful seat. You translate ambiguous requirements into precise, testable statements. You argue with engineers about edge cases and with stakeholders about what "done" means. You're the last person between a decision and a customer. That's most of discovery and spec work, just wearing a different job title.
What I'm adding deliberately: the commercial half. Reading the metrics rather than the logs, sizing a bet before building it, and being able to say "we shouldn't build this" with evidence. I'm doing it the way I learn best — by shipping things end to end and writing down what I got wrong.
Experience
Progression from writing tests to owning how a team ships. Every step here was really about reducing the risk of a decision.
ZS Associates · Delhi, India
ZS Associates · Delhi, India
Independent · pre-ZS
Deliberate practice · alongside the day job
Skills
A toolkit built around reliable automation — plus the dev and data foundations behind it. Technical depth first, product craft second — the combination is the point.
Work
A mix of automation, tooling and data work — all open-sourced on GitHub. Same projects, told as decisions: what problem, what bet, what I'd do differently.
End-to-end UI test automation for Amazon.com built with Selenium, TestNG and a clean Page Object Model — data-driven and maintainable.
Problem E-commerce flows are long, stateful and break silently.
Bet Model pages as objects so a UI change costs one edit, not fifty.
Learned Maintainability is the actual feature. Coverage nobody maintains is coverage nobody trusts.
A lightweight cross-platform screen recorder built with Electron and vanilla JavaScript — small footprint, no bloat.
Problem Screen recorders are either bloated or paywalled behind a signup.
Bet Strip it to one job — press record, get a file — and ship a real binary.
Learned Scoping down is a product decision, not a shortcut. Every feature I cut made it likelier to actually ship.
A machine-learning intrusion-detection system that classifies malicious network traffic with over 90% accuracy.
Problem Rule-based intrusion detection misses anything it hasn't seen before.
Bet Learn the shape of normal traffic instead of enumerating attacks.
Learned Accuracy was the wrong headline metric — for a security tool, the cost of a false negative and a false positive are nothing alike.
Data-visualization study analysing the pandemic's economic footprint across sectors, told through clear, interactive charts.
Problem Sector-level pandemic data existed, but nothing made it comparable.
Bet Normalise across sectors and let the chart carry the argument.
Learned How to pick the one number that changes a reader's mind — and how easily a chart can overstate a story.
A Splitwise-inspired expense-sharing app that keeps group balances tidy and settles who-owes-whom in a tap.
Problem Splitting group expenses is easy; remembering who settled up isn't.
Bet Make the balance the home screen, not a report you go find.
Learned The hard part was social, not technical — nudging someone to pay is a design problem.
Frameworks, experiments and open-source contributions — from automation utilities to data notebooks.
Product track
Being upfront: I haven't held the PM title yet. Here's the case for why I'm closer than the job title suggests — and exactly what I'm doing to close the gap.
Short, structured breakdowns: what the product is optimising for, what it's trading away, and what I'd change with evidence.
DraftingOne real user problem, owned end to end — discovery, scope, build, launch, and an honest write-up of the metrics.
In progressStructured study of discovery, prioritisation and experiment design — with notes published rather than filed away.
OngoingWorking on something where a technically deep, quality-obsessed PM would help? That's the conversation I want.
Contact
Happy to talk automation architecture, killing flaky tests, or what a quality bar should actually gate. Drop a line, connect on LinkedIn, or star a repo.
If you're a PM, hiring manager, or someone who made the engineering-to-product jump — I'd genuinely like to hear how you'd approach it from here. Coffee, call, or a long email.