Quality engineering
Shift quality left, and observe it on the right.
01 — The problem
Quality is still a phase, sitting just before release, and owned by a separate team. Defects are therefore found when they are most expensive to fix. Conversely, once in production, nobody measures perceived quality any more: you find out about problems through support tickets.
02 — What we do
- 01
Make the product testable
Stable identifiers in the UI, data injection points, a controllable clock, external dependencies that can be simulated. Without testability, everything else costs three times as much.
- 02
Move checks to the developer’s workstation
Types, linting, unit tests and pre-commit checks. A defect found in the editor costs a few seconds; the same defect found in acceptance testing costs days.
- 03
Set up continuous testing
Checks at every stage of the pipeline, with a feedback time that keeps pace with the delivery cadence.
- 04
Observe quality in production
Error rate, perceived latency, abandoned journeys. Shift-right is not a gimmick: it is the only measure of the quality actually delivered.
- 05
Define metrics that drive a decision
Every metric tracked must be tied to a possible action. The rest is noise.
04 — What you receive
Named deliverables, not promises. You know what you will receive before we start.
Product testability plan
Chain of checks from the developer’s workstation to production
Quality observability foundation
Set of metrics tied to decisions
05 — Technical ecosystem
Tools do not make quality. We master them so that we can choose the right one, not to use them as a selling point.
- GitHub Actions
- GitLab CI
- Jenkins
- SonarQube
- OpenTelemetry
- Grafana
- Prometheus
- Docker
- Kubernetes