PERFORMANCE TESTING

Software can be functionally flawless and still disappoint the people using it. Logging in suddenly takes several seconds, search slows to a crawl under load, or the whole application turns unstable the moment a few thousand users arrive at once. Functional tests will never surface problems like these. Performance testing gives developers hard evidence of where the technical bottlenecks sit and how a change to the system affects the way it performs.

This article is a practical guide to keeping system performance predictable. It covers four areas:

• Test types compared: where load, stress, soak and spike testing each earn their place
• The metrics that matter: from backend resource usage to Core Web Vitals in the frontend
• Test infrastructure: best practice for building realistic environments and load scenarios
• The shift-left approach: bringing performance testing into CI/CD pipelines and DevOps workflows early

QualityOne offers performance testing both as a standalone service and as part of our TaaS model (Testing as a Service). That gives companies access to specialist testing expertise and the technical infrastructure behind it, without having to keep a dedicated performance testing team on the payroll for every load check.

Performance problems start long before anything fails

A full outage is simply the most visible form of poor performance. Long before that point, response times creep up, database queries get slower, and individual services start consuming more and more resources.

Without deliberate measurement, none of that is easy to spot. A performance check creates a reproducible benchmark: how does the same software behave under 100, 1,000 or 10,000 concurrent users? At what point does responsiveness drop off? And which component is causing the delay?

Why poor performance lands directly on developers

When a bottleneck only surfaces shortly before go-live, or worse, is reported by customers, the cost of finding it rises sharply. Developers then have to work out under time pressure whether the code, the database, the infrastructure or a connected service is responsible.

Performance tests planned in early produce measurements that can be tied to specific versions and specific changes. Optimisations can then be verified by re-running the tests instead of merely assumed.

From slow page loads to full system failure

Not every performance problem ends in a crash. More often, the user experience degrades first: pages render more slowly, an app feels sluggish, a process takes noticeably longer than it used to.

End users rarely care about the technical cause. All they experience is a website or application that responds badly. Repeat that often enough and customer satisfaction suffers, and with it the perception of the brand.

What is performance testing?

Performance testing belongs to the non-functional test types. The question is not whether a function returns the right result, but how the system behaves under defined conditions. At QualityOne, our focus is firmly on responsiveness and stability under load.

To get there, artificial load is generated and the software response is measured. Depending on the objective, different load scenarios and test methods come into play.

Performance check: how capable is the application really?

A performance check starts by establishing the current state. Measurable requirements are defined, then typical processes are executed under a specified load.

An example: a search request should return a result within two seconds in at least 95 per cent of cases with 500 concurrent users. Only with a target like that can the results later be judged meaningfully.

Performance tests measure more than raw speed

Average response time is one figure among many. Peak values, error rates, throughput and resource usage matter just as much.

A system might return fast responses while only a handful of users are active, yet consume disproportionately more memory as load increases. Performance tests make relationships like that visible.

Which measurements actually tell you something about performance?

A useful measurement combines values from several layers. That is the only way to tell whether the bottleneck sits in the application itself, in the infrastructure, or somewhere on the way to the user.

Response and load times from the user perspective

Response times measure things like the duration of an API request or a transaction. Browser applications add further values and further potential failure points, because rendering, JavaScript and lazily loaded content all shape perceived speed. Timeouts and loading errors that only occur while the browser renders have to be accounted for as well. Standardised frontend metrics such as the Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint or Cumulative Layout Shift, for example) play a central role here. For web applications in particular, backend performance and actual browser behaviour should be treated separately. Modern tools such as k6 support browser-based measurement alongside protocol-level testing.

Putting throughput, transactions and load in context

Throughput shows how many requests or transactions a system handles within a given period. The figure becomes genuinely interesting when it is read alongside rising load.

If throughput stays more or less flat while additional users arrive and response times climb, that is a strong signal that some resource has hit its capacity limit.

Resource usage on servers and in the application

CPU utilisation, memory, database connections, network traffic and thread pools all point towards the reasons performance is dropping. Monitoring tools therefore complement the figures produced by the load generator itself.

