---
title: "k6 | Skills We Assign For | Azendo"
description: "k6 for load testing — thresholds in CI, realistic scenarios, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/k6/"
---

[Skills](https://azendo.co/skills/) QA and delivery tooling 

# k6.

k6 is a load testing tool with tests written in JavaScript and a Go execution engine. It is designed for automation: scriptable, version-controlled, with defined pass/fail thresholds, so performance testing runs in a pipeline rather than as an occasional exercise.

## Where k6 fits on a long engagement.

Thresholds are what make k6 useful in delivery rather than only in a report. A test declaring that the 95th percentile must stay under 500ms and errors under one percent either passes or fails, which means performance can gate a release the same way a unit test does.

The value depends entirely on the realism of the scenario. A test hammering one endpoint with no think time measures something, but not anything a user will experience. Modelling actual journeys, with realistic pacing and a data set that defeats caching, is where the work is — and where most load testing quietly goes wrong.

## What an assigned team does with k6.

Performance regressions accumulate invisibly. No single change makes a system slow; twenty changes over six months do, and without a regular baseline nobody can identify which ones or when it started.

Running that baseline continuously rather than before launches is what turns load testing from an event into a signal, assigned under [qa outsourcing](https://azendo.co/services/qa-engineering-and-test-automation/) alongside the rest of the suite.

## What we use k6 for.

* Performance gates in the pipeline Thresholds that fail a build, so a regression is caught by CI rather than by users.
* Scenarios modelled on real journeys Pacing and data that reflect actual usage rather than a synthetic hammer.
* A baseline that makes drift visible Regular runs, so a gradual slowdown is attributable to a period rather than a mystery.

## How k6 capacity is assigned.

Scenario realism is the deliverable rather than the tooling, and the baseline runs continuously rather than before launches. That standing commitment is part of [how the monthly fee is built](https://azendo.co/pricing/).

## Roles we assign k6 for

* [Performance Test Engineer QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/performance-test-engineer/)

## Service lines it sits in

* [QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in qa and delivery tooling

* [TestRail — skill we assign for](https://azendo.co/skills/testrail/)
* [Jest — skill we assign for](https://azendo.co/skills/jest/)
* [React Testing Library — skill we assign for](https://azendo.co/skills/react-testing-library/)
* [XCTest — skill we assign for](https://azendo.co/skills/xctest/)
* [Espresso — skill we assign for](https://azendo.co/skills/espresso/)
* [Detox — skill we assign for](https://azendo.co/skills/detox/)
* [Flutter Test — skill we assign for](https://azendo.co/skills/flutter-test/)
* [Playwright — skill we assign for](https://azendo.co/skills/playwright/)

## Tell us what your roadmap needs k6 for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)