Software capacity testing asks what workload a particular system configuration can sustain while meeting agreed service objectives. The answer is conditional on the work performed, data, environment and duration. A single concurrent-user number does not describe those conditions.
Start with a decision: whether an expected workload is supported, whether a sudden increase can be handled or which limit needs investigation. This guide helps you prepare the evidence. It does not report a Visuosofts benchmark or authorise testing a live system.
Describe the work behind the user count
A person browsing cached information creates different demands from someone saving a large record or requesting a report. List the important journeys, their sequence and the mix of reads, writes and background work. Note pauses, payload sizes, data history, permissions and external calls.
Use observed demand where it is available, with its date and limitations. If demand is an assumption, label it. Do not turn registered accounts into concurrent sessions or treat every session as a continuous stream of identical requests.
Consider how work arrives. Grafana's explanation of open and closed load models distinguishes work scheduled independently of completion from iterations that wait for the previous one. In a closed model, slower responses can reduce the rate at which new work starts. That matters if the question assumes incoming demand will continue despite a slowdown.
Make the environment identifiable
Record the application build, runtime, database version, service configuration and resource limits. Include connection pools, scheduled work, cache state and relevant provider quotas. Record the load generator's configuration as well as the system being tested.
Use synthetic data that represents the important shapes: long histories, larger attachments, uncommon states and competing updates where relevant. A small set of tidy records may exercise a different workload from the one the business expects.
Document substitutions such as a simulated payment provider or disabled messaging service. A substitute can help isolate a question, but passing against it is not evidence of the real provider's throughput or behaviour. The cloud readiness guide covers the surrounding dependencies and operational responsibilities.
Write a capacity test charter
Before choosing a tool, fill in a short record that another reviewer can understand:
- Decision and owner
- What decision will the evidence support, and who can accept the remaining uncertainty?
- Candidate and workload
- Identify the build, configuration, fixture, journeys, arrival model and expected mix of work.
- Boundaries
- Name the authorised environment, excluded services, maximum duration and resource or spend limits.
- Objectives and observations
- Define the relevant latency, error, completed-operation and recovery measures. Record why their acceptance conditions fit the business task.
- Safety and stop rules
- State who can stop the run, what observations require stopping and how to prevent real notifications, payments or other external effects.
- Evidence and review
- Identify retained logs, measurement windows, configuration records and the person who checks the conclusion.
Keep resource safety limits distinct from performance acceptance conditions. A run stopped to protect its environment has not established a passing capacity limit. Missing observations should produce an inconclusive result, not an assumed pass.
Choose a load shape for the question
Grafana's test-type guidance distinguishes expected-load, stress, soak, spike and breakpoint investigations. These ask different questions: ordinary demand, higher load, sustained operation, sudden changes and limits. Start by checking that the test itself works under a small workload before increasing its demands.
Choose the relevant patterns rather than running every category by habit. Set durations and ceilings for the authorised environment; a tool's example settings are not a universal production requirement. Passing a short run cannot establish behaviour during prolonged operation, and a long steady run does not establish response to a sudden burst.
Observe outcomes as well as response times
Keep intended demand, work actually started and work completed separate. Record rejected, timed-out, interrupted and unstarted work rather than excluding it from the conclusion. A reported success response may acknowledge a queued task without proving that its business operation finished.
Inspect latency distributions for the important operations, not just one average across unlike requests. A percentile describes the measured sample; it does not guarantee that every future request will fall within that value. Record the sampling period and volume so a reviewer can judge what the observation represents.
k6 thresholds are one way to encode test-specific pass/fail conditions. Define those conditions for the actual service rather than copying illustrative percentages or response times from documentation.
Watch the generator and dependencies too. If the generator cannot create the intended demand, the run may say more about the test equipment than the application. If a dependency rejects requests, identify that boundary rather than attributing every failure to application code.
Hypothetical exercise: booking while dispatch runs
A fictional repair-booking service needs to assess interactive searches and new bookings while a dispatch job processes existing work. The team creates synthetic customers and appointment histories in an isolated environment. Real notifications are disabled, and downstream dispatch is replaced with a controlled substitute.
The charter describes the search-to-booking mix, expected arrival pattern and concurrent background task. It also names the acceptable booking outcome: an accepted request must correspond to the intended stored booking, without duplicates. The team agrees the response, error and queue conditions before any run, rather than choosing favourable limits afterwards.
After checking the script at low load, the proposed exercise increases demand within the approved bounds and observes whether dispatch work accumulates. A follow-up observation after demand falls checks whether the queue drains and the service recovers. If the substitute cannot model a material dispatch constraint, that limitation remains explicit.
No results are claimed here. This is a planning example, not a test we performed, a customer case or evidence that a booking system supports any particular volume.
Turn the observations into a bounded conclusion
A useful result identifies the tested candidate, workload, duration, environment and objectives. State whether the evidence supports the intended decision, reveals a failure or remains inconclusive. Describe what was not exercised: a different data size, dependency plan, background job or access pattern may need another investigation.
If a limit appears, investigate and repeat a controlled comparison rather than changing several variables and assuming the cause is known. Record what changed and whether the original symptom returned. Do not extrapolate a small successful test into a production capacity promise without evidence supporting that inference.
Define rerun triggers such as a changed query, larger data history, revised connection limit or different dependency. Feed the findings into the release acceptance record and pass operational warnings to the team using the support handover guide.
Discuss workload requirements through Visuosofts application development, or contact the team with your critical journeys, observed demand and unanswered capacity questions. Do not send credentials or customer data with an initial enquiry.
Capacity testing questions
Is concurrent-user count enough to specify a test?
No. Define the actions, arrival pattern, pauses, data and background work represented by those users. Otherwise the same count can describe very different demands.
Does a passing test prove production capacity?
It supports a conclusion about the conditions exercised. Record environmental differences, excluded dependencies and workload assumptions before applying it to a production decision.
What if the generator cannot sustain the intended demand?
Record that limitation and distinguish intended from achieved load. Do not call the application capable of a demand the test did not actually deliver.
Should a test continue until the system breaks?
Only a specifically authorised investigation may explore limits, and it still needs bounded resources and stop rules. Many useful tests ask whether an expected workload meets its objectives without seeking a breaking point.
