Technical QA Visual Atlas

01 · System loop

Quality feedback system

Quality work is a closed feedback system. Every release should improve the next risk model, not merely reset the test cycle.

DiscoverUnderstand users and architectureGoals, dependencies, constraints
ModelIdentify failure modes and riskImpact, likelihood, uncertainty
DesignChoose the fastest useful evidenceHuman and automated layers
DeliverRun feedback at the right cadenceLocal, PR, nightly, release
ObserveWatch real system behaviorLogs, metrics, traces, incidents
LearnImprove prevention and detectionControls, tests, telemetry, design

Read clockwise. The loop fails when production evidence does not change future design, test strategy, or observability.

02 · Decision flowchart

From product risk to a test decision

A test is justified by the decision it supports. Start with failure and uncertainty before selecting a tool.

1What can fail?Behavior, data, security, performance, recovery

ImpactWho or what is harmed?User, revenue, safety, compliance, operations

LikelihoodHow exposed is the failure?Frequency, complexity, change, dependency

UncertaintyWhat do we not understand?New architecture, weak telemetry, unknown data

2Choose the lowest stable layerStatic · unit · integration · API · component · E2E · production signal

AutomateRepeatable and deterministicFast feedback and regression

ExploreUncertain and discovery-heavyHuman observation and adaptation

ObserveProduction-only behaviorMonitoring, canary, rollback

3Define the action thresholdInform · investigate · block · mitigate · roll back

A large test count is not the output. The output is decision-ready evidence tied to a material risk.

03 · Layer map

A layered test portfolio

Use broad, fast checks near the code and a small number of high-value system journeys. The exact shape follows architecture and risk.

Production signalsReal behavior · fastest incident learning

End-to-end journeysFew · slow · broad integration confidence

Component and contractBoundaries · UI states · service compatibility

API and integrationBehavior · data · dependencies · failure paths

Unit and static checksMany · fast · precise · developer feedback

Do not force a pyramid quota. Place each important rule at the cheapest layer that can observe it reliably.

04 · System flow

API request, state, and contract flow

API testing follows behavior across boundaries: identity, transport, service logic, durable state, asynchronous work, and observable outcomes.

ClientIntent and payloadMethod, headers, body, idempotency key
Edge / AuthIdentity and policyAuthentication, authorization, rate limits
ServiceValidation and rulesSchema, domain behavior, error mapping
DatabaseDurable stateTransaction, constraints, integrity, migration
Queue / EventAsynchronous effectsRetry, ordering, duplication, timeout
ConsumerObservable outcomeRead model, notification, downstream contract

ContractSecurityState invariantTimingIdempotencyDiagnostics

A 200 response is only one observation. Verify permissions, persistence, downstream effects, repeat behavior, and evidence for failure.

05 · Engineering loop

Reliable automation architecture

A trustworthy automated test controls state, acts through stable contracts, waits for meaning, and preserves enough evidence to diagnose a failure.

ArrangeOwn test data and environmentKnown state, explicit dependencies
ActUse intentional interfacesPublic API, role, label, stable test contract
SynchronizeWait for observable meaningNo fixed sleeps or ordering assumptions
AssertCheck business-relevant outcomesFocused, readable, diagnostic
CapturePreserve failure evidenceLogs, trace, request, response, screenshot
ResetRelease or rebuild owned stateIndependent rerun and parallel safety

Common flake sources Shared dataFixed waitsHidden orderUnstable selectorEnvironment driftWeak evidence

Retry may classify instability, but it must not hide it. Treat repeated nondeterminism as a product, test, data, or environment defect.

06 · Delivery flowchart

Multi-speed CI/CD quality pipeline

Fast checks protect developer flow; deeper checks run when their cost and signal fit the decision cadence.

01CommitChange and review context
02BuildCompile and package inputs
03Static checksFast prevention
04UnitLogic and local contracts
05IntegrationBoundaries and data
06API / componentService and UI behavior
07Focused E2ECritical journeys
08PerformanceScheduled or release model
09PackageVersion and configuration
10DeployProgressive environment change
11SmokeCritical production behavior
12ObserveSignals, rollback, learning

PR: fast and deterministic Nightly/release: broader and costly Production: controlled and observable

A gate should block only when its evidence is trusted, the threshold is explicit, and the team knows how to act.

07 · Investigation flowchart

Root-cause investigation

Preserve evidence before changing the system. Reduce uncertainty step by step and keep facts separate from hypotheses.

