Performance testing: finding the limit before your users do
Performance tests answer specific questions. Running load without a question produces numbers nobody can act on.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Test level distribution drives cost and reliability.
- Automate by risk and frequency; document what you will not automate.
- Stable selectors and single-behaviour tests survive refactors.
- Treat flaky tests as defects with owners and deadlines.
Distribute tests by level deliberately
Many unit tests, fewer integration tests, few end-to-end tests. The shape matters because cost and reliability differ by an order of magnitude between levels.
Inverted suites — mostly end-to-end — are slow, fragile and expensive to maintain, and they are the most common reason teams stop trusting automation.
Automate by risk and frequency
- Paths where failure is expensive: authentication, payment, data integrity.
- Paths exercised constantly, where regression is likely.
- Areas with a history of defects.
- Complex logic where manual verification is slow and unreliable.
Explicitly decide what will not be automated, and write that down. Unstated coverage gaps become assumed coverage.
Design for maintainability
Tests that break on every interface change get deleted. Select elements by stable, purpose-built attributes rather than by CSS structure, keep selectors in one place, and avoid asserting on incidental detail.
Each test should verify one behaviour and read as documentation of that behaviour.
Flakiness is an emergency
A suite that fails randomly teaches people to re-run rather than investigate, and at that point it protects nothing.
Quarantine flaky tests immediately, raise them as defects with an owner and a deadline, and fix or delete them. Nothing degrades the value of automation faster than tolerated flakiness.
Making the suite part of the culture
Automation succeeds when the whole team owns it. Where tests belong to a separate group, developers merge changes that break them and treat the failure as someone else's problem.
Put test results where developers already look, make the suite fast enough to run before merging, and treat a red build as blocking rather than advisory.
Review test health alongside code health. A suite whose maintenance is nobody's job accumulates flakiness until it is switched off, which is how organisations end up with automation they no longer trust.
Frequently asked questions
Coverage measures execution, not verification. Meaningful tests on critical paths matter more than a number, and chasing a high percentage produces tests written to satisfy the metric.
Both, at different levels. Developers own unit and integration tests; specialists typically own end-to-end and non-functional testing. Shared ownership of the suite's health works best.
Fast checks in minutes; the full suite short enough to run on every merge. Beyond that, it runs less often and defects are found later.
