How to Define the Scope of Load Testing for Enterprise Web Software

Defining the scope of load testing for enterprise web software involves much more than estimating how many users may connect at the same time. In a dealer portal, hundreds of people browsing products may generate less pressure than a smaller group submitting bulk orders to an ERP system. Likewise, viewing a document, exporting a large report and creating a payment record place very different demands on the application, database and connected services.

A credible scope combines business-critical journeys, expected transaction rates, data volume, user behaviour, external dependencies and acceptable performance limits. The objective is not simply to keep the system running under heavy traffic. It is to establish when and why it slows down, how it fails and whether it recovers after demand falls. Load testing should therefore be treated as technical evidence for architecture and capacity planning—not as a one-off traffic exercise immediately before launch.

Define the Purpose of Load Testing Through Business Risk

The first scoping question should not be “How many users will we test?” but “Which business disruption do we need to expose before release?” An order failing to reach the ERP, a customer being unable to access an invoice, a dealer being unable to open a price list and an operations team being unable to generate a report have different consequences. Priorities should reflect the potential effect on revenue, operational continuity, customer experience and data integrity.

For each important journey, record its owner, frequency, busiest period, failure impact and any temporary workaround. Product search may be used constantly, while order approval may occur less often but carry substantially greater business risk. This distinction directs the test budget towards meaningful risks and prevents every screen from being tested to the same depth without justification.

If roles, data ownership and integration requirements remain unclear, begin by modelling the scope of custom web software development. A realistic performance scenario cannot be built from an ambiguous business process.

How Should Critical User Journeys and the Transaction Mix Be Identified?

Load tests should represent end-to-end business journeys rather than isolated pages. In B2B commerce, sign-in, product and stock lookup, adding items to a basket, calculating customer-specific prices, creating an order and transferring it to the ERP can be monitored as separate steps. In a customer portal, key journeys may include viewing an account summary, downloading documents, opening a service request and sending a notification. Filtered reports and file exports may also belong in scope because of their resource cost, even when administrator traffic is relatively low.

Next, create a transaction mix from production evidence or reliable business forecasts. What proportion of sessions only reads information, and how many involve search, record creation, file upload or reporting? How long do users pause between steps? How are sessions divided between roles, devices and locations? These questions produce a workload closer to real behaviour than an artificial scenario in which every virtual user repeats the same action continuously.

The Grafana k6 guide to website load testing explains that component and end-to-end tests serve different purposes and that protocol-based, browser-based or hybrid testing should be selected according to the objective. In enterprise projects, most traffic can often be generated efficiently at API level, while a smaller number of experience-critical journeys are measured in real browsers.

How to Define Load Testing Scope in Six Steps

A practical scope can be developed through the following sequence. Each step supplies measurable input for the next, keeping user numbers, scenarios and performance targets connected.

1. Rank business-critical processes

Identify journeys that matter to revenue, service continuity, regulatory obligations or operational efficiency. For each journey, document the user role, starting condition, completion condition, expected business result and impact of failure. Expand coverage from the highest-risk journeys rather than beginning with whichever screens are easiest to automate.

2. Build the production workload model

Concurrent sessions alone are insufficient. Include transactions per minute or hour, request arrival rate, session duration, user think time, transaction mix and distribution throughout the day. For an existing system, use analytics, application logs and monitoring data. For a new product, label estimates from sales, operations and IT teams as assumptions, then update them once real usage data becomes available.

3. Add data and integration conditions

A query that performs well against a small, clean dataset may behave very differently against years of orders. Define production-representative volumes for products, customers, prices, documents and transaction history. For ERP, CRM, payment, logistics and notification services, include quotas, timeouts, caching, queues and retry behaviour. Record which dependencies are real and which are simulated.

4. Select traffic profiles

Normal load establishes a baseline; peak load represents an expected busy period; spike testing examines a sudden rise; and endurance testing reveals resource accumulation over time. A controlled stress test can be used when the capacity boundary and recovery behaviour matter. Not every project requires every profile at the same scale—the selection should follow the business risk and architecture.

5. Write acceptance and stop criteria

Evaluate response times with percentiles that represent the experience of most users, rather than relying only on an average. Set thresholds for successful business transactions, timeouts, business-rule errors, queue delay and resource utilisation. Define safety conditions that stop the test if error rates rise sharply, data consistency is threatened or a critical service is placed at risk.

6. Complete the monitoring, evidence and repeatability plan

A result report should contain more than output from the load generator. Correlate application and API timings with database queries, connection pools, queues, caches, CPU, memory, disk and external-service latency on the same timeline. Record the scenario version, dataset, environment configuration and software release so that the test can be reproduced and compared later.

Why Is Concurrent User Count Not Enough?

Concurrency is useful, but it does not directly describe the load created. Hundreds of open sessions may generate little demand if most users are reading. A much smaller group may create heavier pressure by uploading large spreadsheets, requesting dynamic pricing, exporting reports or sending orders to an ERP.

