From Manual Tester to SDET: Building a QA Career

The jump from "tester who executes test cases" to "SDET who builds the tools other testers use" doesn't happen by accident, and it doesn't happen by collecting a list of tool names on a resume either. It happens through a fairly predictable skill ladder, one real project done properly, and the ability to talk about specific decisions rather than generic theory in an interview.

This closing article pulls together the career path, a practical skill roadmap, what actually makes a portfolio convincing to an interviewer, and how to prepare for the three distinct layers of questions QA interviews tend to test.

Career paths in QA

The common progression starts with Manual/Functional QA executing test cases, writing bug reports, learning STLC and test design in a real environment. From there, QA Analyst or Senior QA roles add ownership of test strategy, mentoring, and deeper domain expertise in the product. SDET (Software Development Engineer in Test) is a distinct branch, not strictly a promotion; it shifts toward building automation frameworks, writing testing tools, and contributing to CI/CD quality gates, requiring a genuinely closer-to-development skillset.

From SDET, paths branch further into Automation Architect or QA Lead roles, or into specialization performance engineering, security testing, or platform/tooling roles. None of these are strictly linear or mandatory; the useful thing to understand is that SDET specifically requires programming and system-design ability that pure manual QA doesn't, which is why it's worth deliberately building toward rather than assuming it happens automatically with tenure.

A practical skill roadmap

Stage one, foundations: manual testing fundamentals, STLC, test design techniques, effective bug reporting, basic SQL for verifying data directly rather than trusting the UI, and enough command-line comfort to navigate logs and files without friction. Stage two, automation: pick one language (Java, Python, or JavaScript), learn a UI automation tool (Selenium or Playwright), a test runner (TestNG, JUnit, or pytest), and Git well enough to work confidently in a team repository.

Stage three, API and CI/CD: Postman or REST Assured for API testing, and enough Jenkins or GitHub Actions familiarity to understand how a pipeline triggers and reports on automated tests. Stage four, broader engineering practice: basic performance testing concepts, basic security testing awareness, and enough Docker familiarity to understand how modern teams package and run environments none of this needs to be expert-level, but knowing the shape of it changes what conversations you can participate in.

Building a portfolio that actually gets interviews

A public GitHub repository with one real automation project, not a copied tutorial showing a clean Page Object Model structure and a README that explains why decisions were made, not just how to run the tests. Documented test case sets for a real or realistic sample application, showing actual test design thinking rather than a generic checklist. A personal site or blog writing up what was learned along the way genuinely, this kind of article is exactly that kind of proof. And certifications like ISTQB Foundation are a reasonable credibility signal, but they support a portfolio; they don't replace one.

How to actually prepare for interviews

QA interviews tend to test three distinct layers, and most candidates over-prepare for one and under-prepare for the other two. Layer one is concept and theory STLC, test design techniques, the defect life cycle, the kind of material covered across this whole series. Layer two is practical, scenario-based thinking "how would you test this login page" which is really testing whether you can structure an answer on the spot, not whether you memorized a checklist. Layer three, mainly for SDET-track roles, is hands-on technical work writing or debugging a small piece of automation code, or writing a SQL query to verify test data.

Practice explaining past bugs and projects in a tight, structured way: what you were testing, what you found, why it mattered, and what happened as a result. That structure, situation, action, impact turns a vague "I did QA work at my internship" into something an interviewer can actually ask specific follow-up questions about, which is exactly the kind of conversation that gets remembered after the interview ends.

Real-World Example

Consider a composite, realistic path: someone spends a few months in a manual QA role, learning STLC hands-on and writing real test cases against an actual product rather than a classroom exercise. Alongside that assigned work, they build one personal automation project a Selenium and TestNG suite covering a signup flow, including the OTP-verification piece that trips up a lot of automation efforts and publish it on GitHub with a README that explains specific decisions: why Page Object Model, why a particular wait strategy, why that OTP-handling approach.

In interviews, that one well-documented project becomes the centerpiece of nearly every technical conversation. Instead of reciting textbook definitions, the candidate can walk through a real design decision, a real bug they hit while building it, and why they solved it the way they did. That specificity one real project discussed in genuine depth consistently lands better than a resume listing ten tools with no story behind any of them, because it's the difference between claiming a skill and demonstrating one.

Best Practices

• Build one solid, complete project end-to-end rather than five shallow, half-finished ones.
• Write READMEs that explain why framework decisions were made, not just how to run the tests.
• Keep a running log of interesting bugs you've found and how you reported them genuinely useful interview material.
• Learn enough SQL and Git to stay confident in a technical round, even if you're not aiming for a pure SDET role.
• Treat certifications as a supplement to a portfolio, not a substitute for one.

Common Mistakes to Avoid

• Mistake: Copying a tutorial automation project with nothing meaningfully changed
  Fix: Build something with at least one genuinely original decision or twist you can explain and defend.
• Mistake: Listing tools on a resume without being able to explain a decision behind using them
  Fix: For every tool listed, be ready to explain one real choice you made while using it, not just that you used it.
• Mistake: Preparing only theory answers and freezing on scenario questions
  Fix: Practice structuring an answer out loud to open-ended prompts like 'how would you test X' before the interview.
• Mistake: Skipping SQL, Git, or basic scripting as "a developer's job"
  Fix: Learn the basics regardless of your track; they show up in technical rounds more often than expected.
• Mistake: No clear, honest narrative connecting internship work, personal projects, and career goals
  Fix: Prepare one coherent story linking what you've done to where you're trying to go, and practice telling it concisely.

Key Takeaways

• The manual-to-SDET path is a skill ladder foundation, then automation, then API/CI/CD, then broader engineering practice not a single jump.
• A portfolio built around one real, well-documented project beats a resume listing many tool names with no story behind them.
• QA interviews test three distinct layers theory, scenario-based thinking, and (for SDET tracks) hands-on technical work to prepare for all three deliberately.
• Internship work and personal projects are your strongest interview material when you can discuss them specifically and honestly.
• Certifications support a portfolio; they don't replace the need for demonstrable, hands-on work.