Observability Driven Testing

<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

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: ``json // package.json — exact pin, no caret "@opentelemetry/semantic-conventions": "1.41.1" ` `bash npm install --save-exact @opentelemetry/semantic-conventions@1.41.1 `` 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

1. Export production errors from error tracker (Sentry, Insight Hub, etc.)
   - Filter: last 30 days, count > 5 (ignore one-off errors)
   - Group by: error message fingerprint

2. For each error group:
   a. Does a test exist that would catch this error?
      → Yes: the test is either not running or has a gap (investigate)
      → No: this is a test gap (create a test)

   b. What layer should the test live at?
      → TypeError, null reference → unit test
      → Timeout, connection error → integration test with fault injection
      → UI rendering error → E2E test
      → Data inconsistency → contract test or database test

3. Output: prioritized list of tests to create, ordered by:
   error frequency × user impact × recency

Prioritize test creation by error frequency and impact