The scope should therefore pair concurrent-user estimates with transactions per second or minute, role distribution, request types, payload sizes and think times. It should also distinguish open and closed workload models. One model simulates the behaviour of a fixed number of virtual users; another maintains a target arrival rate regardless of response time. The correct choice depends on actual traffic behaviour and the question the test must answer.

How Should Data Scale and ERP/API Dependencies Be Included?

Enterprise software performance rarely depends on the web server alone. Permission checks, customer-specific prices, stock availability and historical transactions may invoke different tables or services. Test data should reproduce the scale and distribution characteristics of production without copying real personal data. A test with a few products, one currency and a short order history can create misleading confidence.

ERP and API testing may use real services in a controlled environment, service doubles or a combination of both. The report must state what was real and what was simulated. Quotas, slow responses, partial failures, retry storms and queue backlogs should be tested deliberately. Relevant ERP workflows and responsibilities can also be aligned with Kumsal Agency’s enterprise resource planning services.

Test records must also cover meaningful variation: active and inactive customers, different permission sets, large and small orders, common and uncommon search terms, multiple currencies and both warm and cold cache conditions. Otherwise, a technically large dataset may still fail to represent the expensive paths found in real operations.

Which Question Does Each Load Scenario Answer?

A single high-traffic run cannot distinguish between different performance risks. First verify scripts, test data and monitoring at low load. Then run normal, peak, spike, endurance and—when justified—stress scenarios for separate purposes. The AWS Distributed Load Testing solution overview describes a distributed approach that can run different scenarios and regions concurrently. That scale should be introduced only through controlled planning with the target-system, test-environment and external-service owners.

• Smoke test: Confirms that scripts, test data and the basic monitoring chain work correctly under low load.
• Normal load test: Establishes baseline performance for the expected everyday transaction mix.
• Peak load test: Evaluates predictable busy periods such as campaigns, month-end processing or order cut-off times.
• Spike test: Examines scaling, rate limits and queue behaviour when traffic rises rapidly.
• Endurance test: Looks for memory, connection or queue accumulation during sustained demand.
• Stress test: Finds the capacity boundary under controlled conditions and observes recovery after load falls.

How Should Measurable Acceptance Criteria Be Written?

“The system must be fast” is not testable. For every critical transaction, define response-time percentiles, successful completion rate, timeout limits and the correctness of the business outcome under the target load. It is not enough for the order screen to respond quickly: the order must be created once, reach the ERP within the agreed window and display the correct status to the user.

Technical metrics should be linked to business outcomes. Queue delay affects how long a user sees “processing,” while database locks may prevent concurrent orders from completing. Thresholds should not be copied from generic benchmarks. They should reflect user expectations, an observed baseline, service objectives and the capacity of the chosen architecture.

Microsoft Azure Well-Architected testing guidance explains that load and performance tests should validate latency, throughput and scalability under expected workloads, and that production-like environments improve confidence. Where environments differ, results must not be presented as a guarantee of production capacity.

Test Environment, Observability and Safe Execution

Record the application release, infrastructure size, network topology, data volume, cache state and integration configuration. If production parity is impossible, explain how each difference may influence the results. The capacity and location of load-generating machines must not become an unnoticed bottleneck.

Before execution, identify responsible teams, the approved test window, test-data cleanup procedures and who can trigger an emergency stop. Any controlled production test requires conservative load, suitable timing, isolation and a rollback plan. Test accounts must not create genuine orders, payments, emails or shipments.

Monitoring should continue after traffic falls. Confirm that resources return to normal, queues drain, failed transactions are handled and automatically scaled components stabilise. Record each finding with its symptom, evidence, likely cause, business impact and proposed action so the development and operations teams can act on it.

When Should Load Testing Be Repeated?

Load testing is not a one-time approval. Relevant scenarios should be rerun when critical journeys, data models, queries, caches, ERP integrations, infrastructure capacity or deployment architecture change. High-risk baseline scenarios can become controlled quality gates in the release pipeline, helping teams detect performance regressions earlier.

Keep scenario, dataset and environment versions stable when comparing results. If a change is unavoidable, establish a new baseline instead of treating unlike results as a trend. After release, compare forecasts with real usage and update the transaction mix and traffic profiles. The test suite then evolves into a living capacity model as the product grows.

A Practical Scope Deliverable for Enterprise Web Software

A useful scope document includes the business objective, critical journeys, user roles, transaction mix, load profiles, data scale, dependency behaviour, environment differences, monitored metrics, acceptance and stop criteria, and reporting responsibilities. It turns “How many users can the system handle?” from an unsupported capacity promise into a technical decision that can be verified under stated conditions.

Kumsal Agency designs and develops enterprise web software around real business processes, user roles, data flows and ERP connections. To evaluate your critical transactions, expected traffic, transaction volume, ERP/API dependencies and performance targets—and create a load testing scope based on realistic usage scenarios—contact Kumsal Agency.