Software Testing: What is Performance Testing

The video above is a short introduction to performance testing, where I use two outages almost everyone remembers, the Obamacare website and Pokemon Go, to show why it matters. Below is the written version, expanded into a fuller guide.

Watch the full video on YouTube: Software Testing, What is Performance Testing.

Performance testing is the difference between an application that works in a demo and one that survives the day real users show up all at once. In the video I keep it short and point at two launches everyone remembers. The Obamacare website buckled under load on its first day. Pokemon Go fell over because nobody accurately predicted how many people would install it at the same time. Both were built by capable teams, and both still failed the moment real traffic arrived, because nobody had proven the system could carry it. That is the gap performance testing exists to close, and this guide expands the short version into what you actually measure and how to begin.

You do not need to be a specialist to start. You need to know what you are measuring and why.

Why Performance Testing Matters

Performance testing is the process that makes sure there are no performance problems waiting for you when an application is released into production.

Functional testing answers one question: does the feature work when one person uses it? Performance testing answers a harder one: does it keep working when thousands of people use it at once? The cost of skipping it is public and expensive. The two examples I use in the video are not jokes, they are warnings. A government website and a global game both launched, drew the load everyone should have expected, and collapsed in front of their users. Catching that before release is not a luxury. It is the work that protects the launch.

What You Are Really Measuring

A useful performance test watches four numbers together: response time, throughput, error rate, and resource usage.

Response time is how long each request takes, and the slow tail matters more than the average. Throughput is how many requests the system handles per second. Error rate is the share of requests that fail under load, and it often climbs sharply right before a system gives out. Resource usage is what the servers are doing underneath, the CPU, the memory, the database connections. I ran performance tests on teams where I found issues taking thirty seconds and, working back with development, we drove them down into milliseconds. That kind of result only happens when you measure the right things and read them together instead of trusting one number alone.

The Types Worth Knowing

Most performance work falls into a few types, and each one answers a different question about how the system holds up.

You do not run all of these every time. You choose the ones that match the risk you care about:

• Load testing. How does the system behave under the number of users you actually expect? This is the baseline.
• Stress testing. Where does it break? You push past normal load on purpose so you learn the ceiling in a test instead of in production.
• Spike testing. What happens when traffic jumps suddenly, the way it did for Pokemon Go? Sudden surges break systems that handle steady load fine.
• Soak testing. Does it survive sustained load over hours? This is how you catch slow memory leaks a short run hides.

Each type maps to a real failure. Choose by asking which failure would hurt you most.

The Tools

The tools range from heavyweight commercial suites to modern open-source options, and the right one depends on your budget and your scale.

In the video I talk about the tools my teams have used. LoadRunner is the long-standing heavyweight, and if money is no object it is hard to beat, though it is far from cheap. Performance Center extends it for larger, distributed runs. AppDynamics is the partner I pair with it, because it helps identify and troubleshoot where a performance problem actually lives on the back end. The combination of a load generator and an application monitor is what turns a slow number into a fixable cause.

If the commercial price tag is out of reach, modern open-source tools like JMeter and k6 cover most of the same ground, and the discipline matters more than the brand. A clear target and a realistic load beat an expensive tool pointed at a guess.

Final Thought

Performance testing is not optional polish. It is the practice that tells you whether your software will hold up when real people arrive all at once, and the Obamacare and Pokemon Go launches are what happens when a team skips it. Learn the types, measure the four numbers that matter, pick a tool that fits your budget, and run it early enough that the answers can still change the build. Do that and launch day stops being a gamble.

The full video is the short introduction. Watch it above, and tell me in the comments: what is the worst performance problem you have caught before release?