The SDET Title Gap: Hired for Automation, Assigned Manual Testing — How to Navigate It
Companies hire SDETs expecting automation but assign them only manual testing. Then the same companies ask advanced Java/OOP/framework questions in interviews. The contradiction is systemic — and here is how to navigate it.
Contents
The Problem
You aced a 4-round technical interview: framework design, API testing, CI/CD pipelines, coding challenges. You got the SDET title. Day 1: your manager asks you to execute manual test cases in a spreadsheet. Month 3: you have not written a single line of automation code.
Why This Happens
- No automation infrastructure: the team has no framework, no CI/CD, no test environments — and no budget to build them
- Title inflation: the company uses “SDET” to attract candidates but the actual work is QA Analyst
- Unclear ownership: nobody decided who builds the automation — dev team thinks QA will, QA thinks dev will
- Legacy mindset: leadership sees testing as a verification phase, not an engineering discipline
Strategy 1: Build Automation Capacity Quietly
Automate one test per week alongside your manual work. After 3 months, you have 12 automated tests and proof that automation saves time. Present the data to your manager.
Strategy 2: Propose a Pilot Project
Pick the most repeated manual test (login flow, smoke test, critical path). Automate it. Measure the time saved. Use this as the business case for a dedicated automation sprint.
Strategy 3: Negotiate Your Role
Have a direct conversation: “I was hired as an SDET. I want to allocate 50% of my time to building automation infrastructure. Here is my proposal for the first 3 months.” Document the agreement.
Strategy 4: Plan Your Exit
If after 6 months the role has not changed, start interviewing. Use your personal projects and side automation work as portfolio evidence. The next company will value what the current one ignores.
The 7 Skills That Actually Make a Great QA
Whether your title is QA or SDET, these skills define your real value:
- STLC understanding and test design techniques
- Failure-scenario thinking (what could go wrong?)
- High-quality bug reports with business impact
- Communication with developers, PMs, and stakeholders
- Practical tooling (Jira, Git, Postman, CI basics)
- Risk-based test prioritization
- Continuous learning mindset
