Manual QA to Agentic SDET: 6-Month Roadmap (2026)

Manual QA professionals are in a strong position to become the next wave of Agentic SDETs: engineers who build, guide, and evaluate autonomous test agents—not only click through UIs or maintain brittle Selenium suites.

This guide is a focused six-month roadmap: from “I mostly explore manually” to “I design automation suites and agentic QA workflows.” Each month has a clear goal, skills list, and deliverables you can put on GitHub and talk about in interviews.

For compensation and senior-level progression, pair this with SDET Career Roadmap 2026: $150K+ Salaries (USA/Europe Focus). For what “agentic” means in testing, see Agentic AI Testing for Software Test Engineers. For a full agent build walkthrough, see Build a LangChain Test Agent: Full Code Repo Walkthrough.

What “Agentic SDET” actually means

An Agentic SDET is more than “QA + automation.” It is an engineer who:

• Knows one programming language deeply enough to build frameworks and small tools
• Owns API and UI automation, CI/CD integration, and debugging
• Understands LLM basics and can use agents (autonomous LLM + tool workflows) for test design, execution, and analysis
• Evaluates and guardrails those agents so they improve quality instead of creating noise

You do not need twenty tools to get there. You need a clear progression and consistent practice over six months.

Roadmap at a glance

Plan for roughly 5–7 hours per week (see Weekly rhythm below).

Month 1 — Foundations: one language and Git

Goal: Move from “I read code” to “I can write small utilities and tests in one language confidently.”

Pick one language

Choose one and stay with it for the whole roadmap:

• Java — common in enterprise QA and pairs with TestNG, Rest Assured
• Python — fast for scripts, pytest, and LangChain agents
• JavaScript/TypeScript — strong if your team is web-first (Playwright, Cypress)

For most manual QA → SDET transitions, Python or Java are excellent starting points.

What to learn

• Syntax, variables, functions
• Conditions and loops
• Collections (lists, arrays, maps/dicts)
• Basic OOP (classes, objects, methods)
• JSON handling and simple file I/O
• Git: clone, branch, commit, push, pull request

Mindset shift

• Stop thinking only in “test cases in Excel”; start thinking reusable functions and scripts
• Read open-source test frameworks and copy patterns (page objects, fixtures, utils)—see Page Object Model 2026: Best Practices

Deliverables by end of Month 1

• Three to four small coding exercises (calculator, string utilities, basic HTTP calls)
• A GitHub repo with practice code and a clear commit history

Month 2 — API automation: where real confidence starts

Goal: Automate APIs reliably—where business logic often lives and where suites are cheaper to maintain than UI-only guards.

APIs are why modern SDET plans push APIs before heavy UI. See REST Assured Complete Tutorial (Java API Testing) if you chose Java.

Tools to pick

Exploration (any language): Postman or the VS Code REST client—use these to learn endpoints before you automate.

Automation (pick the row for your Month 1 language):

What to learn

• HTTP: methods, status codes, headers, query params, JSON bodies
• Assertions: status, schema, key fields, arrays
• Positive and negative scenarios: 200 vs 4xx/5xx, invalid data, auth errors
• Test data: static vs dynamic payloads
• Contract mindset: when is a change breaking? → Contract Testing for Microservices

Deliverables by end of Month 2

• A small API test suite against a public API or a simple local service
• Coverage for at least: happy path, invalid input, auth error
• Single command to run in CI (e.g. pytest tests/api)

Month 3 — UI automation: one framework, done well

Goal: Validate end-to-end flows with one UI framework—UI as a thin layer on top of API confidence, not the only safety net.

Choose one framework

• Playwright (recommended for new projects)
• Selenium (legacy enterprise stacks)
• Cypress (strong for front-end teams)

Pick based on your job market and stack; do not try to master all three at once.

What to learn

• Locators: role, label, data-testid; avoid brittle CSS-only selectors
• Waits: explicit waits, auto-waiting; avoid naked sleep()
• Organization: Page Object or Screenplay, fixtures for setup/auth, reusable login and data helpers
• Parallel runs and basic cross-browser setup

Deliverables by end of Month 3

• UI suite for two to three flows (login, search, checkout) on a demo or internal app
• Page objects and fixtures in place
• API tests used to seed data before UI where possible

Month 4 — CI/CD, debugging, and thinking like an engineer

Goal: Integrate API + UI suites into CI and debug failures from logs and traces—not only “steps to reproduce.”

