QA Wiki

Appearance

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 is worked 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. The evolving QA role
  6. 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 opens 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. Shift-left and maturity
  6. Bug root cause analysis
  7. Performance testing fundamentals — test types and the metrics that matter.
  8. JMeter in practice — from the design GUI to the CLI in the pipeline.
  9. Security for QA: OWASP Top 10 planned
  10. 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.

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.