Developers then see more than the fact that a request suddenly takes five seconds. They can also check what was happening inside the system during that window.

Service level agreements as measurable targets

Service level agreements can set out concrete requirements for availability and performance. Internal targets or technical acceptance criteria work just as well as a basis. A performance test needs thresholds like these to deliver a clear verdict. Without them it still produces data, but no unambiguous pass or fail statement about whether performance meets expectations. To create a binding basis for everyone involved, one rule applies: performance specifications belong in a documented test plan.

The main test types in performance testing

Not every load check pursues the same goal. The various types differ mainly in how hard and how long they push the system.

Load testing: what load tests reveal about normal traffic

Load testing confronts the application with an expected or gradually increasing volume of traffic. Developers learn from it whether the system stays within its defined performance targets even with many concurrent users.

At QualityOne we use load tests to expose capacity limits and weak points in the application, database, hardware and network infrastructure early.

Stress testing: behaviour under exceptionally high load

Stress testing pushes the system beyond normal operating levels and examines stability and behaviour under exceptional load. Such a test may deliberately provoke a server shutdown, for instance as a protective mechanism so that overload does not expose security gaps. Afterwards, the test checks whether the system restarts safely and returns to a stable state on its own. If the aim is to identify the maximum capacity or breaking point specifically, a breakpoint test can be added.

Spike tests: what happens when load jumps suddenly?

Spike tests do not ramp load up gradually; they create abrupt jumps. A typical use case is a sales campaign that sends very large numbers of users to a website within minutes of launching.

The test shows, among other things, how quickly autoscaling, queues or other protective mechanisms respond to the sudden peak.

Endurance testing and soak tests for sustained load

Some performance problems only appear after long periods of operation. Endurance testing, or soak testing, therefore subjects the application to constant or realistically fluctuating load over an extended period. That reveals whether the system stays stable in continuous operation.

Slow-burning problems that shorter tests never catch come to light this way: memory leaks, growing queues, or connections that are never properly released.

Scalability and capacity testing: how far can the system grow?

Scalability testing asks how effectively additional resources translate into additional performance. If server capacity is doubled, for example, the effect on throughput and response times should be traceable.

A capacity test looks more closely at the available capacity itself: how many users, transactions or volumes of data can the current system handle before the defined thresholds are breached?

What do performance tests give developers?

Measurable results shorten the hunt for performance problems. Instead of optimising components on a hunch, developers can start where tests and monitoring show something unusual.

Catching bottlenecks before they get expensive in production

A slow database query may barely register with ten test users. Under heavy load, the same query can block hundreds of parallel processes.

Load tests create those conditions in a controlled way. Developers can then investigate which queries, services or resources hit their limits first.

Testing microservice performance separately and together

With microservices, a single transaction is usually spread across several components. A slow response therefore need not originate in the service the user is talking to directly. Performance testing can examine individual APIs in isolation and then complete process chains. That shows whether the problem lies with one microservice or in the interplay between several systems. Identifying slow endpoints improves the user experience, because those bottlenecks can be optimised before they hold up the entire transaction.

Exposing memory leaks and creeping resource consumption

Memory leaks rarely announce themselves. Memory usage grows step by step until the application eventually slows down or becomes unstable.

Longer-running tests create the conditions in which that pattern becomes visible. The same applies to connection pools, threads and other finite resources.

Assessing performance from the end user perspective

Backend measurements alone do not capture the full user experience. Browser-based tests can therefore examine how an application behaves from an end user point of view.

This form of testing connects technical performance with user experience: under the simulated conditions, how long does someone actually wait before the content they need is visible and usable?

Shift-left: performance testing inside CI/CD and DevOps

Performance does not have to be checked exclusively in large load tests shortly before a release. The recommendation is clear: performance tests should run repeatedly throughout development and should be mandatory before every new deployment. Smaller, faster tests make that possible early on. This approach, known as shift-left performance testing, moves quality checks further forward in the development cycle.

CI/CD: do not leave performance testing until release week

Inside a CI/CD pipeline, selected performance tests can run automatically after builds or changes. That provides continuous verification of key endpoints and processes.

