Exploration, release checks, lightweight automation, support feedback, and process design often sit with one person.
A practical engineering reference
Understand Technical QA as an engineering discipline.
Read what Technical QA is, how it works across delivery, which responsibilities it owns, and how technical evidence supports responsible release decisions.
- 10documentation sections
- 25research topics
- 10official resource links
- 11visual models
The quality feedback loop
01Understand riskProduct, user, architecture
02Choose evidenceHuman + automated layers
03Shorten feedbackCI, diagnostics, ownership
04Learn in productionSignals back into strategy
How to use this reference
Navigate by responsibility, workflow, or risk.
- DefinitionEstablish the role
- ResponsibilityClarify ownership
- WorkflowFollow the evidence
- ApplicationUse scenarios and examples
Use the section navigation for a complete reading path or search for a specific responsibility. Testing judgment, HTTP, SQL, code, automation, and communication appear together because the role applies them as one quality system.
What Technical QA actually owns
Move from “checking at the end” to engineering quality feedback throughout delivery.
What this section documents
- Distinguish QA, testing, Quality Control, and Quality Engineering.
- Explain whole-team quality ownership.
- Separate severity, priority, and business risk.
A working definition
Technical QA combines testing judgment, risk analysis, technical knowledge, observability, targeted human testing, and maintainable automation across the SDLC.
“Technical QA” is a spectrum rather than a universally standardized title. Companies distribute similar work across QA Engineer, Quality Engineer, Automation Engineer, SDET, and Technical Test Analyst roles. Responsibility is more important than the label.
| Moment | Useful contribution | Evidence created |
|---|---|---|
| Refinement | Challenge ambiguity, edge cases, and testability | Clearer criteria and risk notes |
| Development | Design layered tests and diagnostic support | Test portfolio and observability |
| CI | Classify product, test, data, and environment failures | Actionable quality signal |
| Release | Explain evidence, gaps, and residual risk | Decision-ready summary |
| Production | Turn incidents into prevention and regression | Closed evidence loop |
How the role changes with company size
Embedded QA owns risk across a feature or service while sharing frameworks, environments, and release practices.
SDET, performance, security, platform, and release specialists need explicit interfaces and local quality ownership.
Work cadence
Daily
Classify CI, test active changes, inspect evidence, pair on defects.
Weekly
Review escapes, flakes, environments, suite health, and risk changes.
Per sprint
Refine, plan coverage, test continuously, review, and improve.
Release
Validate high risk, package evidence, state gaps, monitor, and verify.
SeverityHow much damage?
PriorityHow urgently will we act?
RiskImpact × likelihood × context
Risk analysis and test design
Choose coverage from impact and uncertainty—not from a target number of test cases.
What this section documents
- Build a feature risk model before writing steps.
- Use boundaries, partitions, decisions, states, and exploration.
- Allocate evidence according to impact and likelihood.
Lower likelihoodHigher likelihood
ObserveLow impact, low likelihood
TargetLow impact, high likelihood
ProtectHigh impact, low likelihood
Prove + monitorHigh impact, high likelihood
Lower impactHigher impact
Begin with a behavior model
Actors and rolesPreconditionsBusiness rulesStatesBoundariesDependenciesTimingRecovery
Equivalence partitions
Group inputs expected to behave alike; select meaningful representatives.
Boundary values
Test at, just below, and just above limits where off-by-one and rounding defects appear.
Decision tables
Expose combinations of conditions and outcomes for permissions, pricing, and business rules.
State transitions
Model allowed, forbidden, and interrupted transitions in workflows such as orders and account locks.
Exploratory charters
Use a mission, time box, notes, and debrief to investigate uncertain risk deliberately.
Combinatorial selection
Reduce a large matrix while preserving important interactions and explicit high-risk combinations.
Worked example
Login is more than valid and invalid credentials.
Model locked, disabled, unverified, and expired accounts; MFA enrollment and recovery; brute-force protection; session rotation; redirects; permissions; audit logs; network interruption; error privacy; and accessible form behavior.
Design move: cover password rules low in the stack, API authorization at the service boundary, and only the most critical journeys through the browser.
Build a test portfolio, not an E2E pile
Match each risk to the lowest layer that can produce useful confidence.
What this section documents
- Distinguish unit, integration, API, contract, component, and E2E intent.
- Explain why automation is an execution method, not a test level.
- Design a balanced portfolio around architecture and risk.
Fastest feedbackUnitRules, decisions, transformations
BoundariesIntegration + APIData, services, dependencies
CompatibilityContract + ComponentConsumer agreements, UI states
Broadest confidenceCritical E2EComplete user journeys
Human exploration crosses every layer.Use it for ambiguity, learning, usability, and unexpected failure.
| Level | Primary question | Typical use | Main trade-off |
|---|---|---|---|
| Unit | Does small logic work in isolation? | Validation, calculation, state rules | Limited integration confidence |
| Integration | Do components and dependencies cooperate? | Database, queue, adapter, transaction | More setup and runtime |
| API | Is service behavior and authorization correct? | Contracts, errors, side effects | Does not prove the full UI journey |
| Contract | Do consumer and provider still agree? | Independent service releases | Not provider functional testing |
| Component | Does a UI component handle its states? | Loading, empty, error, validation | Controlled rather than full system |
| E2E | Does the critical journey work end to end? | Login, checkout, payment, permissions | Slow, expensive, harder to diagnose |
API, data, and distributed systems
Go beyond status codes and learn to follow behavior across boundaries.
What this section documents
- Test API semantics, authorization, and side effects.
- Use SQL to validate meaningful state changes safely.
- Reason about idempotency and eventual consistency.
A `200` response is the beginning.
- Response meaning and schema
- Authentication and tenant boundary
- Invalid input and error contract
- Pagination, filters, and ordering
- Persistence and side effects
- Idempotency and concurrency
- Logs and correlation identifiers
Safe data validation
Use SQL to compare state before and after an operation, follow relationships, and look for duplicates, nulls, or orphan records. Never run destructive queries in shared or production-like environments without explicit authorization and safeguards.
Send once→Repeat same key→Send concurrently→Inspect effects→Verify evidence
Worked example
Idempotent checkout
Send a checkout request and record response plus stored effects. Repeat the identical request with the same idempotency key, then send concurrent duplicates. Verify there is one order, one charge, a documented response contract, and useful audit evidence.
Automation that remains trustworthy
Automate for repeatable value, then maintain test code as an engineering product.
What this section documents
- Select automation by risk, repetition, determinism, and cost.
- Design isolation, data, selectors, assertions, and artifacts.
- Investigate flakiness without hiding it behind retries.
Automation candidate
High risk?+
Repeated often?+
Stable interface?+
Deterministic data?+
Diagnosable failure?+
Automate when the combined value is stronger than the ongoing maintenance cost.
Isolate
Tests should own state and avoid ordering dependencies.
Control data
Seed and reset deterministically; avoid shared immortal accounts.
Use stable contracts
Prefer roles, labels, and intentional test attributes over brittle paths.
Wait for meaning
Use observable conditions and web-first assertions, not fixed sleeps.
Capture evidence
Preserve traces, logs, requests, responses, and focused visuals.
Refactor
Review test code, reduce duplication, and remove low-value coverage.
Flaky-test diagnosis
ProductTest codeDataEnvironmentTimingDependency
- PreserveKeep the original trace and context.
- ClassifySeparate product, test, data, environment, and dependency failures.
- ReproduceRepeat under controlled conditions and reduce the scenario.
- RepairFix the cause, then remove temporary diagnostics.
CI/CD and multi-speed feedback
Place each signal at the earliest point where it can drive a useful decision.
What this section documents
- Explain shift-left without moving every test into pull requests.
- Design fast, scheduled, release, and post-deploy suites.
- Define an owned and diagnosable quality gate.
01RefineRisk + testability
→
02CodeUnit + integration
→
03PR gateFast critical signal
→
04PreviewExplore + target
→
05ReleaseRisk decision
→
06LearnProduction evidence
| Trigger | Representative checks | Decision supported |
|---|---|---|
| Local | Unit + selected integration | Is the change ready to share? |
| Pull request | Lint + unit + API/integration + critical E2E | Is it safe to merge? |
| Main | Broader regression | Does integration still hold? |
| Nightly | Broad E2E + compatibility | Did wider regression appear? |
| Pre-release | Exploratory + targeted non-functional | Is residual risk acceptable? |
| Post-deploy | Smoke + synthetic checks | Did production deployment succeed? |
Useful gate=timely+trustworthy+diagnosable+owned
Performance, security, and accessibility
Model realistic risk before choosing a scanner, script, or workload.
What this section documents
- Design a performance workload from system reality.
- Define Technical QA's safe security-testing contribution.
- Combine automated and human accessibility evaluation.
Performance
Model before load.
Define expected traffic, request mix, data volume, percentiles, thresholds, ramp, observability, and a safe stop condition.
- Smoke
- Average load
- Stress
- Spike
- Soak
- Breakpoint
Security
Authorization and scope first.
Turn requirements and abuse cases into safe checks; partner with AppSec; never treat an automated scan as proof of security.
- Authentication
- Authorization
- Session
- Input
- Data exposure
- Business logic
Accessibility
Automation finds only part.
Combine semantic review, keyboard testing, screen-reader checks, zoom/reflow, contrast, targets, errors, and reduced motion.
- Perceivable
- Operable
- Understandable
- Robust
Performance questions before the tool
Expected load?Which percentile?Error threshold?Real data volume?Which bottleneck signal?
Technical QA for games and Unity
Test frame-based execution, content, persistence, devices, and economy as one connected runtime.
What this section documents
- Trace Unity lifecycle and content-loading risks.
- Build game-specific coverage for progression, economy, save/load, devices, and long sessions.
- Detect behavioral and performance regressions after large refactors.
Unity lifecycle as a test model
- 01LoadScene, content, configuration
- 02InitializeAwake, OnEnable, Start
- 03SimulateFixedUpdate and physics
- 04UpdateInput, gameplay, animation
- 05RenderCPU/GPU frame budget
- 06Pause / focusBackground and resume
- 07PersistSave, cloud, migration
- 08Disable / destroyCleanup, pools, listeners
Game-specific risk portfolio
Rules, controls, combat, camera, AI, collision, timing, pause, restart.
Unlocks, quests, tutorials, rewards, difficulty, time gates.
Currency, pricing, upgrades, offers, ads, purchases, duplicate grants.
Save/load, schema migration, cloud conflict, corruption, recovery.
Scenes, prefabs, ScriptableObjects, Addressables, localization.
Resolution, safe areas, input, OS lifecycle, permissions, storage.
Frame time, memory, allocation, thermal pressure, loading, battery.
Long sessions, repeated transitions, pooling churn, reconnect, low memory.
60 FPS target
16.67 ms One slow subsystem can consume the whole frame.30 FPS target
33.33 ms Measure spikes and percentiles, not only averages.| System | Observe | Probe |
|---|---|---|
| Scene and lifecycle | Initialization, enable/disable, focus, teardown | Re-entry, interruption, duplicate managers, stale listeners |
| Pooling | Reset contract and logical ownership | Reuse after pause, death, cancellation, and scene change |
| Save and economy | Atomicity, versioning, grants, server authority | Forced close, replay, offline recovery, partial write |
| Assets and content | Dependencies, catalog, cache, load/release | Missing content, update, stale cache, low memory |
| Performance | CPU/GPU time, allocation, memory, thermal state | Representative device tiers and long sessions |
Defects, observability, and metrics
Turn failures into actionable evidence and system learning.
What this section documents
- Write defect reports that accelerate action.
- Use logs, metrics, and traces for diagnosis.
- Select quality signals without creating KPI gaming.
LogsWhat happened?Detailed events and context
MetricsHow is behavior changing?Aggregates, trends, saturation
TracesWhere did time or failure travel?Connected distributed activity
Root-cause workflow
- Reproduce
- Verify environment
- Preserve logs and stack
- Inspect network
- Inspect data and state
- Trace code path
- Check dependencies
- Reduce the case
- Falsify hypotheses
- Collaborate with owner
- Verify fix
- Run regression
- Improve prevention
SymptomObserved incorrect behavior
TriggerCondition that exposes it
Root causeDefect that makes it possible
RegressionWorking behavior broken by change
Side effectAdditional behavior from cause or fix
An actionable defect report
Clear titleEnvironmentPreconditionsReproductionExpected vs actualImpactEvidenceFacts vs hypotheses
Release summary
- Build, scope, and environment
- Critical-path evidence
- Known defects and residual risk
- Untested or inconclusive areas
- Monitoring and rollback readiness
- Recommendation and decision owner
| Signal | Useful question | Misuse to avoid |
|---|---|---|
| Escaped high-risk defects | Where did strategy miss? | Counting without impact |
| Critical-flow evidence | Are top risks protected? | Blind coverage quota |
| Feedback lead time | How quickly does a change get an actionable result? | Sacrificing depth for speed |
| Flaky-test rate | Can we trust automation? | Hiding instability with retry |
| Pipeline reliability | Do gates represent reality? | Deleting useful tests for a better number |
Career growth, tools, and interviews
Grow through scope and impact; choose tools from context; interview for judgment.
What this section documents
- Describe junior, mid, senior, lead, and staff-level growth.
- Evaluate tools without a universal “best” ranking.
- Prepare for reasoning-based interview questions.
JuniorReliable executionLearn and contribute
MidFeature ownershipWork independently
SeniorSystem ownershipDesign and mentor
Lead / StaffOrganizational impactStrategy and standards
Execute tests → design tests → own a feature → own quality signals → solve cross-system problems → shape strategy.
Tool-selection lens
ArchitectureTeam languageDebuggingCI fitMaintenanceLicensingExecution timeTestability
Run a small proof of concept with representative difficult scenarios before standardizing. Popularity alone is not evidence of fit.
A realistic Technical QA day
- Review CI and production signals
- Reproduce and isolate a regression
- Pair with the code owner on root cause
- Test the highest-risk feature behavior
- Implement focused automation
- Investigate performance or reliability
- Update evidence and release risk
Portfolio projects that demonstrate judgment
Contracts, auth, negative cases, idempotency, diagnostics, CI.
Focused critical flows, traces, stable contracts, flake policy.
Edit-mode logic, play-mode lifecycle, scenario evidence.
Workload model, thresholds, resource signals, analysis.
Invariants, migrations, corruption, recovery, state diffs.
Lifecycle, compatibility, frame time, memory, normalized results.
Interview prompts worth practicing
How would you test login?
Decompose product, security, data, session, accessibility, and recovery risks before listing cases.
A test fails only in CI. Where do you start?
Preserve evidence, compare context, classify, reproduce, and reduce before proposing a fix.
Why not automate everything?
Discuss risk, repetition, determinism, layer, maintenance, diagnosis, and human learning.
How do you design a checkout load test?
Start from traffic shape, request mix, data, percentiles, thresholds, resources, and safe limits.
A release has a known defect. Ship?
Frame impact, likelihood, exposure, monitoring, rollback, mitigation, cost of delay, and decision owner.
How should a production bug change strategy?
Trace control gaps, add the lowest useful regression, and improve prevention or observability.
See the systems connect
Technical QA Visual Atlas
Eleven responsive diagrams document the core concepts, decision paths, delivery pipelines, diagnostic workflows, performance models, Unity lifecycle, collaboration cadence, and career progression.
Follow test selection, API state, automation, CI/CD, and root-cause investigation step by step.
Read illustrative performance curves, feedback cost, and workload thresholds with explicit explanations.
Trace Unity lifecycle, collaboration, quality cadence, test layers, and competency growth.
Reference library
Primary, official resources
Tool behavior and standards change. Prefer current official documentation over copied tutorials.
ISTQB CTFLTesting concepts and vocabulary
Microsoft testing strategyTest levels and architecture
DORA metricsDelivery throughput and instability
OWASP WSTGWeb security testing guidance
WCAG 2.2Web accessibility requirements
PlaywrightModern web E2E testing
PactConsumer-driven contract testing
Grafana k6Performance workload types
Unity lifecycleEvent functions and execution order
Unity Test FrameworkEdit-mode and play-mode automation
Documentation principle
Quality is a feedback system.
Use the fastest suitable test layer, keep E2E focused, model non-functional work from real risk, create trustworthy CI signals, and feed production learning back into prevention.
Back to documentation top