---
title: "Who uses performance testing? | Grafana Labs"
description: "How developers, QA engineers, and SREs use performance testing differently"
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

## Three roles, three questions

The same HTTP metrics support goals you already talk about in incidents and planning: **end users waiting on slow responses**, **clients or gateways hitting timeout limits**, and **5xx or failed requests when concurrency looks normal**. k6 does not replace **real user monitoring** (collecting performance data from actual user sessions in production) or **browser** testing, but it does give you a repeatable load script and numbers you can gate on.

These are simplified labels; real teams mix responsibilities. The point is the **question** each workflow optimizes for, not that only one role may open an editor.

| Role                        | Question they need answered                                                          | Typical k6 touchpoint                                                                                   | Outcome you might see                                               |
|-----------------------------|--------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------|
| **Developer**               | Did my change regress latency or errors before it lands on main?                     | k6 run in **CI** on the branch with thresholds on `http_req_duration` / `http_req_failed`               | Merge blocked when p95 or error rate crosses a defined line         |
| **QA / release validation** | Is **this build** within the same performance envelope as the last release?          | Scheduled or on-demand k6 run against **staging**, compare runs in Grafana Cloud                        | Release note or ticket when a metric drifts beyond an agreed budget |
| **SRE / platform**          | What is **normal** load and latency, and how much margin do we have before an event? | Baseline against production-like traffic, then capacity or incident follow-up outside this intro course | Autoscaling, limits, or comms grounded in measured steady state     |

## Where you’ll start

This course teaches the skills all three workflows share: writing a test, setting thresholds, and establishing a baseline that produces an automated pass or fail verdict. How you apply those skills depends on your role: in **merge review**, **release validation**, or **capacity planning**.