Tools such as k6 offer explicit CI/CD integrations; JMeter can likewise be wired into continuous integration workflows through the appropriate build and integration tooling.

Performance baselines make change visible

A single measurement says very little without something to compare it against. Baselines provide that reference point.

If an API averaged 180 milliseconds in version 1.8 and suddenly needs 310 milliseconds after a change, the regression is visible, even when both figures still sit below a formal threshold.

Performance checks before go-live

Ahead of major releases, migrations or heavily promoted product launches, more extensive load tests are worth the effort. The question here is less about each individual commit and more about whether the system as a whole is ready for the conditions it will face.

A test like that should use realistic load profiles and infrastructure as close to production as possible.

Building a realistic performance testing environment

How much a test is worth depends heavily on the environment it runs in. A small test system can behave completely differently from a distributed production architecture. For consistent, reproducible results, a controlled and ideally separate test environment is usually the right answer.

Load scenarios from real life, not arbitrary user counts

"10,000 users" is not yet a usable load model. In reality, people use different features and generate very different amounts of load. A realistic model therefore reflects typical use cases: some users log in, others search for products, download data or complete transactions. The result is a load profile that comes much closer to actual usage.

Caching is the classic trap here. If a load test keeps firing identical requests with identical test data, caching layers at various levels can serve an unrealistically high proportion of them. Sensible parameterisation and sufficiently varied test data prevent the test from mostly measuring cache performance instead of real system behaviour.

How close does the test environment need to be to production?

A performance testing environment does not have to be a complete copy of the production environment. The relevant differences do, however, need to be known.

Less CPU, smaller databases or different network capacity all change the result. Those deviations must be factored into the interpretation rather than transferring test figures to production unchecked.

Monitoring tools show where the bottleneck forms

The load generator describes the effect; monitoring helps find the cause. Both perspectives belong together.

Looking at rising response times alongside CPU figures, database metrics and memory usage makes it far quicker to attribute an anomaly to a specific system component.

Performance testing tools: which one fits the project?

The choice of performance testing tools ranges from established open source projects to extensive commercial platforms. Which one fits depends on architecture, protocols, test scope, degree of automation and the knowledge already available in the team.

Choosing tools by application and requirements

The first question is what actually needs to be put under load: HTTP APIs, microservices, a conventional website, databases, or complete browser journeys.

Then come the questions of required load, CI/CD integration, reporting and collaboration between developers and performance testers. A record-and-replay capability can also help when building certain flows.

Open source tools: JMeter and k6 for performance testing

Apache JMeter is an open source tool for generating load and measuring performance. Alongside HTTP and HTTPS, and therefore REST and SOAP web services, JMeter supports JDBC, JMS, FTP and a range of further protocols and interfaces. Web journeys can be recorded and then developed into repeatable test plans; large load tests are normally executed in CLI mode.

k6 is likewise open source and firmly oriented towards developer workflows. Tests are written as scripts; beyond conventional load tests, k6 supports stress, spike and soak scenarios as well as browser-based performance measurement and CI/CD integration.

Performance engineering instead of performance repair

Anyone who only goes looking for performance problems after an outage is doing damage control. Performance engineering starts earlier. Involving the performance testing team early can lower the cost of fixes, because architecture and design weaknesses are usually far easier to correct in the early phases of development.

Treating performance across the full development lifecycle (SDLC)

The industry term for this is the Software Development Life Cycle (SDLC). Performance requirements can be considered as early as architecture and design. Smaller measurements follow during development, larger load tests later, and monitoring once the system is live. The result is a continuous view of how the system performs. DevOps teams can track changes across multiple versions and catch deviations sooner.

Use cases determine how much performance is actually needed

Not every piece of software needs the same performance figures. An internal administration system with 50 users has very different requirements from a public customer portal handling several thousand concurrent sessions.

The form and frequency of use matter too. The goal is therefore not "maximum performance" but performance that matches the actual requirements and load scenarios.

Running performance tests with TaaS from QualityOne

