Testing mode

Features and test data can change before launch.

Choose a route. Build useful QA evidence.

Follow an ordered learning path, then use the skill map to find gaps, select a specialization, and create work that another person can review.

Start with one maintained path.

These course orders come from the published learning paths. The detailed map below supports gap analysis and later specialization.

Maintained learning path

Manual Testing

189 h estimated course time

Build product, process, testing, API, and security knowledge that helps you examine software and communicate risk with confidence.

Best forThis path is for new testers, career changers, and QA professionals who want a stronger manual testing foundation.
  1. 01Computing History10 h
  2. 02IT Fundamentals50 h
  3. 03Git Basics for QA15 h
  4. 04Scrum in Practice23 h
  5. 05Manual Testing Foundations26 h
  6. 06API Testing38 h
  7. 07Cybersecurity Fundamentals27 h
Check prerequisites and outcomes

Before you start

  • You do not need previous QA experience.
  • You need basic computer and web browser skills.
  • You need enough English to follow technical instructions.

After this path

  • Use computing history to explain how current product technologies developed.
  • Explain how product technology and delivery work affect testing.
  • Use Git and GitHub to preserve and review QA evidence.
  • Identify quality risks and select useful manual tests.
  • Test APIs safely and communicate findings to a delivery team.
  • Analyze common web and API security risks and report suspected vulnerabilities responsibly.
Follow the Manual Testing path
Maintained learning path

QA Automation

319 h estimated course time

Build historical, security, testing, and technical knowledge that changes QA decisions into reliable delivery feedback.

Best forThis path is for manual testers who want automation skills. It also supports new QA learners who are ready to learn code.
  1. 01Computing History10 h
  2. 02IT Fundamentals50 h
  3. 03Git Basics for QA15 h
  4. 04Scrum in Practice23 h
  5. 05Manual Testing Foundations26 h
  6. 06API Testing38 h
  7. 07Cybersecurity Fundamentals27 h
  8. 08SQL for QA Engineers26 h
  9. 09JavaScript for QA38 h
  10. 10TypeScript and Playwright42 h
  11. 11Python for QA24 h
Check prerequisites and outcomes

Before you start

  • You need basic computer and web browser skills.
  • Complete the manual testing foundation first, or have equivalent testing knowledge.
  • You do not need previous programming experience when you follow the course order.

After this path

  • Use computing history to explain how current systems inherited important concepts and constraints.
  • Explain how systems, data, APIs, security, and user interfaces affect an automation strategy.
  • Use Git collaboration and CI feedback during a test automation change.
  • Write useful JavaScript, TypeScript, and Python for QA work.
  • Build maintainable automated checks and run them in a delivery pipeline.
Follow the QA Automation path

Use it as direction, not a checklist.

  1. 01

    Choose one maintained learning path and follow its course order.

  2. 02

    Use stage readiness and outcomes to find the next skill gap that affects your work.

  3. 03

    Create the stated evidence and check every completion criterion before you continue.

QA engineer roadmap

Complete the core practice that fits your route. Choose a tool, framework, or specialty only when your product and team need it.

