The SDET Mindset: Quality as an Engineering Problem
Testing is not a phase at the end of development. It's an engineering discipline that should inform every decision from architecture to deployment.
Most engineers think of testing as something that happens after the code is written.
A test plan is created, a QA engineer runs through it, bugs are filed, developers fix them, and eventually the software ships. This model is slow, expensive, and produces fragile software.
The SDET mindset rejects this entirely.
Quality is an engineering problem
When I say quality is an engineering problem, I mean that reliability, correctness, and predictability should be designed into a system — not bolted on afterward.
This changes what an SDET actually does. Instead of asking “does this feature work?” at the end of a sprint, the question becomes:
- How do we design this feature so it’s testable from the start?
- What are the failure modes, and how do we detect them automatically?
- How do we make the feedback loop as short as possible?
The shift-left principle
Shift-left means moving testing earlier in the development cycle. Not just earlier in the sprint — earlier in the thinking.
When I join a product discussion, I’m not there to list test cases. I’m there to identify assumptions, edge cases, and undefined behaviors before a single line of code is written. A bug found in a requirements document costs almost nothing to fix. A bug found in production can cost everything.
Automation is not the goal
This is counterintuitive for an automation engineer to say, but: automation is not the goal. Confidence is the goal.
Automated tests are a tool for generating confidence — confidence that a change didn’t break something, that a deployment is safe, that the system behaves as expected under load. When you chase automation coverage numbers without thinking about what you’re trying to learn, you end up with a large test suite that nobody trusts.
The best test suites I’ve built are not the largest ones. They’re the ones where a green CI pipeline means something.
What this looks like in practice
In practice, the SDET mindset means:
- Treating test code like production code — reviewed, refactored, documented.
- Owning the CI/CD pipeline — not just writing tests, but making them fast and reliable enough that engineers actually run them.
- Measuring flakiness — a flaky test is worse than no test, because it trains engineers to ignore failures.
- Being the voice for observability — if something fails in production and we can’t diagnose it in minutes, that’s a testing problem.
Software quality is a team sport, but it needs engineers who think deeply about reliability. That’s what an SDET is for.