How to Test Performance — How to Test This Podcast, Episode #15

Performance is more than tools and metrics — it's mindset and responsibility. I was happy to contribute to a conversation about performance engineering and real-world testing challenges on the How to Test This podcast. Still learning every day — but excited to share what I've learned so far.

In Episode #15 — How to test Performance — I sat down with the How to Test This team to talk about 12+ years of performance test engineering and building LoadTestExperts. We covered why performance issues are silent revenue killers, how testing differs for banks versus startups, and why teams should test for business goals rather than just trying to crash the system.

Performance issues are silent revenue killers. Unlike functional bugs, users don't report slow systems — they leave. If a page takes more than three seconds, attention drops. Performance protects transactions, trust, and revenue.

Performance testing is not about crashing the system. It answers two business questions: Is it fast enough? Can it handle the expected load and scale? Saturation and other extreme tests are not always necessary.

Slow systems make employees mentally tired and unproductive. For internal tools, sluggish interfaces increase context switching and mental fatigue, reducing tickets closed and measurable output.

Start with workload, not tools. An efficient performance engineer first understands users, transactions, peak traffic, and critical flows — then uses static analysis and dynamic tools to validate with clear, business-focused reporting.

Performance must start at design. Involving performance early means avoiding costly performance debt later, with acceptance criteria on speed (under one to three seconds), load capacity, and scalability. As long as the loading spinner exists, performance engineering will always matter.

We also walked through load versus stress versus capacity testing, a step-by-step guide to finding bottlenecks, monitoring versus observability, choosing tools, why performance experts should be involved early, and how to split responsibilities between testers, developers, and DevOps.

Listen to the full episode on YouTube: https://www.youtube.com/watch?v=yjsYB2-Ey1U

Episode timeline: 00:02:00 — Why I switched from finding bugs to fixing slow systems. 00:05:33 — How performance testing changes for banks vs. startups. 00:08:14 — Testing for business goals, not just system crashes. 00:10:22 — Load vs. stress vs. capacity testing. 00:13:52 — Slow apps kill user attention and drain revenue. 00:19:10 — A step-by-step guide to finding bottlenecks. 00:27:48 — Monitoring vs. observability. 00:30:01 — Choosing your tools. 00:34:03 — Why performance experts should be involved early. 00:39:30 — Acceptance criteria for success. 00:42:35 — How a bad analysis can break a release. 00:46:28 — Practical advice for teams new to performance. 00:53:21 — Splitting tasks between testers, devs, and DevOps. 00:57:59 — The evolving landscape of performance engineering. 01:01:11 — Recommended projects, certifications, and where to start. 01:08:00 — The vision: a spinner-free digital world.