Performance testing calls for specialist know-how, the right tools and enough resources to generate realistic load and interpret the results properly. Simply reaching for conventional test automation (TA) does not work in practice. The technical approach in performance testing is fundamentally different, because TA is primarily focused on the user interface (UI/GUI). This is exactly where our TaaS model (Testing as a Service) at QualityOne comes in, with performance testing as one of its core building blocks.

Why TaaS is such a good fit for performance testing

Many companies do not need extensive load tests every day. Permanently maintaining an in-house performance testing team with specialist tooling knowledge and the matching test infrastructure can therefore be out of all proportion. At the same time, high load levels raise the question of the load generation infrastructure itself: depending on the tool, the test script and the hardware, the CPU, memory or network throughput of the load generator can become the bottleneck and distort the measurements.

If a single instance is not enough for the planned load scenario, the load can be distributed across multiple generators. Distributed testing, whether local, remote or across cloud infrastructure, makes it possible to model even large load scenarios in a controlled and scalable way.

TaaS lets you bring in exactly that specialist capacity on a per-project basis. The internal team can concentrate on development and technical optimisation while QualityOne plans, executes and evaluates the agreed test activities. Which tools, load profiles and test infrastructure are used depends on the requirements of the individual project.

From requirement to result: performance testing with QualityOne

It starts with the question of what load an application genuinely has to handle in practice. From there, concrete objectives, test types and load profiles can be derived.

The next step is to define the right test environment, implement the scenario and raise the load under control. We then analyse response times, resource usage, error rates and further measurements in detail to give a well-founded assessment of the responsiveness, stability and capacity limits of the system.

Developers and the performance testing team work from the same results

The TaaS model does not take responsibility for code and architecture away from developers. Its value lies in providing reliable, reproducible findings.

Our performance testing team can document precisely that beyond a certain number of parallel transactions the response time of a service climbs sharply, or that the database becomes the bottleneck. Developers can then optimise with purpose. A repeat test shows whether the change actually delivered an improvement.

The performance test stops being an external verdict and becomes an agile, technical feedback loop between testing and development.

Conclusion: performance testing gives developers data instead of guesswork

Good performance cannot be inferred from clean code alone. Only under realistic conditions does it become clear how software copes with growing load, many concurrent users and large volumes of data. Load testing, stress testing, spike tests, soak tests and the other test types expose different capacity limits and give developers concrete starting points for optimisation.

Integrating performance checks into CI/CD and DevOps workflows as part of a shift-left approach means degradation is caught during development. Larger load tests before go-live complement that continuous control and confirm whether the system as a whole is ready for the intended operation.

With its TaaS model, QualityOne enables companies to plug performance testing into existing development workflows exactly where it is needed. Developers gain additional testing expertise, cloud-based load infrastructure and transparent assessments without having to build every one of those resources in-house. QualityOne takes on the test activities that fit the project; the development team receives the precise measurements it needs to analyse bottlenecks and verify improvements.

FAQ on performance testing

Can performance tests include external APIs and third-party systems?

Technically yes, although load should never be generated against external systems without checking first. Third-party providers may enforce rate limits or restrict load testing contractually. In such cases, external services can often be simulated or replaced by test systems (mocking). Which systems may be put under load should be clarified during planning.

How do location and network connection affect performance tests?

Latency, bandwidth and geographical distance can influence perceived performance considerably. For applications used internationally it is therefore essential to generate load from different regions (distributed testing) or to simulate varying network conditions. That gives a much better picture of the response times users in different locations actually experience.

How much test data is needed for realistic performance tests?

That depends heavily on the application. A database holding a few hundred records can return very different response times from a system with several million. Beyond sheer volume, the structure of the data and a high degree of variance matter too, in order to avoid caching effects. If large volumes are typical for production, test planning has to reflect that.

Can a load test simply be run against a public production system?

Strongly discouraged without prior agreement. A load test can affect real users, trigger automated protection systems such as DDoS mitigation, or in the worst case cause an outage itself. Add to that the possible impact on connected services and usage-based infrastructure costs. Tests in the production environment should therefore be prepared technically and organisationally, and clearly bounded, for example by running them during quiet traffic periods.