---
title: "Technical QA: Comprehensive Engineering Documentation"
subtitle: "Roles, responsibilities, workflows, evidence, automation, delivery, and game quality"
lang: en
dir: ltr
author: "Technical QA Documentation"
updated: "2026-08-09"
description: >
  Comprehensive English documentation for Technical QA, including role
  boundaries, responsibilities, risk-based testing, test architecture,
  automation, CI/CD, non-functional testing, metrics, Unity and game QA,
  investigation workflows, templates, and explanatory diagrams.
keywords:
  - Technical QA
  - Software Testing
  - Quality Engineering
  - Test Automation
  - CI/CD
  - Test Strategy
---

# Technical QA: Comprehensive Engineering Documentation

> Technical QA combines testing judgment, software-engineering skills, risk analysis, and reliable feedback across the software delivery lifecycle.

This document is an English engineering reference based on the supplied research material. It explains what Technical QA is, how the discipline works, what responsibilities it carries, and how its methods connect across product development, delivery, and production. The structure prioritizes clear explanation, practical context, and reference use.

## Executive summary

Technical QA is an engineering-oriented quality role that connects product risk, software architecture, test design, automation, delivery pipelines, observability, and release decisions. The title is not standardized: one company may use it for a technically strong QA Engineer, another for an SDET-like role, and another for a quality specialist embedded in a delivery team. Judge the role by its responsibilities and decision authority rather than its title.

This edition incorporates the supplied *Technical QA Research* PDF topic brief, including organizational cadence, role boundaries, root-cause analysis, Unity and game-development QA, realistic scenarios, project examples, and a competency map. The companion website includes a responsive visual atlas for the major systems and workflows.

