Home — Approach
How we work
A method refined across banking, retail, energy, automotive and logistics programmes. Identify the approach, classify the risk, execute, then refine against what the evidence actually says.
Six phases.
None of them optional.
The order matters more than the tooling. Most failed performance programmes we have been called in to rescue skipped phase one and never recovered.
-
Identify
Which flows carry the volume, which carry the money, and which carry the regulatory exposure. Usually three different lists. We build all three before writing a single script.
-
Classify
Risk-rank every flow by blast radius and likelihood. This is what decides where automation investment goes — not what is easiest to automate, which is the default failure mode of most suites.
-
Model
Derive the workload from production telemetry: real concurrency, real think times, real data cardinality, real arrival distribution. A model built from assumptions will pass a test your platform would fail.
-
Instrument
APM, logs and infrastructure metrics attached before the first execution. A load test without instrumentation produces a number. With it, you get a cause.
-
Execute
Baseline first, then capacity, stress, spike, endurance and soak. Each with an exit criterion agreed in advance, so nobody negotiates the definition of “pass” after seeing the result.
-
Refine
Findings go back into the model, the suite and the pipeline gate. Every release cycle the framework is extended to cover new endpoints and flows — otherwise coverage silently decays while the dashboard still says green.
Shift left, but honestly
Moving testing earlier only helps if the earlier tests are meaningful. A thousand fast unit tests will not tell you the connection pool exhausts at 4,000 concurrent sessions. Both layers, doing their own job.
Evidence over opinion
Every claim we make about your platform comes with the execution behind it. Where the data is inconclusive we say so, rather than rounding it into a reassuring sentence.
Build it to be handed over
Frameworks are written to be maintained by your team. We document, we run knowledge transfer, and we consider the engagement failed if the suite decays six months after we leave.
The environment is part of the test
Unhealthy environments generate false failures, false failures destroy trust in the suite, and a suite nobody trusts gets bypassed. So we monitor the environment as rigorously as the application.
Write NFRs that can fail
“Responsive under normal load” is not a requirement, it is a wish. A threshold needs a number, a percentile and a load condition, or it will never stop a release.
Report to the room you are in
Engineers need the flame graph. The Head of Delivery needs one slide and a recommendation. We produce both, and we do not confuse the two audiences.
What you receive.
Governance in regulated sectors runs on documents. We produce them to the standard that has cleared bank, energy and public sector review.
- Test strategy
- Test plan
- Workload model
- NFR specification
- Risk classification matrix
- Execution reports
- Telemetry comparison reports
- Bottleneck analysis
- Capacity findings
- Exit report
- Handover & KT pack
- Framework documentation
Plus the stakeholder walkthroughs. Written artefacts do not secure a milestone approval on their own — somebody has to stand in front of the steering group and defend the numbers. We do that.
Bring us the release you are
least comfortable shipping.
A short, specific conversation is usually enough to tell whether we can help. No discovery deck, no bench to feed — just an engineer who has broken systems like yours on purpose, many times.
Typical first engagement: a two to three week assessment producing a workload model, an instrumented baseline and a ranked list of what will fail first.