Course available Apply in stage evidence
  1. 01
    Core foundation · Stage 01

    Understand software quality

    Build the language and risk mindset that support every later testing decision.

    Start when

    No previous QA experience is required.

    Outcomes
    • Explain how quality assurance and testing support different decisions.
    • Describe a quality risk through likelihood and harm.
    • Separate an observation from an assumption or opinion.
    Create

    Write a one-page quality risk note for a product that you know.

    Complete when

    The note names the affected user, possible failure, harm, evidence source, and one unanswered question.

    Core practice

    Purpose and mindset

    Learn what QA contributes and how testing supplies evidence about product risk.

    Core practice

    Essential vocabulary

    Use stable terms so product specialists, developers, and testers can discuss the same evidence.

  2. 02
    Core foundation · Stage 02

    Learn how teams deliver software

    Place testing inside the delivery workflow instead of treating it as a final isolated phase.

    Start when

    You can explain quality risk and distinguish evidence from assumptions.

    Outcomes
    • Map a change from discovery through production support.
    • Explain how a delivery model changes feedback timing.
    • Identify decisions that need QA evidence.
    Create

    Draw a delivery map for one product change and mark each useful feedback point.

    Complete when

    The map names the decision owner, expected evidence, and feedback point from discovery through production.

    Core practice

    Delivery models

    Learn how each model changes feedback timing, test planning, and release decisions.

    Core practice

    Team workflow

    Understand where QA input changes product and engineering decisions.

  3. 03
    Core practice · Stage 03

    Practice manual testing

    Turn requirements, risks, and observations into focused tests and clear defect evidence.

    Start when

    You can identify a product risk and locate its place in the delivery workflow.

    Outcomes
    • Derive test conditions from risks and requirements.
    • Select a suitable test design technique.
    • Report a reproducible defect without guessing its cause.
    Create

    Create a test charter, a small set of designed tests, and one example defect report.

    Complete when

    Each test connects to a risk, and the defect report contains reproducible evidence and a clear effect.

    Core practice

    Test design techniques

    Select a small set of tests that represents a much larger input and behavior space.

    Core practice

    Execution and investigation

    Choose a test scope that matches the change, available time, and required confidence.

  4. 04
    Core practice · Stage 04

    Cover the right test levels and types

    Combine perspectives because no single test level or test type can reveal every important risk.

    Start when

    You can design and record focused manual tests.

    Outcomes
    • Select a test level that can answer a specific question.
    • Combine functional and quality-characteristic coverage.
    • State an important coverage limit.
    Create

    Create a coverage model for one feature across test levels, approaches, and quality characteristics.

    Complete when

    The model justifies each selected check and names at least one important coverage gap.

    Core practice

    Test levels and approaches

    Select the smallest useful boundary first, then add broader checks for connected behavior.

    04.1Test level

    Component testing

    Check a small unit of code or behavior in isolation with fast and focused feedback.

    Apply this topic in the stage evidence
    04.2Test level

    Integration testing

    Check contracts, data flow, timing, and failures between connected components.

    Apply this topic in the stage evidence
    04.3Test level

    System testing

    Evaluate the complete integrated product against functional and non-functional expectations.

    Apply this topic in the stage evidence
    04.4Test level

    Acceptance testing

    Confirm that the product supports agreed business needs and realistic user work.

    Apply this topic in the stage evidence
    04.5Approach

    Black-box testing

    Design tests from visible inputs and outputs without depending on internal implementation details.

    Apply this topic in the stage evidence
    04.6Approach

    White-box testing

    Use code structure, branches, paths, and data flow to design focused tests and evaluate structural coverage.

    Apply this topic in the stage evidence
    04.7Approach

    Gray-box testing

    Use limited architecture or data knowledge to select stronger tests and diagnose failures.

    Apply this topic in the stage evidence
    Core practice

    Quality characteristics

    Test characteristics that matter to the product, users, and operating environment.

    04.8Test type

    Functional testing

    Check whether product behavior meets defined rules and realistic user needs.

    Review the matching course curriculumManual Testing — Introduction to the QA World
    04.9Test type

    Compatibility testing

    Evaluate supported browsers, devices, operating systems, networks, and integrations.

    Apply this topic in the stage evidence
    04.10Test type

    Accessibility testing

    Check whether people with different abilities and assistive technologies can use the product.

    Apply this topic in the stage evidence
    04.11Test type

    Usability testing

    Observe whether representative users can complete important tasks accurately and efficiently.

    Apply this topic in the stage evidence
    04.12Test type

    Localization testing

    Check translated text, formats, layouts, sorting, and regional behavior for a target locale.

    Apply this topic in the stage evidence
    04.13Test type

    Reliability and recovery

    Check stable operation, fault handling, restoration, and data integrity after disruption.

    Apply this topic in the stage evidence
  5. 05
    Core technical practice · Stage 05

    Build technical foundations

    Inspect behavior below the interface so you can locate failures and collect stronger evidence.

    Start when

    You can test visible behavior and explain the risk behind each test.

    Outcomes
    • Inspect browser and network evidence.
    • Trace a change with Git and command-line tools.
    • Use a focused SQL query to confirm application state.
    Create

    Investigate one web failure with interface, network, repository, or database evidence.

    Complete when

    The investigation uses evidence from at least three system layers and records the limit of each source.

    Core practice

    Web and browser foundations

    Learn how a browser, a network, and a server combine to deliver an interface.

    05.1Technology

    HTML, CSS, and JavaScript

    Learn how structure, presentation, and behavior combine in a web page.

    Review the matching course curriculumJavaScript for QA Automation
    05.2Tool

    Browser developer tools

    Inspect elements, console messages, requests, storage, accessibility data, and performance signals.

    Review the matching course curriculumIT Fundamentals for Digital Teams
    05.3Protocol

    HTTP and HTTPS

    Read methods, URLs, status codes, headers, bodies, caching rules, and secure transport behavior.

    Review the matching course curriculumAPI Testing for Manual QA
    05.4Concept

    Cookies, sessions, and browser storage

    Check how the client preserves identity, preferences, and temporary application state.

    Apply this topic in the stage evidence
    05.5Concept

    AJAX and asynchronous interfaces

    Test interface updates that occur after background requests without a full page load.

    Apply this topic in the stage evidence
    05.6Concept

    Client-side and server-side rendering

    Recognize where content is produced and how that choice affects loading and testing.

    Apply this topic in the stage evidence
    05.7Test type

    Responsive and adaptive layouts

    Check content and controls across meaningful viewport sizes, orientation changes, and input methods.

    Apply this topic in the stage evidence
    Core practice

    Source and data foundations

    Trace changes and confirm persistent state with tools used by the delivery team.

  6. 06
    Core technical practice · Stage 06

    Test APIs and service contracts

    Validate service behavior directly before choosing a framework for repeatable API checks.

    Start when

    You can read HTTP traffic and use data evidence safely.

    Outcomes
    • Control request inputs and evaluate complete responses.
    • Test contract, authentication, authorization, and error behavior.
    • Compare API behavior with an authorized data source.
    Create

    Prepare an API evidence pack with a successful request, negative request, authorization check, and data comparison.

    Complete when

    Every result includes the request, response, expected rule, observed side effect, and evidence limit.

    Core practice

    API testing concepts

    Start with protocols, contracts, data, identity, and failure behavior.

    06.1Practice

    Requests and responses

    Control request inputs and evaluate status, headers, payloads, timing, and side effects.

    Review the matching course curriculumAPI Testing for Manual QA
    06.2Architecture

    REST APIs

    Test resources, methods, representations, status codes, pagination, filtering, and idempotent behavior.

    Review the matching course curriculumAPI Testing for Manual QA
    06.3Architecture

    GraphQL APIs

    Test queries, mutations, variables, schema rules, partial errors, and authorization at field boundaries.

    Apply this topic in the stage evidence
    06.4Architecture

    SOAP services

    Validate XML messages, service contracts, faults, namespaces, and transport behavior.

    Apply this topic in the stage evidence
    06.5Practice

    Contract and schema testing

    Check required fields, types, formats, compatibility rules, and consumer expectations.

    Review the matching course curriculumAPI Testing for Manual QA
    06.6Security

    Authentication and authorization

    Verify identity and confirm that each user can access only permitted operations and data.

    Review the matching course curriculumCybersecurity Fundamentals for QA Engineers
    06.7Practice

    Negative and resilience testing

    Send invalid, incomplete, repeated, delayed, and conflicting requests to examine safe failure behavior.

    Apply this topic in the stage evidence
    06.8Practice

    Data validation with SQL

    Compare service results with precise queries while respecting data ownership and privacy.

    Review the matching course curriculumSQL for QA Engineers
    Choose one when needed

    API tools and frameworks

    Choose one tool that fits the team language, pipeline, and maintenance needs.

    06.9Tool

    Postman and Newman

    Design requests in collections, add checks, manage environments, and run collections from a command line.

    Apply this topic in the stage evidence
    06.10Framework

    REST Assured

    Build Java API checks with readable requests, responses, extraction, and assertions.

    Apply this topic in the stage evidence
    06.11Framework

    Karate

    Express API scenarios with a domain-specific language and run them as automated checks.

    Apply this topic in the stage evidence
    06.12Tool

    SoapUI

    Explore and automate SOAP or REST service checks with reusable projects and data.

    Apply this topic in the stage evidence
    06.13Framework

    Pact

    Verify consumer-driven contracts so service teams can detect incompatible changes early.

    Apply this topic in the stage evidence
    06.14Tool

    WireMock

    Simulate HTTP dependencies, control responses, and verify expected service interactions.

    Apply this topic in the stage evidence
  7. 07
    Automation route · Stage 07

    Learn programming and automation design

    Choose one language, then learn reliable test-code design before collecting automation frameworks.

    Start when

    You can design a useful repeatable test and explain why automation is appropriate.

    Outcomes
    • Choose one language for a stated team need.
    • Write a small deterministic automated check.
    • Explain the maintenance and diagnostic needs of the check.
    Create

    Build one automated check with controlled data, a meaningful assertion, and a useful failure message.

    Complete when

    A second person can run the check, understand its purpose, and diagnose an intentional failure.

    Choose one

    Choose one language

    Use the language that fits your target product and the team that will maintain the checks.

    Core practice

    Automation engineering

    Design checks that remain clear, isolated, diagnosable, and worth maintaining.

    07.6Concept

    Test automation strategy

    Select checks by value, repeatability, feedback speed, maintenance cost, and failure clarity.

    Review the matching course curriculumJavaScript for QA Automation
    07.7Concept

    Test pyramid and test distribution

    Place more checks at fast, focused levels and use broad interface checks selectively.

    Apply this topic in the stage evidence
    07.8Practice

    Assertions and synchronization

    Assert meaningful outcomes and wait for observable conditions instead of fixed delays.

    Review the matching course curriculumTypeScript and Playwright for QA
    07.9Pattern

    Fixtures and setup

    Create known preconditions, isolate tests, and clean up state without hiding important behavior.

    Apply this topic in the stage evidence
    07.10Pattern

    Page objects and component models

    Centralize interface operations when the abstraction improves readability and change control.

    Review the matching course curriculumTypeScript and Playwright for QA
    07.11Practice

    Data-driven and parameterized tests

    Run the same behavior check with selected inputs while keeping each failure understandable.

    Apply this topic in the stage evidence
    07.12Practice

    Flaky test control

    Treat intermittent failures as defects and investigate timing, data, isolation, and environment causes.

    Review the matching course curriculumTypeScript and Playwright for QA
    07.13Practice

    Parallel execution

    Reduce feedback time while preventing shared data and resource conflicts.

    Apply this topic in the stage evidence
  8. 08
    Automation route · Stage 08

    Choose automation frameworks

    Compare framework scope, language, browser support, debugging, ecosystem, and team ownership.

    Start when

    You can write and debug a small automated check in one language.

    Outcomes
    • Select one framework that fits the product and team.
    • Use framework-native waiting and isolation.
    • Collect diagnostic evidence from a failed run.
    Create

    Build a three-check suite for one stable workflow and document why the framework fits.

    Complete when

    The suite runs independently, avoids fixed delays, and preserves enough evidence to diagnose a failure.

    Choose one

    Web automation

    Choose one main browser framework and learn its waiting, isolation, assertion, and debugging model.

    08.1Framework

    Playwright

    Automate modern browsers with isolated contexts, web-first assertions, tracing, and multiple language options.

    Review the matching course curriculumTypeScript and Playwright for QA
    08.2Framework

    Cypress

    Run browser-focused checks with automatic retry behavior, interactive debugging, and a JavaScript or TypeScript test API.

    Apply this topic in the stage evidence
    08.3Framework

    Selenium WebDriver

    Control browsers through the WebDriver standard and use the test runner from your chosen language.

    Apply this topic in the stage evidence
    08.4Framework

    WebdriverIO

    Build JavaScript or TypeScript checks for browsers and mobile applications with a plugin-based runner.

    Apply this topic in the stage evidence
    08.5Framework

    Puppeteer

    Control Chromium or Firefox through a JavaScript API for browser tasks and focused checks.

    Apply this topic in the stage evidence
    08.6Practice

    Cross-browser and headless testing

    Run representative checks across supported engines and keep headed debugging available for failures.

    Apply this topic in the stage evidence
    08.7Platform

    Browser grids and device clouds

    Run checks across managed browser, operating-system, and device combinations when local coverage is insufficient.

    Apply this topic in the stage evidence
    Match your language

    Test runners by language

    Use the runner and assertion tools that fit your language and application ecosystem.

    08.8Framework

    Jest or Vitest

    Organize JavaScript or TypeScript tests with fixtures, assertions, mocks, filtering, and reports.

    Apply this topic in the stage evidence
    08.9Framework

    pytest

    Organize Python tests with fixtures, parameterization, markers, plugins, and concise assertions.

    Apply this topic in the stage evidence
    08.10Framework

    JUnit or TestNG

    Structure Java tests with lifecycle hooks, parameterization, grouping, and build-tool integration.

    Apply this topic in the stage evidence
    08.11Framework

    NUnit or xUnit.net

    Structure C# tests with setup, parameterized cases, assertions, and .NET tooling.

    Apply this topic in the stage evidence
    Optional specialization

    Mobile automation

    Add mobile automation when native behavior and supported devices create important product risk.

    08.12Framework

    Appium

    Automate native, hybrid, and mobile web applications through the WebDriver protocol.

    Apply this topic in the stage evidence
    08.13Framework

    Espresso

    Build focused Android interface checks with synchronization inside the application process.

    Apply this topic in the stage evidence
    08.14Framework

    XCUITest

    Build native Apple-platform interface checks with XCTest and accessibility-based element queries.

    Apply this topic in the stage evidence
    08.15Framework

    Detox

    Create gray-box end-to-end checks for React Native applications with application synchronization.

    Apply this topic in the stage evidence
    08.16Platform

    Emulators, simulators, and real devices

    Use virtual devices for fast feedback and real devices for hardware, network, and platform evidence.

    Apply this topic in the stage evidence
  9. 09
    Choose by product risk · Stage 09

    Add specialty testing

    Learn each specialty from its risks and measurements before selecting a tool.

    Start when

    You can explain the product architecture, users, and highest quality risks.

    Outcomes
    • Select a specialty because of a stated product risk.
    • Choose evidence and measurements before a tool.
    • Report safety, authorization, and coverage limits.
    Create

    Create one authorized specialty test charter and a result report for a realistic product risk.

    Complete when

    The report states the model, measurement, environment, result, limitation, and accountable next decision.

    Choose for a performance risk

    Performance testing

    Model realistic work, define useful measurements, and observe client and server behavior.

    09.1Test type

    Load and stress testing

    Measure expected workload first, then increase pressure to study limits and recovery.

    Apply this topic in the stage evidence
    09.2Tool

    k6

    Write JavaScript load scenarios, define thresholds, and export measurements for analysis.

    Apply this topic in the stage evidence
    09.3Tool

    Apache JMeter

    Build protocol-level plans for load generation, parameterization, correlation, and distributed runs.

    Apply this topic in the stage evidence
    09.4Framework

    Gatling

    Define code-based load simulations with detailed timing reports for supported protocols.

    Apply this topic in the stage evidence
    09.5Framework

    Locust

    Write Python user behavior and distribute load generation across worker processes.

    Apply this topic in the stage evidence
    09.6Framework

    Artillery

    Define command-line performance scenarios for HTTP and event-driven services.

    Apply this topic in the stage evidence
    Choose for a security risk

    Security testing

    Test trust boundaries, identity, input handling, secrets, and safe failure with explicit authorization.

    Choose for an accessibility risk

    Accessibility testing

    Combine automated checks with keyboard use, assistive technology, and human evaluation.

    09.12Tool

    axe

    Detect selected accessibility rule violations without claiming complete accessibility coverage.

    Apply this topic in the stage evidence
    09.13Tool

    Lighthouse

    Audit selected accessibility, performance, and web quality signals during development.

    Apply this topic in the stage evidence
    09.14Practice

    Keyboard and screen readers

    Test focus order, names, roles, states, instructions, announcements, and complete task flows.

    Apply this topic in the stage evidence
  10. 10
    Automation delivery · Stage 10

    Connect testing to CI/CD

    Run the right checks at the right delivery stage and keep failed feedback easy to investigate.

    Start when

    You have a version-controlled automated suite that runs reliably on your computer.

    Outcomes
    • Place checks at suitable pipeline stages.
    • Define a reliable quality gate with an owner.
    • Protect configuration and preserve failure artifacts.
    Create

    Run a small automated suite in CI and retain the result and diagnostic artifacts.

    Complete when

    A fresh change starts the pipeline, failures are diagnosable, and no credential appears in code, logs, or artifacts.

    Core practice

    Pipeline design

    Build fast feedback first, then add broader checks where their cost and evidence make sense.

    10.1Concept

    Continuous integration and delivery

    Build each change, run useful checks, preserve evidence, and control promotion between environments.

    Apply this topic in the stage evidence
    10.2Practice

    Quality gates

    Block promotion only with checks that are reliable, relevant, owned, and fast enough for that stage.

    Apply this topic in the stage evidence
    10.3Practice

    Test selection and splitting

    Run checks by risk, changed area, tag, duration, or shard to control feedback time.

    Apply this topic in the stage evidence
    10.4Technology

    Docker and test environments

    Package dependencies consistently and create isolated environments with known versions and configuration.

    Apply this topic in the stage evidence
    10.5Practice

    Configuration and secrets

    Separate environment settings from code and prevent credentials from entering logs, artifacts, or repositories.

    Apply this topic in the stage evidence
    10.6Practice

    Artifacts and reports

    Preserve logs, screenshots, traces, videos, and machine-readable results for failed checks.

    Apply this topic in the stage evidence
    Use your team platform

    CI/CD platforms

    Learn the platform your team uses because the pipeline concepts transfer between products.

    10.7Platform

    GitHub Actions

    Define repository workflows with events, jobs, runners, permissions, caches, secrets, and artifacts.

    Review the matching course curriculumTypeScript and Playwright for QA
    10.8Platform

    GitLab CI/CD

    Define staged or directed pipelines with runners, variables, caches, environments, and reports.

    Apply this topic in the stage evidence
    10.9Platform

    Jenkins

    Build pipelines with managed agents, plugins, credentials, stages, and retained test evidence.

    Apply this topic in the stage evidence
    10.10Platform

    Azure Pipelines

    Run multi-stage builds and tests with agents, environments, approvals, artifacts, and test publishing.

    Apply this topic in the stage evidence
    10.11Platform

    CircleCI

    Configure jobs, workflows, executors, caches, workspaces, and stored test results.

    Apply this topic in the stage evidence
    10.12Platform

    Bamboo or TeamCity

    Configure builds, agents, dependencies, variables, and test reports in a managed CI server.

    Apply this topic in the stage evidence
  11. 11
    Professional practice · Stage 11

    Manage quality and learn from production

    Turn test work and production signals into clear decisions and continuous improvement.

    Start when

    You have stage evidence that shows manual, technical, or automated QA work.

    Outcomes
    • Summarize coverage, evidence, uncertainty, and release options.
    • Use production signals to improve future testing.
    • Present QA work as a reviewable professional artifact.
    Create

    Prepare a release recommendation and a compact portfolio case study from your roadmap evidence.

    Complete when

    Both artifacts link claims to evidence, state important limits, name the decision owner, and identify the next learning need.

    Core practice

    Test management and reporting

    Choose tools that support communication without making documentation the goal.

    11.1Practice

    Test planning and prioritization

    Define scope, risks, people, environments, data, schedule, and exit conditions.

    Review the matching course curriculumManual Testing — Introduction to the QA World
    11.2Tool

    Jira with Xray or Zephyr

    Connect requirements, defects, test cases, executions, and reports inside an issue-tracking workflow.

    Apply this topic in the stage evidence
    11.3Tool

    TestRail

    Organize test cases, plans, runs, results, milestones, and reports in a dedicated system.

    Apply this topic in the stage evidence
    11.4Tool

    qTest

    Manage test design, execution, defects, traceability, and reporting across delivery teams.

    Apply this topic in the stage evidence
    11.5Tool

    Allure Report

    Transform automated-test results into navigable reports with steps, attachments, history, and categories.

    Apply this topic in the stage evidence
    11.6Practice

    Coverage and release reporting

    State what was tested, what remains uncertain, and what action the evidence supports.

    Review the matching course curriculumManual Testing — Introduction to the QA World
    Core practice

    Observability and operations

    Use logs, metrics, traces, alerts, and user impact to investigate real system behavior.

    11.7Practice

    Monitoring and logs

    Use production signals to detect failures, investigate incidents, and improve future coverage.

    Apply this topic in the stage evidence
    11.8Platform

    Grafana and Prometheus

    Explore metrics, build dashboards, and relate service behavior to test or production events.

    Apply this topic in the stage evidence
    11.9Platform

    Kibana and Elastic

    Search and visualize structured events and logs to trace behavior across services.

    Apply this topic in the stage evidence
    11.10Platform

    Datadog or New Relic

    Correlate application, infrastructure, browser, log, trace, and alert data.

    Apply this topic in the stage evidence
    11.11Platform

    Sentry

    Investigate application errors, affected releases, stack traces, context, and user impact.

    Apply this topic in the stage evidence
    11.12Practice

    Incident review

    Reconstruct the event, identify system contributors, assign improvements, and verify that actions reduce recurrence.

    Apply this topic in the stage evidence
    Core practice

    Professional practice

    Develop judgment, communication, and technical depth through visible work.

    11.13Practice

    Risk communication

    Describe likelihood, impact, evidence, uncertainty, and options without presenting opinion as fact.

    Review the matching course curriculumManual Testing — Introduction to the QA World
    11.14Practice

    QA portfolio

    Show concise test artifacts, automation code, investigations, and the reasoning behind important choices.

    Apply this topic in the stage evidence
    11.15Practice

    AI-assisted QA work

    Use AI to generate or transform ideas, then review outputs against evidence, privacy rules, and product risk.

    Apply this topic in the stage evidence
    11.16Practice

    Choose a specialization

    Deepen the area that matches your product risks, team needs, and career direction.

    Apply this topic in the stage evidence
    11.17Practice

    Continuous learning

    Review escaped defects, flaky checks, incidents, feedback, and architecture changes to choose your next skill.

    Apply this topic in the stage evidence

Start with the gap that matters now.

You do not need every skill before you can contribute. Build one capability, use it on a realistic product, and record the evidence.