Use production telemetry as INPUT to design new tests. Covers OpenTelemetry integration with tests, trace-based assertions, log-informed test creation, production-error analysis for coverage gaps, and telemetry-driven test prioritization. Use when: "trace-based testing," "design tests from logs," "O

<objective Production is the richest source of test design input: every error log, slow trace, and latency spike tells you where tests are missing. This skill closes the feedback loop between production observability and test creation, and makes trace structure a test assertion. A 200 OK that silently hit the database on a path meant to be cache only passes an HTTP assertion — a trace assertion catches it. Output: instrumented test runners, trace based assertions, and a production error to test pipeline. </objective Quick Route Situation Go to Make test execution emit traces correlated with the app OTel test runner setup ( references/trace assertions.md ) Assert which services were called / no error spans / latency Traces as Test Evidence Turn a Sentry/Datadog error into a test Production Error to Test Pipeline Decide which endpoints need tests next Telemetry Driven Test Prioritization A trace assertion is flaky or a span never arrives Failure Modes Discovery Questions Check .agents/qa project context.md first. If it exists, use it as context and skip questions already answered there. Observability stack: What APM/tracing tool is in place? (Datadog, New Relic, Honeycomb, Splunk Observability/SignalFx, ServiceNow Cloud Observability — formerly Lightstep, Dash0, Jaeger, Grafana Tempo, OpenTelemetry native) — determines how you pull traces and which query syntax the diagnosis workflow uses. Is OpenTelemetry instrumented in the application, and which services? — un instrumented services are invisible and untestable via traces. What logging infrastructure exists? (ELK, Loki, CloudWatch, Datadog Logs) — sets where log by trace ID correlation happens. Are structured logs used, or free form text? — structured logs are parseable into test gaps; free form needs a fingerprinting step first. Tracing maturity: Are distributed traces available across service boundaries? — without them, only single service span assertions are possible. What is the trace sampling rate? (100%, 10%, head based, tail based) — probabilistic sampling will randomly drop the trace a test asserts on; you must force sample test traffic (see Failure Modes). Can you search traces by error status, latency threshold, or custom attributes? Are traces correlated with logs and metrics? — enables exemplars (metric → representative trace ID), which makes prioritization concrete. Production error tracking: What error tracking tool is used? (Sentry, SmartBear Insight Hub — formerly Bugsnag, Rollbar, Datadog Error Tracking, LaunchDarkly Observability — incl. session replay, formerly Highlight.io) How are production errors triaged? (Automated, manual, ignored) Is there a process for turning production errors into test cases? What was the last production error that a test should have caught? Test infrastructure: Can tests emit telemetry? (Traces, custom metrics, structured logs) Are test results correlated with application telemetry? Do you have a test to code coverage mapping? — required to compute the error rate to coverage matrix below. Core Principles 1. Production data informs test priorities The most valuable tests prevent real production errors — not theoretical edge cases, not contrived scenarios. Production error logs are a pre prioritized backlog of tests you should have written, ordered by what real users actually hit. 2. Traces are test evidence "The API returned 200" proves the endpoint responded. "The request hit the cache, skipped the database, and returned in <50ms" proves the system behaved correctly at every layer. Traces make tests deeper without making them more brittle. 3. Observability gaps equal test gaps A code path with no traces, no logs, and no metrics is invisible — untestable in production and unverifiable during incidents. Observability coverage and test coverage are two views of the same problem. 4. Close the feedback loop The complete cycle: error detected → analyzed → test written → deployed → recurrence prevented. If your team finds production errors but does not systematically create tests, the same class of error recurs. Traces as Test Evidence Pin @opentelemetry/semantic conventions to an exact version and treat sem conv bumps as breaking. Trace assertions reference attribute names by string; those names drift across releases and your assertions silently break. v1.41.0 (April 2026) shipped GenAI breaking changes and a process.executable entity split, and moved graphql.document from Recommended to Opt In. Pin the literal version and bump deliberately: Do not introduce new OpenTracing shims. The OTel spec deprecated OpenTracing compatibility in March 2026 (removal no earlier than March 2027); new instrumentation should target native OTel APIs and OTLP. Three patterns, all in references/trace assertions.md : OpenTelemetry integration in test infrastructure — instrument the test runner ( test setup/tracing.ts ) so test execution correlates with application traces via service.name , test.suite , and test.run id resource attributes. Flush from the runner's global teardown with an awaited sdk.shutdown() — not process.on('beforeExit') , which drops trailing spans. Trace based assertions — assert on trace structure, span attributes, and timing (which services were called, no ERROR spans, root span latency, DB operations) instead of only the HTTP status. For unit level span checks, use an in process InMemorySpanExporter + SimpleSpanProcessor and read getFinishedSpans() synchronously — no network, no waitForTrace , no timeout flake. Reserve the real collector + waitForTrace path for cross process traces. Distributed trace validation across services — an assertTraceStructure helper that verifies a request flowed through the expected services in order, with per span attribute and maxDuration checks. For declarative trace based assertions (YAML/UI driven instead of hand rolled span queries), the OSS Tracetest project ( kubeshop/tracetest ) is still available, but the last public OSS release is v1.7.1 (Oct 2024) with low recent activity — evaluate maintenance before adopting. Tracetest's commercial Cloud offering was end of lifed October 2024; do not set up Tracetest Cloud, users will hit a dead product. Log Informed Test Design Analyze production error logs for test gaps Production errors are the highest priority input for test creation. Each unhandled error is a missing test. See references/log and error pipeline.md for the analyze production errors.ts script that maps each production error to test coverage, assigns a priority by frequency and recency, and suggests a test layer (unit/integration/e2e) from the error characteristics. Categorize errors: covered vs. uncovered Prioritize test creation by error frequency and impact Prioritize using a 2×2 of frequency (high/low) vs. impact (high/low): P0 = high frequency + high impact (fix now), P1 = low frequency + high impact (next sprint), P2 = high frequency + low impact (this sprint), P3 = both low (backlog). Impact indicators: high = payment/auth failure, data loss, crash; low = UI glitch, slow but functional response. Telemetry Driven Test Prioritization Score endpoints by error weighted gap Invest test effort proportional to real usage and real failure. Gap Score is the canonical formula used throughout this skill: This is error weighted: it ranks an endpoint by the absolute volume of failing requests it produces, divided by how much test coverage already guards it. (If you instead want a volume weighted lens that surfaces high traffic but healthy endpoints, multiply by (1 + error rate) rather than error rate — a different question, not the matrix's labels.) Error rate by endpoint to test coverage mapping Every label above is derived from the formula and the stated thresholds — copy the formula and you reproduce the matrix exactly. Pick your own thresholds, but state them; never hand label. Exemplars close the metric → trace → test loop. When a high error endpoint surfaces in this matrix, OTel exemplars let you jump straight from the error rate metric to a representative failing trace ID, then walk that trace (below) to write the test — instead of hunting for a matching trace by hand. Hot path analysis Identify the most traversed code paths in production and ensure they have proportional test coverage. Pair endpoint level traffic data with continuous profiling to find CPU and allocation hot paths inside endpoints, not just at the boundary. The OTel profiling signal entered public alpha on 2026 03 26 (OTLP path /v1development/profiles ), with GA targeted for Q3 2026 — treat it as not yet production. Production ready alternatives today: Pyroscope , Parca , Polar Signals , Datadog Profiling . eBPF zero instrumentation profilers (no SDK changes): Polar Signals, Parca, Grafana Beyla . Zero instrumentation observability — when adding the OTel SDK isn't feasible, eBPF tools capture HTTP/gRPC traces from kernel syscalls without code changes: Beyla (Grafana), Cilium Tetragon , Pixie , Coroot . Useful for legacy or polyglot services where SDK rollout takes quarters. OTel Weaver generates type safe instrumentation code from semantic convention YAML — keeping trace assertions in sync with sem conv bumps. Worth adopting if you maintain custom conventions or hit attribute drift between versions. Production Error to Test Pipeline The most important workflow in this skill: turning production errors into tests that prevent recurrence. See references/log and error pipeline.md for a full test built from Sentry issue PROJ 4521 (null shipping address → null reference), asserting either a 400 or 422 (whichever your contract uses) at the API layer plus the E2E checkout prompt. The test name and a comment document the originating error, frequency, and context — the convention to follow when creating tests from production signals. Establish the team feedback loop Weekly error review (30 min): pull the top 10 new errors by frequency from the error tracker. For each: assign an owner, create a test, or mark as known/acceptable. An error tracker with thousands of unresolved entries that nobody reads is the anti pattern. Incident close gate: add "What test would have prevented this?" to every postmortem; the test is created (or the gap is explicitly recorded) before the incident is closed. Tie this to a checklist item so it is auditable, not aspirational. Diagnosis Workflows Trace a failing request end to end When a test fails or a production error occurs, use the trace to understand exactly what happened. Correlate test failures with production telemetry When a test fails, query your observability platform: (1) search production errors for matching messages (last 7 days); (2) search traces for the same HTTP route with ERROR status. Matches exist → the bug is real and affecting users, prioritize the fix. No matches → likely a test only issue or a new bug not yet in production. This turns "probably flaky" into "confirmed production impact" or "test only issue." Anti Patterns 1. Ignoring production signals The error tracker has 500 unresolved errors nobody looks at; the suite passes, so the team assumes quality is fine. Fix: run the weekly 30 minute error review above — top 10 new errors, each assigned an owner, a test, or a known/acceptable mark. 2. Testing only what is easy to observe Teams assert HTTP status and response time while ignoring data consistency, background job completion, and cache coherence. Fix: add spans to background jobs, cache ops, and async workflows, then assert on them. If it runs in production, it should produce telemetry. 3. No feedback loop between production and testing SRE handles errors, QA writes tests, neithe

observability-driven-testing