Many manual testers plateau here; SDETs and Agentic SDETs push through.

CI/CD basics

• GitHub Actions, GitLab CI, or Jenkins
• Run suites on every PR or on merges to main
• Store artifacts: HTML reports, videos, screenshots, logs
• Simple notifications: failing pipeline → Slack or Teams

Walkthrough: GitHub Actions + Playwright CI/CD pipeline.

Debugging skills

• Read stack traces and error logs
• Browser dev tools: Network, Console, Storage
• Check DB or API logs when available
• Reproduce CI failures locally from pipeline output

Deliverables by end of Month 4

• A pipeline that runs API + UI tests on push
• Habit of opening logs/traces before asking devs “what broke?”
• At least two to three bugs documented with investigation summary, not only reproduction steps

Month 5 — Architect mindset: risk, observability, and test design

Goal: Design testing systems, not only test cases—the step that prepares you to place agents in the architecture as another layer, not magic.

What to focus on

• Risk-based testing — prioritize by impact and likelihood → Risk-Based Testing Framework for Enterprise Teams
• Observability — logs, metrics, traces; what your framework should record (request/response, correlation IDs, screenshots on failure)
• Flaky tests — root causes (waits, data, environment); fix, do not only retry → Fix Flaky Tests: 2026 Masterclass

Design thinking

• Map key business flows; decide what belongs in unit vs API vs UI vs production checks
• Design frameworks with extension points: fixtures, plugins, helpers
• Portfolio balance: Modern Test Pyramid 2026: Complete Strategy

Deliverables by end of Month 5

• A short testing strategy doc for a sample system: what you test at which layer and why
• Measurable reduction in flakiness (root-cause fixes, not blind --retries)

Month 6 — Agentic AI and LLM testing

Goal: Add agentic QA skills: build and evaluate at least one agent that assists testing—with guardrails.

Industry direction includes autonomous agents that plan, execute, and heal tests; your role is to design, integrate, and evaluate them.

Step 1 — Core LLM and agent concepts

• LLMs at a high level: tokens, context window, temperature
• Prompt engineering and system prompts → Prompt Engineering for Test Automation
• Agents in LangChain-style stacks: LLM + tools + memory/planning

Step 2 — Agentic QA use cases

• Test case generation from specs or logs
• Self-healing locators and suggested fixes → Self-Healing Tests with AI: Playwright Tutorial
• Root-cause analysis from CI logs, traces, and code context
• RAG-based documentation assistants for test design

Step 3 — Hands-on mini-project (pick one)

Start from the repo patterns in Build a LangChain Test Agent: Full Code Repo Walkthrough.

Step 4 — Evaluation and guardrails

Agentic QA is not “ship the agent and walk away.”

• Metrics: accuracy, coverage added, time saved, false-positive rate
• Guardrails: limit file write paths, human review before merge, log every tool call
• Evals: trajectory checks, LLM-as-judge where appropriate → AI Test Hallucinations: Detection and Fixes

Deliverables by end of Month 6

• One working agentic QA project on GitHub
• Short writeup: problem, architecture, tools, evaluation, lessons learned
• Interview-ready stories on agentic QA, LLM testing, and agent evaluation

Weekly rhythm

Across all six months, keep a simple pattern:

Every week:

• Push something to GitHub (even small)
• Write a short log: what you learned, what you built, what broke

Compounding beats cramming a weekend once a month.

How to know you have become an Agentic SDET

By the end of this plan, you should be able to:

• Own API and UI automation for a feature from scratch
• Integrate tests into CI, debug failures, and collaborate with devs using logs and traces
• Explain risk-based testing and design a layered strategy
• Build and evaluate at least one agent that assists testing (generation, triage, or LLM behavior checks)

At that point, “Manual QA → Agentic SDET” is not a slogan—it is your profile, portfolio, and interview narrative.

If you are not starting from zero

Adjust the timeline rather than skipping foundations:

Use the deliverables each month as checkpoints—not rigid calendar gates.

Conclusion

The path from manual QA to Agentic SDET is learnable in six months with one language, API-first confidence, one UI framework, CI discipline, risk-aware design, and a hands-on agent project. You do not need every tool on the market; you need progressive depth and proof on GitHub.

Start Month 1 this week: pick your language, create the repo, and ship the first small exercise. The rest of the roadmap builds on that momentum.