Performance testing with TMAP

What is performance testing, exactly?

When people talk about performance, they often only think about speed. "How fast does this page open?" While that is a good start, it’s not the whole story. Performance testing is about how a system behaves under various conditions.

Within the TMAP quality attributes, we look at the extent to which a system meets goals for response time and processing power. You can compare it to a car. A car driving 120 km/h on an empty road has good speed. But what happens when five people are inside, there is a roof box on top, and a trailer attached to the back? Does the car still drive smoothly, or does it stall at the first hill?

In software, we focus on three main pillars:

• Response Time: How quickly does the user get an answer after a click?

• Throughput: How many transactions can the system handle simultaneously?

• Resource Usage: How much memory and processing power does the system require to do its job?

Why performance testing is crucial in Agile and DevOps

In the past, performance testing was something done at the very end of a project. There was a special 'test phase' where expensive tools were used to put the system under extreme stress. In the modern world of Agile and DevOps, that no longer works. we deliver small increments of software constantly. If you only test if the system is fast enough at the end of the year, you are much too late.

When a system is slow, users walk away. Research shows that every extra second of loading time directly harms customer satisfaction and revenue. For a computer science student, this is a tough lesson: a technically perfect app that responds slowly will not be used by anyone. For a Product Owner, it’s simple: poor performance is a business risk.

That is why TMAP advocates for 'shift-left'. This means starting your testing as early as possible. Performance is not an afterthought; it is a conversation you should have during the refinement of a User Story.

Making performance concrete with the VOICE model

The tricky part of performance is that it often remains vague. "The app must be fast," says the business. But what is fast? For a bank transfer, two seconds is fine, but for an action game, it's an eternity. To make this measurable, the e-learning TMAP: Quality for Cross-Functional Teams uses the VOICE model. This helps you look beyond just the technical side.

Value

Ask yourself: what value does speed provide to the user? For a webshop, a fast checkout leads to more sales. For an internal business app, a faster search function means employees are less frustrated and more productive. When you know the value, you know how much time and money to invest in testing.

Objectives

Set hard goals. Instead of "the app must be fast," we agree: "95% of all searches must show a result within 800 milliseconds with 500 simultaneous users." Now you have something you can actually measure.

Indicators

How do we measure if we are hitting those goals? This is where technical terms like latency, CPU load, and memory usage come in. These are the gauges on your dashboard that tell you how your software's engine is performing.

Confidence

This is perhaps the most important part for a tester or QA engineer. Do we have enough data to go 'live' with peace of mind? If you only tested with one user, your confidence is low. If you ran a heavy load test that mimics the real world, your confidence is high.

Experience

Numbers tell a story, but not the whole story. Sometimes an app feels slow, even if loading times are technically fine—perhaps because there is no loading icon. The end-user's experience is the ultimate measure of success.

Recognizable situations: when does It go wrong?

To understand why we do this, let’s look at a few examples from the daily reality of IT teams.

The growing database

A team builds a new portal. During development, everything is lightning fast because there are only ten test records in the database. But once the system goes live with 100,000 users, searches suddenly take ten seconds. The database query that worked on a small scale isn't scalable. With performance testing on a representative dataset, the team could have caught this months earlier.

The mobile network

A developer builds a beautiful feature on a high-end laptop with a stable fiber connection. However, the end-user is on a train with a poor 4G signal on an old phone. If the app has to load three megabytes of JavaScript before anything happens, that user experiences massive lag. Performance is also about how you build your software (e.g., using code-splitting).

The memory leak

Some problems aren't visible immediately. An application might run perfectly for the first few hours but slowly consume more and more memory. After two days, the server suddenly crashes without an obvious reason. Soak tests (long-duration tests) are an essential part of a solid performance strategy.

How to make performance testable in your team

In a cross-functional team, quality is everyone’s responsibility. That includes performance. Here are three steps you can take tomorrow:

1. Ask Questions at the User Story: When the Product Owner wants a new feature, ask immediately: "How many people will use this at once?" and "What is the maximum wait time we find acceptable?"

2. Monitor in Production: Use tools to see how the software behaves in the real world. If you notice certain functions getting slower, you can intervene before it becomes a serious problem.

3. Test Small: You don't always need a massive load test. A developer can check how many database calls are being made while writing code. Fewer calls almost always mean better performance.

Improve structurally with Testlearning

Performance testing is a specialized field, but the basic principles belong in the toolbox of every IT professional. Whether you are a developer wanting to write faster code or a tester learning to map out risks, TMAP knowledge will help you.

In our e-learning TMAP: Quality for Cross-Functional Teams, we dive deep into these quality attributes. We teach you not just the theory, but how to apply it within an Agile or DevOps environment. You learn how to set the right priorities with your team, so you don't have to test everything to exhaustion, but instead focus on the areas with the highest risk.

The advantage of our digital training is that you learn at your own pace, with examples that are immediately recognizable for your workday. No dry walls of text, but practical tools you can use right away.

Speed is a choice

Software quality doesn't happen by accident; it is the result of conscious choices. By taking performance testing seriously and applying TMAP principles, you prevent your team from spending valuable time "extinguishing fires" in production. You build software that makes users happy and supports your organization's growth.

Want to learn how to structurally embed quality in your team? View our range of TMAP courses and take the next step in your professional development. Because a fast application starts with a team that knows exactly what they are doing.