**Website:** [https://technical-qa.site](https://technical-qa.site)

## Audience and scope

This reference is useful for:

- manual or functional testers who need stronger technical context;
- junior QA engineers who need a coherent view of the discipline;
- developers moving toward test automation or quality engineering;
- senior QA engineers designing test portfolios and delivery gates;
- QA leads defining competencies, hiring criteria, and quality strategy;
- product and engineering leaders who need a shared model of quality ownership.

## Documentation coverage

The documentation explains how to:

1. Explain how Quality Assurance, testing, Quality Control, and Quality Engineering relate.
2. Analyze product risk and select suitable test techniques and test levels.
3. Decide what belongs in unit, integration, API, contract, component, and end-to-end testing.
4. Design maintainable automation rather than merely recording more scripts.
5. Integrate fast, trustworthy quality feedback into CI/CD.
6. Plan performance, security, accessibility, and compatibility testing according to risk.
7. Investigate failures using logs, metrics, traces, data, and environment evidence.
8. Report release confidence and uncertainty without hiding risk behind pass rates.
9. Interpret competency expectations from junior through senior, lead, or staff-level work.

## How to use this reference

Read the foundations for a shared definition of the role, then use the remaining parts by responsibility or workflow. Each topic connects the concept to its operational purpose, evidence, examples, and failure modes. The website adds search, responsive navigation, and a visual atlas for readers who prefer system diagrams and flowcharts.

HTTP, SQL, Git, programming, automation, and CI are documented beside testing judgment because Technical QA applies them together. Product thinking and engineering skill are complementary parts of the same responsibility.

---

# Part I — Foundations

## 1. What Technical QA means

“Technical QA” is better understood as a spectrum of engineering-oriented quality roles than as a universally standardized job title. Companies use titles such as QA Engineer, Software Test Engineer, Quality Engineer, Automation Tester, Test Automation Engineer, and SDET for overlapping areas of work. The title matters less than an explicit definition of responsibility.

The [O*NET profile for Software Quality Assurance Analysts and Testers](https://www.onetonline.org/link/summary/15-1253.00) includes designing and executing tests, documenting defects, reviewing system changes, participating in design reviews, maintaining automated scripts, and providing feedback to developers. That breadth is a useful reminder that the role extends beyond executing predefined test cases.

### Working definition

> A Technical QA professional engineers software quality by combining testing judgment, risk analysis, technical knowledge, system observability, targeted human testing, and maintainable automation throughout the SDLC—not by checking the product only after development is complete.

This definition aligns with the whole-team and lifecycle-oriented direction of the [ISTQB Certified Tester Foundation Level](https://www.istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/), which applies testing knowledge across sequential, Agile, DevOps, and continuous-delivery contexts.

### QA is not identical to testing

Testing is a set of activities used to evaluate software and expose quality risks. Quality Assurance is broader and more preventive: it influences process, clarity, testability, feedback loops, and how a team reduces the chance of defects.

Technical QA may contribute to:

- requirement and acceptance-criteria reviews;
- risk discovery before implementation;
- testability, logging, and diagnostic design;
- manual, exploratory, API, data, and automated testing;
- reliable CI quality signals;
- release-risk analysis;
- learning from production incidents.

QA should not become the final “quality gatekeeper.” Developers, QA, product, UX, operations, security, and leadership share responsibility for quality. Technical QA provides specialized leadership in risk, evidence, and feedback.

### Approximate role boundaries

The following is an educational model, not an official industry taxonomy.

| Role | Dominant focus | Coding depth | Product-risk focus | Automation and CI |
|---|---|---:|---:|---:|
| Manual / Functional Tester | Product behavior and exploratory testing | Low to medium | High | Low to medium |
| QA Engineer | System quality and multi-layer testing | Medium | High | Medium |
| Technical QA | Quality, technical analysis, and automation | Medium to high | High | High |
| Automation Engineer | Automation frameworks and infrastructure | High | Medium | Very high |
| SDET / Software Engineer in Test | Testing software, tools, and testability | High | Medium to high | Very high |
| Quality / QA Lead | Strategy, risk, people, and process | Variable | Very high | Architectural oversight |

### A realistic day of Technical QA work

| Activity | Example contribution |
|---|---|
| Refinement | Challenge ambiguity, acceptance criteria, edge cases, and testability before development |
| Test analysis | Turn business rules and risks into scenarios, boundaries, and decision tables |
| Technical investigation | Inspect API requests, database state, logs, network traffic, integrations, and permissions |
| Automation | Add or refactor tests at API, component, contract, or E2E level |
| CI | Distinguish product defects from flaky tests and infrastructure failures |
| Defect triage | Establish reproducibility, severity, evidence, likely scope, and diagnostic clues |
| Release review | Explain tested evidence, known gaps, residual risk, and recommended action |
| Production learning | Investigate incidents and add regression protection at the lowest useful layer |

### Severity, priority, and business risk

These concepts are related but not interchangeable:

- **Severity** describes the effect of a defect on the system or user.
- **Priority** describes how urgently the organization intends to address it.
- **Business risk** combines possible impact with likelihood and context.

A rare data-loss defect may deserve more attention than dozens of cosmetic issues. Therefore, success cannot be measured by bug count alone.

---

## 2. Skills, levels, and professional growth

Career levels are more useful when defined by scope, independence, impact, and decision responsibility than by years of experience.

### Competency matrix

| Capability | Junior | Mid-level | Senior | Lead / Staff |
|---|---|---|---|---|
| Testing fundamentals | Applies core techniques with guidance | Works independently | Coaches others | Sets standards |
| Exploratory testing | Uses checklists and charters | Runs focused sessions | Drives risk-led exploration | Builds team practice |
| HTTP and API | Sends requests and writes basic assertions | Tests auth, errors, and schemas | Analyzes cross-service flows | Defines API-quality standards |
| SQL and data | Writes simple queries | Uses joins and validates state | Tests consistency and migration risk | Guides data strategy and privacy awareness |
| Programming | Understands syntax and functions | Writes reusable test code | Designs and refactors frameworks | Reviews architecture and portfolio choices |
| Browser and web | Uses DOM and developer tools | Inspects network and storage | Diagnoses browser and integration issues | Improves testability |
| Automation | Adds focused tests | Owns maintainable suites | Designs architecture and reduces debt | Defines the automation portfolio |
| Git | Uses branch, commit, and pull request | Resolves routine conflicts and reviews | Establishes conventions | Guides governance |
| CI/CD | Reads and runs pipelines | Adds quality checks | Optimizes gates and feedback | Defines delivery strategy |
| Performance | Understands terminology | Runs focused smoke/load tests | Models workload and analyzes results | Sets performance strategy |
| Security | Knows foundational risks | Adds safe baseline checks | Integrates risk-led testing | Partners with AppSec |
| Observability | Reads logs | Correlates events | Uses logs, metrics, and traces for diagnosis | Shapes quality observability |
| Leadership | Collaborates well | Owns a feature | Mentors and influences systems | Leads strategy and stakeholders |

### What changes at each level

**Junior Technical QA**

- writes reproducible, actionable defect reports;
- creates logical test scenarios rather than copying steps blindly;
- performs basic API and database checks;
- understands Git and CI fundamentals;
- contributes small automation changes without uncontrolled duplication.

**Mid-level Technical QA**

- owns quality for a feature or service;
- identifies risks and testability problems early;
- selects test levels intentionally;
- maintains automation and test data independently;
- communicates release risk clearly.

**Senior Technical QA**

- reasons across services, contracts, data consistency, reliability, and environments;
- diagnoses cross-system and pipeline failures;
- improves test architecture and reduces flaky-test debt;
- uses production evidence to refine strategy;
- mentors others and drives quality beyond a single feature.

**Technical QA Lead or Staff Quality Engineer**

- sets quality strategy, standards, and investment priorities;
- manages test-portfolio trade-offs and risk governance;
- aligns Engineering, Product, Security, and Operations;
- builds useful metrics and transparent release decisions;
- develops people and organizational capability.

A lead does not have to be the team's fastest automation coder. A strong lead creates a durable system for decision-making and feedback. Management is also not the only progression route: Staff or Principal Quality Engineer can be an advanced individual-contributor path.

### Core technical skills

A balanced foundation includes:

- testing and risk analysis;
- web fundamentals, HTML, DOM, and browser developer tools;
- HTTP, APIs, authentication, and common data formats;
- SQL and data consistency;
- at least one programming language;
- Git and command-line basics;
- CI/CD concepts;
- architecture fundamentals;
- logs, metrics, traces, and environments.

### Core human skills

Technical depth is not enough. High-impact QA work also requires:

- asking precise questions without creating blame;
- explaining uncertainty in language Product and leadership can use;
- negotiating test depth according to risk;
- facilitating refinement and incident learning;
- writing concise, evidence-rich reports;
- coaching teammates toward shared ownership.

### Career map

```mermaid
flowchart LR
    J["Junior QA / Tester"] --> M["Technical QA / QA Engineer"]
    M --> S["Senior Technical QA"]
    S --> L["QA / Quality Lead"]
    S --> ST["Staff / Principal Quality Engineer"]
    L --> MGR["QA Manager / Engineering Manager"]
    ST --> ARCH["Quality / Test Architecture"]
```

Growth commonly follows this sequence:

```text
Execute tests
-> design tests
-> own feature quality
-> own quality signals
-> solve cross-system problems
-> design strategy
-> influence multiple teams
```

### Compensation: how to benchmark responsibly

There is no defensible global “junior, senior, and lead salary” without country, city, work model, industry, and compensation details. The following is only a United States occupation-wide reference from [O*NET/BLS 2025 wage data](https://www.onetonline.org/link/localwages/15-1253.00):

| United States market percentile | Annual wage |
|---:|---:|
| 10th percentile | $61,440 |
| 25th percentile | $80,310 |
| Median | $104,300 |
| 75th percentile | $133,180 |
| 90th percentile | $167,010 |

These figures do **not** map directly to junior, mid, senior, or lead levels, do not represent global compensation, and do not include every form of bonus or equity.

For a local benchmark, collect several sources using:

```text
Country + City/Remote + Title + Seniority + Industry
+ Base/Bonus/Equity + Automation Depth + Specialization
```

Report ranges such as P25, P50, and P75. Treat performance, security, cloud, distributed systems, and automation engineering as possible skill premiums. Do not convert a US benchmark directly by exchange rate.

---

# Part II — Risk and Test Design

## 3. Risk-based test strategy

Testing cannot cover every possible input, state, dependency, timing, device, and user behavior. A professional strategy allocates effort according to risk.

### A practical risk model

For each important capability, ask:

1. **Impact:** What happens if it fails?
2. **Likelihood:** How plausible is the failure?
3. **Exposure:** How often or widely will users encounter it?
4. **Detectability:** Would monitoring or another control reveal it quickly?
5. **Recoverability:** Can the system or team recover safely?

Use the answers to prioritize, not to manufacture a false-precision score. A simple qualitative matrix is often enough:

| Risk | Example | Testing response |
|---|---|---|
| Critical | Payment captured twice | Multiple layers, idempotency, concurrency, observability, rollback evidence |
| High | User loses unsaved work | State transitions, interruption, recovery, compatibility, exploratory testing |
| Medium | Incorrect optional filter | Functional scenarios, boundaries, focused regression |
| Low | Minor spacing inconsistency | Visual review or opportunistic check |

### Turn requirements into testable models

Do not begin with a long list of steps. Begin with the behavior model:

- actors and permissions;
- preconditions and data states;
- business rules;
- state transitions;
- valid and invalid inputs;
- dependencies and failure modes;
- concurrency and timing;
- observability and recovery.

### Test-design techniques

**Equivalence partitioning**

Group inputs expected to behave similarly and test representatives from each meaningful group.

**Boundary-value analysis**

Test at, below, and above limits. Boundaries commonly reveal off-by-one, rounding, capacity, and validation failures.

**Decision tables**

Use a table when outcomes depend on combinations of conditions, such as discount eligibility, permissions, or shipping rules.

**State-transition testing**

Model states and allowed transitions for workflows such as account locking, order status, subscriptions, or retry logic.

**Pairwise or combinatorial selection**

Reduce large configuration matrices while still covering important interactions. Add explicit high-risk combinations even if the pairwise set does not choose them.

**Exploratory testing**

Use a time-boxed charter, notes, and evidence to investigate uncertain behavior. Exploration is disciplined learning, not random clicking.

### Worked example: login risk analysis

Suppose the product supports email/password login, optional MFA, account lockout, password reset, and several roles.

A useful model includes:

- valid and invalid credentials;
- locked, disabled, unverified, and expired accounts;
- MFA enrollment, challenge, backup codes, and recovery;
- brute-force protection and rate limits;
- session creation, rotation, timeout, and logout;
- redirect behavior and authorization after authentication;
- error-message privacy;
- audit logs and monitoring;
- accessibility of forms and errors;
- browser, mobile, and network interruption behavior.

The goal is not to produce the highest number of test cases. The goal is to expose the most important risks with efficient evidence.

### Test-strategy questions

| Area | Question to answer |
|---|---|
| Objectives | Which risks are we trying to reduce? |
| Scope | What is explicitly in and out? |
| Architecture | What are the system's main boundaries and dependencies? |
| Test levels | What belongs in unit, integration, API, contract, component, or E2E? |
| Data | How is test data created, reset, anonymized, and protected? |
| Environment | What roles do local, ephemeral, staging, and production environments play? |
| Automation | What will be automated, at what layer, and why? |
| Non-functional | When do performance, security, accessibility, and compatibility checks run? |
| CI gates | Which failures block merge or deployment? |
| Defects | How are severity, triage, RCA, and regression handled? |
| Observability | Which logs, metrics, and traces support diagnosis? |
| Exit criteria | What evidence is sufficient for a release decision? |
| Metrics | Which signals reveal feedback quality and delivery health? |

### Applied example — feature risk allocation

For a familiar feature, document five material risks before listing test cases. For each risk, identify the lowest test level that can produce useful confidence. This example shows how a strategy stays tied to decisions instead of growing from case-count targets.

---

# Part III — The Test Portfolio

## 4. Test levels and testing types

The [Microsoft architecture strategy for testing](https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/testing) distinguishes fast, isolated unit tests; broader integration tests; and slower end-to-end tests that validate complete user journeys. The practical implication is simple: do not test everything through the UI.

| Test type | Primary question | Typical ownership | Common timing | Example tools |
|---|---|---|---|---|
| Unit | Does a small unit of logic behave correctly in isolation? | Developer | Every commit | Language test framework |
| Integration | Do components, databases, queues, and services interact correctly? | Developer + QA | Pull request / CI | Test framework, containers |
| API | Is endpoint behavior, authorization, schema, and error handling correct? | Developer + QA | Pull request / CI | Code tests, Postman |
| Contract | Are consumer and provider expectations still compatible? | Developer + Technical QA | CI | Pact |
| Component | Does an isolated UI component render and behave correctly? | Developer + QA | Pull request | Cypress, framework tools |
| E2E | Does a critical user journey work across the full system? | QA + Developer | Selected CI / nightly | Playwright, Cypress, Selenium |
| Performance | Are latency, throughput, capacity, and stability acceptable under a modeled workload? | Performance / QA | Scheduled / release | k6, JMeter |
| Security | Are defined security weaknesses and abuse cases detected? | QA + AppSec | Layered | ZAP and specialist tools |
| Accessibility | Can people use the product with diverse abilities and assistive technologies? | Whole team | Design through release | Manual checks, AT, scanners |
| Exploratory | Which failures or misunderstandings exist outside scripted coverage? | Human | Feature / release | Charter and notes |
| Regression | Has previously working behavior broken? | Whole team | Multiple layers | Mixed portfolio |

Automation is not a separate test level. It is an execution method that can support unit, integration, API, contract, component, E2E, performance, and selected security checks.

### Unit testing

Unit tests are best for small, controlled logic and fast feedback. Technical QA does not have to author every unit test. QA can add value by identifying boundaries, risks, missing states, and testability gaps.

Good candidates include:

- calculations and validation rules;
- pure transformations;
- decision logic;
- parsers and formatters;
- state-machine transitions;
- permission policies expressed as code.

### Integration testing

Integration tests matter when isolated correctness is not enough. They test interactions involving databases, services, queues, file systems, configuration, or external adapters.

Look for:

- schema and migration behavior;
- transactions and rollback;
- retries, timeouts, and duplicate delivery;
- serialization and compatibility;
- authentication between services;
- dependency degradation and failure.

### API testing

A `200 OK` status does not prove an API operation is correct. Verify:

- semantics of the response body;
- authorization and tenant boundaries;
- schema and backward compatibility;
- invalid input and error contracts;
- pagination, filtering, and sorting;
- idempotency and duplicate requests;
- concurrency and eventual consistency;
- persistence and side effects;
- logs, correlation identifiers, and metrics.

### Contract testing

[Pact](https://docs.pact.io/) describes a code-first, consumer-driven approach in which consumer expectations are captured and verified against providers. Contract tests reduce a gap between isolated tests and expensive full-system E2E tests, especially when services deploy independently.

Contract tests do not replace provider functional testing. They answer a narrower question: do consumer and provider still agree on the interactions the consumer actually uses?

### Component testing

Component tests render a UI component with controlled dependencies. They are useful for states such as loading, empty, error, disabled, validation, and permission variants without paying the full setup cost of E2E.

### End-to-end testing

E2E is valuable for critical journeys such as login, signup, checkout, payment, and permission flows. It is slower and harder to diagnose than lower-level tests, so keep it focused.

> Preserve E2E for critical journeys and cross-system confidence. Test small business rules at the lowest suitable layer.

### Exploratory testing

A strong exploratory session has:

- a clear charter;
- a time box;
- relevant data and environment;
- notes about paths, observations, and questions;
- captured evidence;
- a short debrief and follow-up actions.

Example charter:

```text
Explore password-reset recovery for abuse, interruption, and privacy risks
using expired links, repeated requests, multiple devices, and role variants.
```

### Build a portfolio, not a pyramid quota

The test pyramid is a useful heuristic: many fast tests at lower levels and fewer broad-stack tests. It is not a mechanical quota. Architecture, product risk, release model, and observability should determine the actual portfolio.

---

## 5. Web, API, data, and distributed-system skills

### Web and browser knowledge

A Technical QA professional should understand:

- request/response flow;
- DOM structure and accessible names;
- cookies, local storage, and session storage;
- caching and service workers;
- network timing and failed requests;
- responsive behavior;
- browser permissions;
- console errors and source maps.

Use browser developer tools to answer specific questions, not merely to collect screenshots.

### HTTP fundamentals

Learn methods, status codes, headers, content types, caching, authentication, redirects, and idempotency. Treat conventions as context, not proof: an API can return a technically valid status code with a semantically wrong result.

### Database and data reasoning

Useful SQL skills include:

- filtering and ordering;
- joins;
- grouping and aggregation;
- null behavior;
- transaction awareness;
- comparing state before and after an operation;
- tracing foreign-key relationships;
- checking duplicate or orphan records.

Do not run destructive queries in shared or production-like environments without explicit authorization and safeguards.

### Eventual consistency

In asynchronous systems, “not visible immediately” may not mean failure. Define:

- the expected consistency window;
- retry and polling behavior;
- duplicate-event handling;
- ordering guarantees;
- dead-letter and recovery paths;
- user-visible intermediate states;
- observability for each hop.

### Idempotency example

To test a payment or order endpoint with an idempotency key:

1. Send the request once and record response and persistent effects.
2. Send the identical request with the same key.
3. Verify that no duplicate charge or order appears.
4. Confirm the response follows the documented contract.
5. Repeat concurrently to expose race conditions.
6. Inspect logs, metrics, and audit evidence.

---

# Part IV — Automation and Delivery

## 6. Automation engineering

Automation is valuable when it creates repeatable, trustworthy feedback at a sustainable cost. More scripts are not automatically better.

### What to automate

Prioritize scenarios that are:

- high-risk or business-critical;
- repeated frequently;
- deterministic enough to produce a trustworthy signal;
- expensive or error-prone to execute manually;
- stable at the chosen interface;
- diagnosable when they fail.

Keep human testing for learning, ambiguity, usability, visual nuance, and rapidly changing behavior where automation cost exceeds value.

### Select the right layer

Before adding a UI test, ask:

1. Can this rule be proven with a unit test?
2. Can service behavior be covered through an API or integration test?
3. Is a contract test the real need?
4. Does the risk require full browser and system integration?

### Maintainability principles

- Isolate tests from one another.
- Create deterministic data and reset state explicitly.
- Prefer user-facing roles and stable test attributes over fragile CSS paths.
- Use web-first assertions instead of fixed sleeps.
- Separate test intent from setup mechanics.
- Keep abstractions narrow and readable.
- Review test code like production code.
- Store useful failure artifacts: logs, traces, screenshots, requests, and responses.

[Playwright Test](https://playwright.dev/docs/intro) bundles a runner, assertions, isolation, parallel execution, and support for Chromium, WebKit, and Firefox. [Cypress](https://docs.cypress.io/app/get-started/why-cypress) supports browser-based E2E and component testing. [Selenium WebDriver](https://www.selenium.dev/documentation/webdriver/) uses the W3C WebDriver model and has a mature multi-language ecosystem. Choose according to team context, not popularity alone.

### Example: focused Playwright smoke test

```ts
import { test, expect } from "@playwright/test";

test("a signed-in user can reach the dashboard", async ({ page }) => {
  await page.goto("/login");
  await page.getByLabel("Email").fill("qa.engineer@example.test");
  await page.getByLabel("Password").fill("correct-horse-battery-staple");
  await page.getByRole("button", { name: "Sign in" }).click();

  await expect(page).toHaveURL(/\/dashboard$/);
  await expect(page.getByRole("heading", { name: "Dashboard" })).toBeVisible();
});
```

In a real suite, credentials should come from safe test configuration, not source code. The example uses fictional data only.

### Flaky-test investigation

Do not use retries merely to turn the build green. Classify the failure:

```text
Product defect
Test-code defect
Test-data collision
Environment instability
Timing or race condition
Dependency failure
Resource exhaustion
Unknown
```

Investigation sequence:

1. Preserve the failure evidence.
2. Compare local and CI environment details.
3. Identify whether the failure is deterministic under controlled repetition.
4. Check data ownership, cleanup, ordering, and parallel collisions.
5. Inspect network, console, trace, and server logs.
6. Reduce to the smallest reproducible test.
7. Fix the cause, then remove diagnostic noise.

Quarantine can be a temporary risk-control measure, but it needs an owner, reason, and expiry condition.

### Automation-health questions

- Which failures are actionable?
- Which tests duplicate coverage available at a cheaper layer?
- How much time is spent maintaining the suite?
- Can a developer reproduce a CI failure locally?
- Are retries hiding instability?
- Which critical risks have no reliable automated evidence?

---

## 7. CI/CD and quality gates

[GitHub's continuous-integration documentation](https://docs.github.com/en/actions/get-started/continuous-integration) describes workflows that build and test changes and can report results to pull requests. The platform is one implementation; the underlying design principles apply more broadly.

### Shift left, correctly understood

Shift left does not mean moving every test earlier. It means placing useful feedback at the earliest point where it is technically and economically effective.

```mermaid
flowchart TD
    A["Idea / Requirement"] --> B["Refinement"]
    B --> C["Risk and Testability Review"]
    C --> D["Development"]
    D --> U["Unit Tests"]
    U --> PR["Pull Request"]
    PR --> S["Static, Lint, and Security Checks"]
    PR --> I["Integration, API, and Contract Tests"]
    PR --> E["Critical E2E Tests"]
    S --> G{"Fast Gate"}
    I --> G
    E --> G
    G -- Fail --> F["Diagnose and Fix"]
    F --> D
    G -- Pass --> ST["Staging / Preview"]
    ST --> X["Exploratory and Targeted Regression"]
    X --> P["Targeted Performance and Security"]
    P --> R{"Release Risk Review"}
    R -- Accept --> PROD["Production"]
    R -- Not Accept --> F
    PROD --> O["Logs, Metrics, and Incidents"]
    O --> RCA["RCA and New Regression"]
    RCA --> B
```

### Multi-speed pipeline

| Trigger | Typical checks | Purpose |
|---|---|---|
| Developer local | Unit + selected integration | Immediate feedback |
| Pull request | Lint + unit + API/integration + critical E2E | Merge confidence |
| Merge to main | Broader regression | Integration confidence |
| Nightly | Broad E2E + compatibility | Wider regression detection |
| Pre-release | Exploratory + targeted performance/security | Release-risk assessment |
| Post-deploy | Smoke + synthetic checks | Production verification |

There is no universal rule that every pull-request pipeline must finish under a particular number of minutes. Establish targets from team data, developer workflow, risk, and infrastructure cost.

### A quality gate should be

- fast enough for its decision point;
- deterministic enough to trust;
- explicit about what a failure means;
- owned by a team;
- visible and diagnosable;
- proportional to the risk it controls.

### Common pipeline mistakes

- running the entire portfolio on every commit;
- allowing flaky tests to block work indefinitely;
- hiding failures behind unconditional retries;
- mixing environment outages with product-quality status;
- using one giant end-to-end suite as the only release signal;
- collecting artifacts that nobody can interpret;
- leaving failed gates without an owner.

---

# Part V — Non-Functional Quality

## 8. Performance, security, accessibility, and compatibility

### Performance testing

Performance testing is not simply “run with many users.” Begin with a model:

```text
Expected load
-> user behavior and request mix
-> data volume
-> workload shape
-> service-level objective
-> thresholds
-> observability
-> analysis and decision
```

Before selecting a tool, answer:

- What load is normal, seasonal, and exceptional?
- Which latency percentiles matter?
- What are the throughput and error-rate expectations?
- How quickly should load ramp up and down?
- What data volume and cache state are realistic?
- Which logs, metrics, and traces reveal the bottleneck?
- What is the stop condition if the environment becomes unsafe?

The [Grafana k6 load-test guide](https://grafana.com/docs/k6/latest/testing-guides/test-types/) distinguishes several workload types:

| Type | Purpose |
|---|---|
| Smoke | Validate the script and baseline behavior under minimal load |
| Average-load | Evaluate expected normal conditions |
| Stress | Explore behavior above expected average load |
| Spike | Test sudden, short, intense activity |
| Soak | Evaluate stability over an extended period |
| Breakpoint | Increase load to discover capacity limits |

The correct size is specific to the system. A stress test for one product can be an average-load test for another.

### Security testing

Security testing must have authorization, a defined scope, and a suitable environment. The [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/) covers authentication, authorization, session management, input validation, cryptography, business logic, client-side behavior, and other web risks.

A Technical QA professional can contribute by:

- turning security requirements and abuse cases into tests;
- checking authorization boundaries and sensitive-data exposure;
- adding safe baseline checks to CI;
- verifying security fixes and regression coverage;
- improving testability and audit evidence;
- collaborating with AppSec and specialist penetration testers.

Technical QA does not replace a specialist penetration tester. Automated scanning also does not prove security. [ZAP's Automation Framework](https://www.zaproxy.org/docs/automate/automation-framework/) can support structured, authorized checks, but findings still require scope control and expert interpretation.

### Accessibility testing

Target [WCAG 2.2](https://www.w3.org/TR/WCAG22/) where relevant. Automated scanners find only part of the problem. Combine automation with keyboard testing, screen-reader checks, zoom and reflow testing, and human judgment.

Core checks include:

- semantic headings and landmarks;
- accessible names and labels;
- complete keyboard operation;
- visible, unobscured focus;
- meaningful error messages;
- text and non-text contrast;
- reflow at narrow widths and zoom;
- sufficient target size;
- alternatives for non-text content;
- motion that respects user preferences;
- meaning that does not depend on color alone.

### Mobile and compatibility testing

Build a risk-led matrix using:

- usage analytics and supported-market data;
- browser and operating-system versions;
- viewport and input modes;
- network quality and interruption;
- permissions and notifications;
- install, update, background, and resume behavior;
- device resources and battery constraints;
- locale, time zone, and date formats.

Do not multiply every dimension mechanically. Select representative combinations and explicitly add high-risk cases.

---

# Part VI — Evidence and Decision-Making

## 9. Defects, observability, and release decisions

### Actionable defect reports

A useful report helps another person understand and act. Include:

- concise title;
- environment and build;
- preconditions and relevant data;
- reproducible steps or event sequence;
- expected and actual behavior;
- impact, severity, and evidence;
- frequency and known scope;
- logs, requests, screenshots, video, or trace identifiers as useful;
- possible workarounds;
- links to requirement, test, incident, or related defect.

Avoid speculation presented as fact. Label hypotheses clearly.

### Observability for QA

Observability is the ability to understand system behavior through evidence such as logs, metrics, and traces.

**Logs** answer detailed event questions. They should include timestamps, severity, context, and safe identifiers without leaking secrets.

**Metrics** reveal trends and aggregates such as latency, errors, saturation, queue depth, or retries.

**Traces** connect activity across distributed components and help locate where time or failure occurs.

Technical QA should ask for diagnostic support during design, not only after a failure becomes difficult to reproduce.

### Release evidence

A release summary should state:

- scope and version;
- environments and data used;
- completed testing and important results;
- critical-path coverage;
- known defects and accepted risks;
- untested or partially tested areas;
- automation or environment limitations;
- performance, security, and accessibility evidence;
- production monitoring and rollback readiness;
- recommendation and decision owner.

“All tests passed” is not a complete release statement. It says nothing about missing coverage, environment mismatch, flaky signals, or known defects.

### Root-cause learning

After an escaped defect or incident:

1. Reconstruct the facts and timeline.
2. Separate triggering event from systemic contributors.
3. Identify why existing controls did not prevent or detect it.
4. Add protection at the lowest useful layer.
5. Improve requirements, testability, monitoring, data, or process as appropriate.
6. Assign actions and verify they are completed.

The goal is learning and prevention, not blame.

---

## 10. Metrics and KPIs

QA metrics should illuminate delivery-system health and feedback quality, not create individual productivity theater.

The current [DORA software delivery performance model](https://dora.dev/guides/dora-metrics/) uses five metrics grouped into throughput and instability:

- change lead time;
- deployment frequency;
- failed deployment recovery time;
- change fail rate;
- deployment rework rate.

DORA recommends applying these in the context of an application or service and examining improvement over time. Do not use them to rank individual QA engineers.

### Useful quality signals

| Signal | Practical definition | Useful for | Misuse risk |
|---|---|---|---|
| Production escaped defects | Confirmed defects found after release | Finding strategy gaps | Counting without severity or exposure |
| Critical-flow coverage | High-risk flows with suitable evidence | Connecting tests to business risk | Turning coverage into a blind quota |
| Feedback lead time | Change to actionable test result | Improving feedback speed | Sacrificing depth for speed |
| Flaky-test rate | Share of non-deterministic failures | Automation health | Hiding failure with retries |
| Pipeline-signal reliability | Trustworthiness of quality gates | CI confidence | Deleting valuable tests to improve the number |
| Defect triage time | Failure to useful classification | Diagnosis speed | Closing tickets artificially |
| Automation maintenance cost | Maintenance effort relative to value | Investment decisions | Measuring test count only |
| Change fail rate | Deployments requiring intervention | Delivery quality | Assigning blame to one role |
| Recovery time | Time to recover from failed deployment | Resilience | Treating it as an individual KPI |
| Deployment rework | Unplanned deployment work after an incident | Reducing rework | Creating a blame culture |

### Poor individual targets

Avoid targets such as:

- number of test cases written;
- number of bugs found;
- number of tests executed;
- automation percentage at any cost;
- pass rate without context.

These measures ignore risk, severity, duplication, maintenance, and value. A smaller, reliable portfolio can be more useful than a large, noisy one.

---

# Part VII — Tools, Hiring, and Practice

## 11. Selecting tools

No professional tool table should contain a universal “best tool” column. Choose based on team language, architecture, browser matrix, CI environment, maintainability, debugging needs, licensing, execution time, skills, and system testability.

| Tool | Primary use | Notable fit | Selection consideration |
|---|---|---|---|
| [Playwright](https://playwright.dev/docs/intro) | Web E2E | Modern cross-browser testing with integrated runner | Strong choice for many new web stacks; assess team fit |
| [Cypress](https://docs.cypress.io/app/get-started/why-cypress) | E2E and component | Browser-based developer workflow and component testing | Particularly attractive for frontend collaboration |
| [Selenium](https://www.selenium.dev/documentation/webdriver/) | Browser automation | Mature ecosystem, language choice, Grid | Useful when ecosystem breadth and existing investment matter |
| Appium | Mobile UI automation | Native, hybrid, and mobile-web application testing | Confirm device-lab strategy and platform-specific maintenance cost |
| [Postman CLI](https://learning.postman.com/docs/tests-and-scripts/postman-cli-guides/overview/) | API testing | Collections and CI execution | Useful for collaborative API workflows; manage assets as code |
| Insomnia | API exploration | Request design, environment variables, and debugging | Useful for interactive investigation; keep shared assets reviewable |
| REST Assured | Java API automation | Code-first HTTP assertions in JVM projects | Strong fit when Java already owns the test stack |
| [Pact](https://docs.pact.io/) | Contract testing | Consumer-driven compatibility | Best suited to independently evolving services and APIs |
| [k6](https://grafana.com/docs/k6/latest/testing-guides/test-types/) | Performance and load | Scripted, automation-friendly workloads | Requires a realistic workload model and observability |
| JMeter | Load and protocol testing | Mature Java ecosystem | Evaluate maintainability and team expertise |
| Gatling | Performance and load | Code-based scenarios and detailed reporting | Evaluate language fit, workload realism, and pipeline cost |
| [ZAP](https://www.zaproxy.org/docs/automate/automation-framework/) | Web security checks | Automation Framework and baseline scanning | Use only with authorization, scope, and review |
| [GitHub Actions](https://docs.github.com/en/actions/get-started/continuous-integration) | CI/CD | Repository-integrated workflows | Natural when source is already hosted on GitHub |
| GitLab CI, Jenkins, Azure DevOps, TeamCity | CI/CD | Build orchestration, gates, agents, and artifacts | Choose from repository ownership, hosting, plugins, and operations capability |
| pytest, NUnit, JUnit, xUnit | Code-level testing | Language-native unit and integration suites | Keep fixtures isolated and align with the production ecosystem |
| Unity Test Framework | Unity edit-mode and play-mode testing | Engine-aware automated checks | Separate fast deterministic logic tests from lifecycle-dependent play-mode checks |
| Chrome DevTools, Visual Studio, Rider | Debugging and profiling | Network, source, stack, performance, and runtime inspection | Evidence quality matters more than the preferred interface |
| Grafana, Prometheus, Sentry, Datadog | Monitoring and observability | Metrics, dashboards, errors, traces, and alerts | Define ownership, retention, privacy, and actionable signals |
| Git, GitHub, GitLab, Plastic SCM | Version control and collaboration | History, branches, reviews, and change traceability | QA should be able to inspect and contribute without bypassing ownership rules |
| TestRail or similar | Test management | Cases, suites, runs, and traceability | Useful when governance needs justify maintenance cost |
| Jira, Zephyr, Xray, or similar | Work and test management | Defects, cases, runs, and traceability | These systems organize evidence; they do not create test quality by themselves |

### Tool decision worksheet

Score candidates against real needs:

```text
Supported interfaces and platforms
Team language and skill
Debugging quality
Isolation and parallel execution
CI integration
Reporting and artifacts
Test-data support
Maintenance cost
Licensing and hosting
Security and privacy
Migration risk
```

Run a small proof of concept with representative difficult scenarios before standardizing a tool.

---

## 12. Job descriptions and hiring

### Junior Technical QA — sample role

**Mission:** Help the product team identify risk and create reliable feedback about feature quality.

**Responsibilities:** Analyze acceptance criteria, design scenarios, run exploratory/API/database testing, record reproducible defects, maintain existing automation, use Git and CI, and contribute to regression.

**Essential knowledge:** Testing fundamentals, basic HTTP/API and SQL, Git, one scripting or programming language at beginner level, and clear communication.

**Success evidence:** Increasing independence, high-quality defect reports, reduced low-value manual repetition, and maintainable automation contributions.

### Senior Technical QA — sample role

**Mission:** Own quality engineering for a domain and reduce release risk through suitable test strategy and automation.

**Responsibilities:** Risk analysis, test-level selection, automation architecture, integration/API/E2E strategy, pipeline diagnosis, test data and environments, performance/security coordination, mentoring, and production-defect review.

**Essential knowledge:** Programming, architecture fundamentals, CI/CD, APIs, databases, automation design, and layered troubleshooting.

**Success evidence:** Faster and more trustworthy feedback, fewer escaped high-risk defects, lower flakiness, and stronger team independence.

### Technical QA Lead — sample role

**Mission:** Build a measurable, sustainable quality system across one or more teams.

**Responsibilities:** Quality strategy, risk governance, test portfolio, standards, metrics, automation strategy, hiring, mentoring, cross-functional alignment, and transparent release-risk reporting.

**Success evidence:** Health of the delivery system—not the number of bugs or test cases produced.

Adapt each description to the product domain, architecture, technology stack, deployment model, team topology, and expected seniority.

---

## 13. Interview preparation

A strong interview evaluates reasoning, evidence, and communication—not memorized definitions alone.

| Question | What it evaluates |
|---|---|
| How would you create a test strategy for login? | Risk decomposition |
| What is the difference between unit, integration, and E2E, and where would you test a validation rule? | Test-level judgment |
| A test fails only occasionally in CI. Where do you begin? | Flakiness investigation |
| An API returns `200`. Is that enough to pass? | Semantic API reasoning |
| How would you verify data integrity in a multi-table operation? | SQL and data reasoning |
| Why is 100% automation coverage not automatically a good objective? | ROI and risk thinking |
| A UI selector breaks repeatedly. What do you change? | Maintainability and testability |
| What problem does contract testing solve? | Distributed-system knowledge |
| How would you design a checkout load test? | Workload modeling |
| Which security checks might run in CI? | Security maturity |
| A release contains a known defect. Ship or stop? | Risk communication |
| A suite grew from 20 to 90 minutes. What do you do? | Architecture and optimization |
| How should a production bug change test strategy? | Continuous learning |
| A developer disagrees with your severity rating. What do you do? | Collaboration |
| How would you establish an automation strategy for a team with none? | Senior/lead strategy |

### Practical interview assessment

Give the candidate a short fictional feature, its API contract, and two production incidents. Ask for:

1. Top risks;
2. Test-level allocation;
3. Five high-value scenarios;
4. One automation example;
5. Release evidence;
6. Questions they would ask the team.

Score reasoning, prioritization, communication, and awareness of uncertainty. Do not reward sheer test-case volume.

---

## 14. Onboarding a Technical QA professional

Good onboarding connects a new teammate to architecture, risk, and the feedback system rather than handing them a folder of test cases.

| Suggested period | Outcome |
|---|---|
| First days | Access, product context, architecture map, local setup, CI, glossary |
| First weeks | Run suites, reproduce defects, explore APIs, logs, and data |
| By end of month one | First automation contribution and ownership of a small feature |
| Month two | Own quality for a feature/service; analyze a flaky suite or data issue |
| Month three | Propose a measurable improvement to strategy, pipeline, or automation |

### Operational onboarding flow

```mermaid
flowchart LR
    A["Access and product context"] --> B["Observe architecture and delivery workflows"]
    B --> C["Contribute test evidence and automation"]
    C --> D["Own quality for a bounded feature or service"]
    D --> E["Improve strategy, diagnostics, or delivery feedback"]
```

Onboarding should cover access, architecture, dependency maps, environments, seed data, secret handling, CI, observability, regression suites, incident examples, definition of done, release process, severity model, security contacts, performance expectations, and automation ownership.

---

# Part VIII — Applied Technical QA in Real Engineering

## Organizational shape, cadence, and collaboration

The Technical QA title changes with organizational scale:

| Context | Typical shape | Main opportunity | Main risk |
|---|---|---|---|
| Startup | One QA professional covers exploration, release checks, lightweight automation, support feedback, and process design | Build fast feedback into the product early | Becoming the final manual gate for every change |
| Mid-sized company | QA is embedded in product teams with shared automation, environments, and release practices | Own feature or service quality end to end | Fragmented standards and duplicated frameworks |
| Large organization | Specialized roles may cover SDET, performance, security, release, platform, and test architecture | Deep expertise and scalable quality platforms | Handoffs, slow governance, and unclear local ownership |

### Work cadence

| Cadence | Typical Technical QA work | Expected evidence |
|---|---|---|
| Daily | Review CI failures, refine risk, test active changes, inspect logs/API/data, pair on defects, maintain focused automation | Classified failures, updated defects, new observations |
| Weekly | Analyze escaped defects and flakes, review environment health, improve suites, discuss quality signals | Trend notes, maintenance decisions, risk changes |
| Per sprint | Refine acceptance criteria, plan coverage, test throughout development, support review and demos, contribute to retrospective | Sprint risk map, coverage notes, actionable learning |
| Before release | Execute risk-based regression, validate packaging and configuration, review non-functional evidence, confirm monitoring and rollback | Release summary with residual risk and recommendation |
| After release | Run production smoke checks, watch signals, compare expected behavior, triage incidents, add prevention | Production verification and closed-loop follow-up |

### Healthy QA and developer boundaries

Technical QA should read source code when it shortens investigation, review code for testability or risk, and write automation or diagnostic tooling. It may propose production fixes, but the production-code owner normally implements and approves them. This separation preserves accountability without creating an artificial wall.

| Activity | Healthy Technical QA contribution | Primary ownership |
|---|---|---|
| Read code | Trace behavior, state, dependencies, and test seams | Shared capability |
| Write test code | Build maintainable test infrastructure and checks | QA or shared platform owner |
| Debug production code | Reproduce, isolate, gather evidence, form a testable hypothesis | Shared investigation |
| Modify production code | Only under the team's normal engineering review and ownership model | Product engineering owner |
| Review architecture | Surface testability, operability, failure modes, and release risk | Architect and engineering team |
| Participate in code review | Review risk, observability, contracts, and tests when useful | Shared review process |

### A realistic working day

```text
09:00  Review CI failures and overnight production signals
09:30  Daily stand-up; state risk, evidence, and blockers
10:00  Reproduce a reported regression
11:00  Inspect logs, requests, responses, data, and state transitions
12:00  Pair with the developer to isolate the failing code path
13:00  Test a new feature against its highest risks
14:00  Implement or refactor focused automation
15:00  Execute targeted regression and compatibility checks
16:00  Investigate a performance or reliability signal
17:00  Update defect evidence, test status, and release risk
```

The mix changes by phase. Discovery emphasizes ambiguity and testability; active development emphasizes fast feedback and investigation; stabilization emphasizes regression, performance, compatibility, and release evidence; operations emphasizes monitoring, incident learning, and prevention.

### Collaboration map

| Partner | Information QA provides | Information QA needs |
|---|---|---|
| Product / Game Design | User-impact risks, ambiguous behavior, scenario evidence | Intended outcomes, priority, economy and progression rules |
| Developers / Tech Leads | Reproduction, diagnostics, affected scope, regression probes | Architecture, change intent, known constraints, debug hooks |
| Architecture | Failure modes, testability gaps, dependency risk | Boundaries, contracts, state ownership, resilience decisions |
| DevOps / Release | Gate results, environment findings, smoke evidence | Deployment topology, configuration, rollback, infrastructure changes |
| Security | Abuse cases, baseline checks, verified fixes | Authorized scope, threat model, specialist assessment |
| Support / Operations | Reproduction guidance and known impact | Real user symptoms, frequency, device, region, and timing |

## Debugging and root-cause analysis

A professional investigation preserves evidence before changing the system:

```text
Reproduce
-> verify environment and build
-> preserve logs and stack traces
-> inspect network and external dependencies
-> inspect application and database state
-> trace the relevant code path
-> compare timing, configuration, and lifecycle
-> reduce the failing case
-> form and falsify a root-cause hypothesis
-> collaborate with the owning developer
-> verify the fix
-> run focused regression
-> improve prevention or observability
```

| Term | Meaning | Example |
|---|---|---|
| Symptom | Observable incorrect behavior | A saved game opens with zero currency |
| Trigger | Event or condition that exposes the problem | Resume after the OS terminated the process |
| Root cause | Underlying defect that makes the failure possible | Non-atomic persistence writes leave mixed schema versions |
| Regression | Previously working behavior broken by a change | Refactor bypasses the migration path |
| Side effect | Additional behavior caused by the same defect or fix | Recovery logic duplicates an inventory item |

### Scenario playbooks

**Feature fails after reopening.** Compare in-memory and persisted state, lifecycle callbacks, serialization versions, asynchronous write completion, timestamps, and restore ordering. Test normal close, forced termination, background/resume, update migration, and low-storage conditions.

**A refactor improves performance but breaks another system.** Establish a before/after baseline, identify changed ownership and event order, run affected contract and state-transition tests, inspect pooled-object reset behavior, and add a regression at the lowest stable layer.

**An API occasionally returns invalid data.** Capture correlation IDs and raw responses, group failures by node, deployment, input, time, and dependency, validate schemas and invariants, inspect retries and caches, and distinguish producer corruption from client deserialization.

**A game fails only on one device.** Record device, OS, GPU, memory, resolution, thermal state, locale, permissions, network, and lifecycle. Compare player logs, frame timing, memory pressure, graphics settings, and device-specific platform code.

**Save/load corrupts gameplay state.** Define invariants across inventory, progression, economy, quests, and versioning. Test atomicity, rollback, duplicate requests, partial writes, concurrent updates, migration, tampering, and recovery from invalid data.

## Technical QA for game development and Unity

Game QA combines normal software-quality practice with frame-based execution, content pipelines, device variability, long-lived state, economy, and application lifecycle. The [Unity event-function execution-order documentation](https://docs.unity3d.com/6000.0/Documentation/Manual/execution-order.html) is essential because defects often depend on initialization, enable/disable, frame update, physics, rendering, pause, and destruction order.

### Knowledge map

| Area | What Technical QA should understand | High-value probes |
|---|---|---|
| Scenes and lifecycle | Scene loading, additive scenes, MonoBehaviour callbacks, pause/focus, teardown | Re-entry, duplicate managers, interrupted transitions, stale listeners |
| Prefabs and ScriptableObjects | Serialized references, variants, shared configuration, asset GUIDs | Missing references, unintended shared mutation, migration and merge damage |
| Physics and animation | Fixed-step updates, collision layers, triggers, state machines, root motion | Frame-rate sensitivity, tunneling, transition interruption, disabled objects |
| UI systems | Input modes, anchors, safe areas, localization, resolution and aspect ratio | Overlap, focus order, controller/touch parity, long text and right-to-left readiness |
| Runtime assets | Direct references, bundles, Addressables, dependencies, asynchronous load/release | Missing catalog, stale cache, duplicate content, memory not released |
| Pooling | Reuse instead of destruction, enable/disable lifecycle, reset contracts | Stale state, listeners, particles, timers, ownership, disabled-but-logically-active effects |
| Save and economy | Versioned persistence, transactions, server authority, purchases, rewards | Duplication, underflow/overflow, replay, offline recovery, partial grant |
| Performance | CPU/GPU frame time, allocation, garbage collection, memory, draw cost, thermal behavior | Spikes, leaks, long sessions, low-memory recovery, device tiers |

At 60 FPS, one frame has about 16.67 ms; at 30 FPS, about 33.33 ms. Averages are insufficient: investigate spikes, percentiles, thread waits, GPU/CPU bounds, allocations, and device conditions.

### Game-specific risk portfolio

- **Gameplay:** controls, rules, combat, collisions, timing, camera, AI, pause, and restart.
- **Progression and economy:** unlocks, rewards, currency, upgrades, offers, time gates, and configuration changes.
- **Persistence:** save/load, migrations, cloud/local conflict, corrupted data, and account switching.
- **Monetization:** ads, in-app purchases, receipt handling, duplicate callbacks, restoration, cancellation, and offline paths.
- **Content:** scenes, prefabs, Addressables, localization, tutorials, remote configuration, and asset compatibility.
- **Platform:** devices, resolutions, safe areas, permissions, lifecycle, network transitions, storage, and thermal pressure.
- **Reliability:** long sessions, repeated scene changes, pooling churn, background/resume, reconnect, and low-memory events.

### Detecting regressions after large refactors

1. Freeze observable behavior and performance baselines before the refactor.
2. Map changed owners, lifecycle order, events, data contracts, serialized assets, and migration paths.
3. Select invariants that must remain true across gameplay, persistence, economy, and content.
4. Run fast deterministic tests first, then play-mode, device, long-session, and migration scenarios.
5. Compare logs, frame timing, allocations, state snapshots, and content manifests before and after.
6. Add the smallest stable regression check at the defect's true ownership boundary.

## Practical portfolio projects

| Project | Deliverable | What it demonstrates |
|---|---|---|
| API automation framework | Contract, negative, auth, idempotency, and CI checks | HTTP reasoning, code structure, data control, diagnostics |
| Web E2E framework | Focused critical flows with traces and stable selectors | UI automation judgment and maintainability |
| Unity automated QA framework | Edit-mode logic, play-mode lifecycle, and reportable scenarios | Engine knowledge, deterministic design, failure evidence |
| Performance project | Workload model, thresholds, dashboards, and analysis | Capacity reasoning and observability |
| CI-integrated regression suite | Multi-speed pipeline with artifacts and quarantine policy | Delivery engineering and signal reliability |
| Save/load validation system | Invariants, migrations, corruption, recovery, and state diffs | Persistence and data-integrity testing |
| Automated gameplay scenario runner | Repeatable input, checkpoints, assertions, and captures | Game-system automation and debugging |
| Device compatibility framework | Device matrix, lifecycle, performance, and result normalization | Mobile risk strategy and scalable evidence |

## Research coverage map

The supplied PDF is a requirements brief rather than a finished research report. This guide and its companion visual atlas cover every requested area:

| PDF topic | Where it is covered |
|---|---|
| 1. What is Technical QA? | Part I: definitions and role boundaries |
| 2. Role and responsibilities | Foundations, cadence, collaboration, release evidence |
| 3. Technical knowledge | Skills matrix, HTTP, SQL, programming, command line |
| 4. Software engineering knowledge | Architecture, contracts, state, automation design |
| 5. Testing knowledge | Part III test portfolio and non-functional quality |
| 6. Test automation | Automation engineering and framework health |
| 7. API testing | HTTP, contracts, auth, retries, idempotency |
| 8. Database testing | SQL, transactions, integrity, concurrency, migrations |
| 9. Performance engineering | Workload models, percentiles, resources, frame budgets |
| 10. Debugging and RCA | Investigation workflow and scenario playbooks |
| 11. Bug reporting | Evidence anatomy and reusable defect template |
| 12. CI/CD | Multi-speed pipeline and quality gates |
| 13. Collaboration | Partner exchange map |
| 14. Agile development | Lifecycle, shift-left/right, sprint cadence |
| 15. Tools | Tool-selection table and proof-of-concept worksheet |
| 16. Game development | Dedicated Unity and game QA section |
| 17. QA vs developer | Healthy ownership-boundary table |
| 18. Typical working day | Applied daily schedule |
| 19. Real-world scenarios | Five investigation playbooks |
| 20. Metrics and KPIs | Part VI signals and misuse guardrails |
| 21. Career levels | Competency matrix and career ladder |
| 22. Interview preparation | Questions, assessment scenario, and scorecard |
| 23. Capability development | Technical dependencies and competency levels presented as reference material rather than a time-based sequence |
| 24. Practical projects | Eight employer-visible portfolio projects |
| 25. Competency map | Skills matrix from junior through lead |

---

# Part IX — Reference Templates

## 15. Test strategy template

```markdown
# Test Strategy — [Product / Release]

## 1. Purpose and decision
- Decision this strategy supports:
- Stakeholders:
- Release or review date:

## 2. Product context
- User value:
- Architecture and dependencies:
- Compliance or safety constraints:

## 3. Risks
| Risk | Impact | Likelihood | Evidence needed | Owner |
|---|---|---|---|---|

## 4. Scope
- In scope:
- Out of scope:
- Assumptions:

## 5. Test portfolio
| Risk / behavior | Unit | Integration | API / Contract | E2E | Human |
|---|---|---|---|---|---|

## 6. Data and environments
- Data creation and reset:
- Privacy and secrets:
- Environment roles and known differences:

## 7. Non-functional work
- Performance:
- Security:
- Accessibility:
- Compatibility:

## 8. CI and execution
- Pull-request gates:
- Scheduled suites:
- Failure ownership:
- Artifacts:

## 9. Entry and exit criteria
- Entry:
- Exit:
- Accepted residual risks:

## 10. Reporting
- Metrics:
- Release summary owner:
- Decision forum:
```

## 16. Defect report template

```markdown
# [Concise observed problem]

## Environment
- Build / commit:
- Platform / browser / device:
- Account / role / data:

## Preconditions

## Reproduction
1.
2.
3.

## Expected

## Actual

## Impact and scope
- Severity:
- Frequency:
- Affected users or flows:
- Workaround:

## Evidence
- Request / response:
- Log / trace ID:
- Screenshot / recording:

## Notes
- Confirmed facts:
- Hypotheses:
- Related requirement / test / incident:
```

## 17. Risk register template

| ID | Risk | Impact | Likelihood | Exposure | Detectability | Mitigation / evidence | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| R-01 |  |  |  |  |  |  |  |  |

## 18. Release summary template

```markdown
# Quality and Release Summary — [Version]

## Recommendation
- Recommend: Ship / Ship with conditions / Hold
- Decision owner:

## Scope and evidence
- Build and environment:
- Critical paths tested:
- Automated suites:
- Exploratory work:
- Performance / security / accessibility:

## Results
- Passed evidence:
- Failed or inconclusive evidence:
- Environment or tooling limitations:

## Known risk
| Risk / defect | User impact | Mitigation | Owner | Acceptance |
|---|---|---|---|---|

## Not tested or partially tested

## Production readiness
- Monitoring:
- Alerting:
- Rollback:
- Post-deploy checks:
```

## 19. Exploratory session template

```markdown
# Exploratory Session

- Charter:
- Time box:
- Tester:
- Build / environment:
- Data:

## Coverage notes

## Observations and questions

## Defects / risks

## Evidence

## Debrief and follow-up
```

## 20. Interview scorecard template

| Dimension | 1 — Needs support | 2 — Developing | 3 — Independent | 4 — Advanced | Evidence |
|---|---|---|---|---|---|
| Risk analysis |  |  |  |  |  |
| Test-level judgment |  |  |  |  |  |
| Technical investigation |  |  |  |  |  |
| Automation design |  |  |  |  |  |
| Communication |  |  |  |  |  |
| Seniority-specific scope |  |  |  |  |  |

---

# Part X — Publishing and Maintenance

## 21. Single source of truth

Maintain canonical content once, then derive other formats:

```text
Canonical Markdown
      |----> Documentation website
      |----> DOCX
      |----> PDF
```

This reduces drift between independently edited versions. The current deliverables use this English reference as the canonical source for the website's documentation structure.

### Optional document conversion

[Pandoc](https://pandoc.org/getting-started.html) can convert Markdown into HTML, DOCX, and PDF formats.

```bash
pandoc Technical-QA-Educational-Guide.md --toc -o Technical-QA-Educational-Guide.docx
```

For professional Word styling, use a tested reference document:

```bash
pandoc Technical-QA-Educational-Guide.md \
  --toc \
  --reference-doc=reference.docx \
  -o Technical-QA-Educational-Guide.docx
```

Always inspect generated documents visually. A successful command proves file generation, not layout quality.

### Document QA checklist

- heading hierarchy and table of contents;
- readable tables and code blocks;
- correct page breaks;
- working links;
- diagram rendering;
- accessible reading order where supported;
- reliable fonts and fallback behavior;
- print margins, headers, footers, and page numbers.

---

# Glossary

| Term | Practical meaning |
|---|---|
| Quality Assurance | Preventive, process-oriented work that supports quality |
| Quality Engineering | Engineering practices that build quality feedback into delivery |
| Software Testing | Activities used to evaluate software and reveal risk |
| Test Case | A defined condition, action, and expected result used to evaluate behavior |
| Test Strategy | The risk-led plan for obtaining useful quality evidence |
| Testability | How easily a system can be controlled, observed, and evaluated |
| Defect / Bug | A flaw or mismatch between required and actual behavior |
| Severity | Degree of impact caused by a defect |
| Priority | Urgency assigned to addressing work |
| Regression | Previously working behavior that has broken |
| Exploratory Testing | Simultaneous learning, test design, and execution guided by a charter |
| Unit Test | Test of a small unit of logic, usually in isolation |
| Integration Test | Test of interaction between components or dependencies |
| Contract Test | Test that checks compatibility between a consumer and provider |
| End-to-End Test | Test of a complete user journey across the system |
| Load Test | Performance test under a modeled level of activity |
| Stress Test | Test above expected load to explore limits and failure behavior |
| Soak Test | Long-running test for stability and resource issues |
| Flaky Test | A test that produces inconsistent results without a relevant product change |
| Quality Gate | A defined check that controls progression through delivery |
| Shift Left | Moving useful feedback to an earlier effective point in the lifecycle |
| Observability | Understanding system behavior from logs, metrics, traces, and related evidence |
| Test Data | Data prepared or selected for testing |
| Test Environment | The system configuration in which testing occurs |
| Release Risk | Residual possibility and impact of failure associated with a release |

---

# Primary references

The original report drew from official and primary documentation. These links replace its interface-specific citation markers:

1. [ISTQB Certified Tester Foundation Level v4.0](https://www.istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/)
2. [Microsoft — Architecture strategies for testing](https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/testing)
3. [O*NET — Software Quality Assurance Analysts and Testers](https://www.onetonline.org/link/summary/15-1253.00)
4. [O*NET/BLS — United States wage data for Software QA Analysts and Testers](https://www.onetonline.org/link/localwages/15-1253.00)
5. [DORA — Software delivery performance metrics](https://dora.dev/guides/dora-metrics/)
6. [GitHub Docs — Continuous integration](https://docs.github.com/en/actions/get-started/continuous-integration)
7. [Playwright documentation](https://playwright.dev/docs/intro)
8. [Cypress documentation](https://docs.cypress.io/app/get-started/why-cypress)
9. [Selenium WebDriver documentation](https://www.selenium.dev/documentation/webdriver/)
10. [Postman CLI testing guide](https://learning.postman.com/docs/tests-and-scripts/postman-cli-guides/overview/)
11. [Pact documentation](https://docs.pact.io/)
12. [Grafana k6 — Load test types](https://grafana.com/docs/k6/latest/testing-guides/test-types/)
13. [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
14. [ZAP Automation Framework](https://www.zaproxy.org/docs/automate/automation-framework/)
15. [W3C Web Content Accessibility Guidelines 2.2](https://www.w3.org/TR/WCAG22/)
16. [Pandoc — Getting started](https://pandoc.org/getting-started.html)
17. [Unity 6 Manual — Event function execution order](https://docs.unity3d.com/6000.0/Documentation/Manual/execution-order.html)
18. [Unity Test Framework documentation](https://docs.unity3d.com/Packages/com.unity.test-framework@1.4/manual/index.html)
19. [Unity 6 Manual — Runtime asset management](https://docs.unity3d.com/6000.0/Documentation/Manual/assets-managing-introduction.html)
20. [Unity 6 Manual — Frame timing counters](https://docs.unity3d.com/6000.0/Documentation/Manual/frame-timing-manager-counter-reference.html)
21. [Unity Memory Profiler documentation](https://docs.unity3d.com/Packages/com.unity.memoryprofiler@1.1/manual/index.html)

## Final principle

Technical QA transforms testing from a late-stage checkpoint into an engineering system for feedback and quality-risk management across the lifecycle. The practical consequences are consistent:

- use the fastest suitable test level;
- keep E2E limited and valuable;
- model performance and security work from real risk;
- build reliable CI signals;
- connect production evidence back to prevention and regression;
- measure delivery systems rather than individual activity;
- define career growth by scope, independence, and impact.