Skip to content

QA learning path ​

The path I would follow today to train as a QA Engineer, in order. Links go to articles on this wiki; items marked planned are part of the path but not written yet — they're also this wiki's backlog.

It's not a strict ladder: stages overlap, and it's normal to work with one while studying the next. But the order matters — automating without knowing how to design test cases is automating badly.

Stage 1 — The base ​

The vocabulary and concepts everything else is built on.

  1. What is QA? — QA vs QC vs testing, and the 7 principles.
  2. Types of testing
  3. The testing pyramid
  4. Test case design — the core skill of the craft.
  5. Bug reporting — a badly reported bug is a bug that doesn't get fixed.
  6. Exploratory testing — the technique that finds what scripts don't anticipate.

Stage 2 — The craft in a real team ​

How quality work gets done inside an agile team, beyond executing tests.

  1. Agile testing strategy
  2. Acceptance criteria & DoR
  3. How to review a task
  4. Defining tests for a feature
  5. Scrum from the QA seat — what QA does in each ceremony, and estimation that includes testing.
  6. Test management with Xray — tests, plans and executions that keep traceability.
  7. The evolving QA role
  8. Onboarding into a complex domain — for every new job or project.
  9. Git basics for QA — the daily flow and Git as an investigation tool (diff, blame, bisect).

The ISTQB CTFL won't make you a better tester by itself, but it organizes your vocabulary, fills gaps and gets your CV past HR filters. This is the best moment in the path for it: with stages 1 and 2 done, much of the syllabus will already sound familiar.

  1. The CTFL v4.0 exam
  2. Study plan

Stage 4 — The web from the inside: APIs ​

Before automating interfaces you need to understand what travels underneath.

  1. HTTP fundamentals
  2. What to test in an API
  3. Anatomy of an API test
  4. JSON Schema validation
  5. Test data and authentication
  6. Async APIs with Awaitility
  7. API framework architecture
  8. Karate: API testing with BDD — the fast, readable route.
  9. REST Client (VS Code)
  10. Postman and SoapUI — testing APIs without a framework, including SOAP and its WSDL.
  11. SQL for QA — validating in the database what the API claims.
  12. NoSQL for QA — validating when no schema defends you.
  13. Contract testing (Pact) planned

Stage 5 — E2E automation ​

Judgment first, tooling second.

  1. When to automate — and when not to.
  2. The E2E tools landscape — Selenium, WebDriverIO, Cypress, Playwright: choose with criteria.
  3. Cypress: first steps — the mental model: chaining and automatic retry.
  4. Cypress: patterns that work — cy.session, cy.intercept and state via API.
  5. Playwright: first steps
  6. Page Object Model
  7. Configuring and organizing the suite
  8. TypeScript for QA
  9. Python for QA — the utility language: pytest and requests.
  10. BDD with Cucumber — when it pays off and when it's theater.
  11. Migrating from TestCafe to Playwright — a real case, with numbers.
  12. AI in test automation
  13. Visual testing planned
  14. Mobile testing planned

Stage 6 — The pipeline ​

Testing lives in CI/CD or it doesn't scale.

  1. Environment validations
  2. Jenkins and GitLab CI — the concepts travel between tools.
  3. Static analysis
  4. Parallelization and sharding
  5. Docker for QA — the factory of reproducible environments.
  6. AWS for QA — logs, data and artifacts in the cloud, without depending on anyone.
  7. Observability and logs for QA planned

Stage 7 — Advanced strategy ​

Designing the quality of a whole system, not of a single feature.

  1. Testing layers: backend
  2. Testing layers: frontend
  3. What E2E tests should cover
  4. Microservices testing
  5. Test environments strategy — what each environment can prove.
  6. Mocks in integration testing — useful, and they lie.
  7. Shift-left and maturity
  8. Bug root cause analysis
  9. Investigating hard failures — intermittent bugs and production incidents.
  10. Performance testing fundamentals — test types and the metrics that matter.
  11. JMeter in practice — from the design GUI to the CLI in the pipeline.
  12. Security for QA: OWASP Top 10 planned
  13. Accessibility testing planned

Stage 8 — Domain specialization ​

Every sector has its own map of systems and its own vocabulary. In my case, telecom:

  1. OSS/BSS for QA — an operator's systems, TM Forum, and what testing chains of systems means.
  2. The catalog: offers, CFS, RFS and resources — configuration that decides behavior.
  3. Service orders (TMF641) — the state machine, and why the inventory is the truth.
  4. Fallout management — when provisioning fails, and how to test it.
  5. Testing workflows on a BPM engine — versions, skipped tasks and human tasks.

Stage 9 — Advanced certification (optional) ​

Once you've built and maintained real automation for a while, the ISTQB Advanced Level Test Automation Engineering turns that experience into structured judgment: framework architecture, approaches and patterns, pipelines, reporting, and how to verify and improve the automation itself. Take it when the syllabus describes things you've already done, not before.

  1. The Advanced Level: which module
  2. Advanced Test Automation Engineering: exam and syllabus map
  3. TAE study plan
  4. TAE practice questions

How to use this path

Starting from zero: complete stages 1 and 2 before anything else, and find a real project (your own or a practice one) to apply each stage to as soon as possible. Already working as a QA: use it to spot your gaps — we all have them.