01ReproduceSmallest reliable trigger
02Verify contextBuild, config, device, data
03Preserve evidenceLogs, stack, trace, timing
04Inspect boundariesNetwork, dependency, database
05Compare stateBefore, during, after
06Trace code pathOwner, lifecycle, concurrency
07Reduce the caseRemove unrelated variables
08Falsify hypothesesPredict, test, reject
09Verify the fixOriginal failure and side effects
10Prevent regressionTest, telemetry, design control

SymptomWhat is observed

TriggerWhat exposes it

Root causeWhat makes it possible

RegressionWhat a change broke

Side effectWhat else changed

Stopping at “cannot reproduce” or “fixed” leaves risk behind. Record the context, verification, regression boundary, and learning.

08 · Graphs

Performance saturation and frame budgets

These are illustrative models, not benchmark targets. Measure your actual workload, percentiles, resources, and device conditions.

Service response time under rising load

25% load180 ms

50% load210 ms

75% load290 ms

100% load610 ms

125% load1.4 s

The knee suggests saturation: latency rises faster than useful throughput.

Frame-time budget

120 FPS8.33 ms

60 FPS16.67 ms

30 FPS33.33 ms

20 FPS50 ms

Budget = 1,000 ms divided by target FPS; CPU, GPU, waits, and overhead share it.

Latency percentilesThroughputError rateCPUGPUMemoryAllocation / GCDisk and networkThermal state

Look for saturation, spikes, leaks, queue growth, and recovery. Averages can hide the user-visible tail.

09 · Runtime map

Unity lifecycle and regression probes

Many game defects appear only when lifecycle, pooling, persistence, content, and device conditions interact.

LoadScene and contentCatalog, dependency, configuration, migration
AwakeCreate stateReferences, services, serialized values
OnEnableSubscribe and activateListeners, pools, presentation state
StartBegin behaviorCross-object ordering and readiness
FixedUpdatePhysics stepCollision, movement, time scale
UpdateGameplay frameInput, rules, animation, timers
RenderPresent frameCPU, GPU, memory, resolution
Pause / focusInterrupt runtimeBackground, network, audio, save
OnDisableReset reusable stateListeners, timers, particles, ownership
Destroy / quitRelease and persistCleanup, atomic write, recovery

LifecyclePause, resume, focus, force close, scene re-entry

ContentMissing asset, stale catalog, interrupted load, low memory

StateSave migration, duplicate grant, rollback, cloud conflict

DeviceResolution, safe area, GPU, thermal, storage, permissions

After a refactor, compare lifecycle order, event ownership, serialized data, state invariants, frame timing, and memory on representative devices.

10 · Cadence and ownership

Collaboration across a delivery cycle

Technical QA exchanges different evidence at different cadences. Quality remains a whole-team responsibility.

DailyActive feedbackCI, testing, logs, pairing, defect evidence

WeeklySystem healthEscapes, flakes, environments, suite maintenance

SprintProduct learningRefinement, coverage, review, retrospective

ReleaseDecision evidenceRegression, non-functional risk, monitoring, rollback

ProductionClosed loopSmoke, telemetry, incidents, prevention

Technical QARisk and evidence specialist

Product / DesignIntent and user impact

DevelopmentChange and code ownership

ArchitectureBoundaries and failure modes

DevOps / ReleaseEnvironment and deployment

SecurityThreat and authorized scope

Support / OperationsReal-world symptoms

QA can read and write code, debug, and review architecture while production-code ownership and approval remain explicit.

11 · Progression map

Technical QA competency progression

Growth is an increase in scope, independence, systems thinking, and organizational influence - not merely years or tool count.

Competency	Junior	Mid	Senior	Lead / Staff
Testing and risk	Basic	Intermediate	Advanced	Advanced strategy
Programming	Basic	Intermediate	Advanced test systems	Standards and direction
Architecture	Awareness	Trace boundaries	Review failure modes	Influence design
Automation	Maintain	Own features	Design frameworks	Portfolio strategy
API and data	Basic checks	Independent analysis	Distributed state	Cross-system policy
CI and reliability	Use pipeline	Improve signal	Design gates	Delivery governance
Debugging	Reproduce	Isolate	Lead RCA	Improve prevention
Leadership	Collaborate	Own feature	Mentor systems	Shape organization

Execute reliablyOwn a featureOwn systemsShape strategy

Specialist transitions can lead toward SDET, software engineering, automation architecture, performance, DevOps, security, QA architecture, or engineering management.

See the whole quality system.