Learning paths

Begin with what testing is for and how it fits into development: the SDLC and STLC, test levels and types, and how to write test cases and bug reports. Then practise on real applications by exploring features and noting what could break. Once you are comfortable, add programming and automation. The free testing fundamentals path covers this from the first lesson, with exercises and links to interview questions for each topic.

Learn testing fundamentals before tools. Understand test design techniques such as boundary value analysis and equivalence partitioning, the difference between functional and non-functional testing, and how to write a clear bug report. These skills decide what you test, which matters more than how you automate it. Then learn one programming language and HTTP basics. Start with the introduction to software testing lesson.

Fundamentals, then programming, then automation. Concretely: test design; one language such as TypeScript, Java or Python; Git; API testing; a UI framework; framework patterns such as page objects, fixtures and test data management; CI/CD; then a specialism such as performance, security, mobile or AI testing. Each step should end with something you have built. The paths on this page follow that order, and the SDET roadmap shows how they connect.

There is no fixed timeline; it depends on your starting point and how much time you put in each week. As a rough guide, a manual tester studying steadily part-time often needs six to twelve months to reach junior automation level, a developer moving into testing may need a few months to learn test design and tooling, and someone starting from zero usually needs longer. Measure progress by projects built and bugs debugged, not hours of video watched.

Playwright is a good first choice for most beginners. Setup is a single command, auto-waiting removes most timing problems, the codegen tool records starter tests, and the trace viewer shows exactly why a test failed. Choose Selenium if the jobs you want use Java and Selenium, or Cypress if your team already uses it. Whichever you pick, learn the shared concepts: locators, waits, assertions and page objects. See choosing an automation tool.

If you have no constraints, start with Playwright: it is quicker to set up and its defaults teach good habits, such as user-facing locators and web-first assertions. Learn Selenium first if your target employers or current team use it, which is common in Java-based enterprise projects. Moving from one to the other later is much faster than learning the first, because the concepts transfer. Practise both in the Playwright lab and the Selenium lab.

Yes. JavaScript, and TypeScript on top of it, is the native language of Playwright, Cypress and WebdriverIO, shares an ecosystem with most web front ends, and handles JSON naturally, which suits API testing. TypeScript adds type checking that catches mistakes in larger frameworks. The main hurdle is asynchronous code, so understand promises and async/await early. Start with JavaScript essentials for testers.

Automation is moving earlier and deeper: more API and contract tests, fewer brittle UI tests, suites that run on every pull request, and more attention to observability and testing in production. AI is speeding up test creation and maintenance, while creating new work in testing AI features. The constant is the need for engineers who know what to test and can build reliable, maintainable suites. Read the introduction to AI-powered testing for where AI fits.

AI is changing both how tests are written and what needs testing. LLM assistants draft test cases and automation code, explain failures and suggest locators, and AI agents can explore an application through a browser. At the same time, products with LLM features need new techniques, such as evaluation datasets, LLM-as-judge scoring and prompt-injection tests. Testers who review AI output critically and can test AI systems gain the most. See the AI in testing path.

Agentic AI refers to AI systems that plan and take actions toward a goal rather than only answering a prompt. In testing, an agent might read a user story, open the application in a browser, explore flows, draft or repair automated tests and report what it found, using tools such as a browser driver or test runner. Agents still need clear goals, guardrails and human review of their output. The agentic AI for testing lesson explains the patterns and the risks.

MCP (Model Context Protocol) is an open standard that lets AI assistants connect to external tools and data through MCP servers. For QA engineers, it means an assistant can use a browser automation server, such as Playwright MCP, to navigate an app, query a test database, read issues from a bug tracker or run a test suite, then reason about the results. Treat MCP access like any credential: limit permissions and review actions. See MCP for QA workflows.

Start with how large language models work and where they fail, then use them on real tasks: generating test ideas, drafting automation code and reviewing it critically. Next, learn to test AI features: building evaluation datasets, scoring outputs, and checking for hallucinations and prompt injection. Keep your core automation skills sharp, because reviewing AI-generated tests depends on them. The AI in testing path covers these topics in order, from fundamentals to agents and MCP.