Logging
// Definition
The practice of recording timestamped events emitted by a running application — errors, warnings, informational messages, and debug traces — to a persistent or queryable store. Logs are one of the three pillars of observability, alongside metrics and traces. A well-structured log entry carries at minimum a timestamp, a severity level (ERROR, WARN, INFO, DEBUG), a message, and a correlation ID linking it to its originating request. In QA, logs are the primary post-hoc evidence for what happened during a test run: a failing end-to-end test rarely tells you which backend call failed — the logs do. Structured logging (JSON lines rather than free-form text) makes logs programmatically queryable without regex parsing. Common testing concerns include verifying that the correct log level is used (a caught exception should be WARN or ERROR, not INFO), that no PII appears in plain text, that correlation IDs are propagated to every service hop, and that security-relevant events (failed login, privilege escalation attempt) are logged at the right level with enough context to reconstruct the event.
// Related terms
Observability
The ability to understand the internal state of a system from the signals it emits externally, without needing to redeploy or modify the system. The three pillars are logs (timestamped records of discrete events), metrics (numeric measurements aggregated over time, such as request rate, error rate, and latency percentiles), and traces (end-to-end records of a request's path through distributed services, linked by a correlation ID). High observability means a QA engineer can diagnose a failure purely from existing output, without attaching a debugger or reproducing the issue locally. In test environments, observability enables post-run failure analysis: instead of re-running a flaky test with extra logging, query structured logs for the test's correlation ID and see exactly which service call failed and why. Contrast with monitoring, which alerts on known failure thresholds — observability enables exploration of previously unknown failure modes.
Correlation ID
A unique identifier — typically a UUID — attached to a request when it first enters a system and propagated through every downstream service call, log entry, and event. Correlation IDs make it possible to trace a single user action across multiple services, relating all log entries to one root cause. QA engineers use them to diagnose failures in distributed systems: locate the correlation ID in a failing test's response header, then grep every service log for that ID to reconstruct the exact call chain. Absence of a correlation ID on any hop indicates a broken propagation point. CI pipelines increasingly inject a known correlation ID into test requests so that post-run log analysis can be scoped to a single test run's traffic.
Flaky Test
A test that passes and fails intermittently without any code changes, often caused by timing issues, shared state, async race conditions, or external dependencies. The single largest source of CI noise.