Keeping your business current means making sure customers can access your websites, applications, and digital services without delays or failures. As more organizations rely on web and mobile applications, software quality is no longer only about whether features work. Applications also need to perform reliably when real users, traffic spikes, third-party services, and infrastructure limits are involved.
Performance testing helps uncover bottlenecks before they affect users, but the test itself needs structure. Before running a performance test, teams should define what must be ready. After the test, they should define what results are required for the test to be considered complete. These are known as performance testing entry and exit criteria.
What Is Performance Testing?
Performance testing is a set of testing methods used to evaluate how a website, application, API, or system behaves under different conditions. It helps teams understand speed, stability, scalability, response time, throughput, error rates, and resource usage.
Everyday users may not think about performance testing, but they feel the results. When a page loads slowly, a checkout times out, a search hangs, or an application becomes unavailable, the user experience suffers. Performance testing helps development, QA, DevOps, and infrastructure teams identify problems early so they can improve uptime, availability, and responsiveness.
Kinds of Performance Testing
When teams evaluate application performance, they may use several types of tests depending on the goal:
- Endurance Testing
- Load Testing
- Scalability Testing
- Spike Testing
- Stress Testing
- Volume Testing
Each method answers a different question. Load testing shows how the application behaves under expected traffic. Stress testing identifies failure points. Spike testing measures sudden traffic changes. Endurance testing reveals long-running issues such as memory leaks or resource exhaustion.
Performance Testing Strategy
Performance testing requires a clear strategy. The strategy defines the scope, workload model, test environments, Service Level Objectives (SLOs), Service Level Agreements (SLAs), tools, metrics, and responsibilities. A strong strategy usually includes the following stages.
Stage 1: Planning
Testing Vision
Start by defining why performance testing is being done and what outcomes are expected. Input from development, QA, DevOps, product, support, and business teams can help refine the test plan and identify critical workflows that should be included.
Situational Analysis
Once the goal is clear, review the current state of the application. Understand known issues, traffic patterns, recent incidents, infrastructure constraints, upcoming releases, and business targets.
Set Objectives
Define specific objectives for the test. These may include response time targets, error-rate limits, throughput goals, concurrent user levels, transaction completion rates, or infrastructure thresholds. Clear objectives lead to better test results.
Understand Limits
Not every part of an application needs the same level of testing. Define what is in scope, what is out of scope, and what should not be touched during the test. This is especially important for production-like environments, payment flows, third-party APIs, and sensitive data.
Stage 2: Evaluating the Testing Environment
Software Specifications
Review the application’s current features, architecture, dependencies, and performance requirements. Decide which performance testing types should be used first. For example, a team might begin with load testing, then move to spike testing, endurance testing, or stress testing depending on the goal. Some teams choose LoadView Professional Services to help design a testing strategy and execute more complex performance tests.
Tool Selection
Choose the right tools, procedures, and reporting approach. For example, LoadView is web-based, so teams do not need to manage additional load generation hardware. The platform provides features for testing advanced applications, including real browser testing, load curves, and geographic load generation. Choosing the wrong tool can extend the testing period, create unreliable results, and waste resources.
Stage 3: Choosing the Right Parameters and Metrics
Performance testing metrics help reveal the root cause of slowdowns or failures. Common metrics include:
- Response time
- Throughput
- Error rate
- Concurrent users
- Requests per second
- Bandwidth
- CPU usage
- Memory usage
- Database performance
- Queue depth
- Apdex or user-experience score, when available
At this stage, teams decide which metrics matter most for the application and how those metrics will be collected during the test.
Stage 4: Execution and Collection of Results
The final stage is defining how test scripts will be created, how scenarios will be executed, and how results will be collected. Teams should document the test schedule, roles, monitoring setup, test data, reporting format, and decision process for identifying bottlenecks or accepting the results.
How to Write Performance Testing Plans
Performance testing strategies and performance testing plans are related, but they are not the same thing. A strategy defines the overall approach. A performance test plan provides a detailed view of the scope, objectives, scenarios, tools, schedule, risks, entry criteria, exit criteria, and deliverables for a specific test effort.
Testing Objectives
The plan should define objectives in detail. Objectives may be based on change requests, performance requirements, traffic forecasts, business goals, or workload expectations. For high-traffic applications, objectives may include response time targets, transaction rates, concurrent users, throughput, and acceptable error rates under normal and peak load.
Test Scope
This section defines which testing types and workflows are included. For example, you might select load testing and volume testing while excluding spike testing for a specific release. The scope should be based on risk, application behavior, business priority, and known performance concerns, not guesswork.
Testing Techniques
This is one of the most important parts of the performance testing plan. It defines test locations, scripts, scenarios, timing, validation rules, workload model, user behavior, performance testing tools, testing environments, and monitoring methods. It should also explain how errors, failed transactions, bottlenecks, and test documentation will be handled.
Test Schedule
The schedule defines when performance testing starts and ends, when results are reviewed, when fixes are expected, and when retesting will occur.
Entry and Exit Criteria
Entry criteria define what must be ready before the performance test can start. Exit criteria define what must be completed before the test can be considered finished. This section should also identify the individuals or teams responsible for approving readiness, executing the test, monitoring the environment, reviewing results, and approving closure.
Risks and Risk Management
Performance testing plans should account for risks such as environment instability, missing test data, third-party dependency limits, monitoring gaps, unavailable team members, production conflicts, or infrastructure restrictions. The plan should explain how these risks will be handled.
Deliverables
Deliverables may include test scripts, test data, reports, dashboards, bottleneck analysis, tuning recommendations, meeting notes, sign-off documents, or retest results. Each deliverable should have an owner.
Software Testing Life Cycle Explained
The Software Testing Life Cycle, or STLC, is a set of activities performed by testing teams to help ensure software quality. It is part of the broader Software Development Life Cycle, or SDLC, but focuses specifically on testing activities. STLC helps teams define scope, test cases, entry criteria, exit criteria, environments, execution steps, and closure documentation.
Software Testing Life Cycle Phases
The STLC often includes six phases, although the exact process may vary depending on the application and organization.
Phase 1: Requirement Analysis
The team reviews requirements and identifies what needs to be tested.
Phase 2: Test Planning
The team defines the test strategy, schedule, resources, tools, risks, and techniques.
Phase 3: Test Case Development
Testers create test cases, scripts, scenarios, and test data based on scope and criteria.
Phase 4: Test Environment Setup
The team prepares the environment, tools, monitoring, access, data, integrations, and dependencies needed for testing.
Phase 5: Test Execution
Tests are executed, results are reviewed, and defects or bottlenecks are documented.
Phase 6: Test Closure
Results, reports, metrics, defects, lessons learned, and sign-off decisions are documented and shared with stakeholders.
What Are Performance Testing Entry and Exit Criteria?
Performance testing entry criteria are the conditions that must be satisfied before testing begins. These conditions may include approved requirements, a stable test environment, working monitoring tools, available test data, stakeholder sign-off, and clear test objectives.
Performance testing exit criteria are the conditions that must be satisfied after testing is complete. These may include completed test execution, documented results, resolved or accepted bottlenecks, stakeholder review, and confirmation that performance goals were met or that next steps were agreed upon.
Teams should not begin performance testing until entry and exit criteria are defined. Without clear criteria, it becomes difficult to know whether the test was valid, whether the results are acceptable, or whether more testing is needed.
Requirements for Performance Testing Entry Criteria
The following are common requirements for performance testing entry criteria.
Clear and Approved Requirements
Before running the test, define the objectives and review them with application owners and stakeholders. Requirements should be documented and approved so everyone understands what is being tested and why.
Selection of Performance Test Type
The team should choose the type of performance testing to apply, such as load testing, stress testing, spike testing, endurance testing, or scalability testing.
Software Stability
The application should be stable enough for performance testing. Unexpected code, configuration, or environment changes during the test can invalidate results. If changes are required for comparison, they should be controlled and documented.
Dedicated Setup and Testing Environment
The required resources should be available before testing begins. This includes the test environment, monitoring tools, access credentials, test data, network access, and load generation setup. Platforms like LoadView can help simplify load generation, but the application environment still needs to be prepared.
Monitoring Team
Performance testing should have assigned owners for monitoring, troubleshooting, and decision-making during the test. The team should know who can pause, stop, reset, or escalate issues if something goes wrong.
Backup and Restoration Plan
Before testing, confirm that databases, configurations, and critical data can be restored if needed. This is especially important when testing environments use shared data, production-like data, or workflows that modify records.
Plan for Handling Problems
Teams should decide how performance issues will be handled. Some tests are intended only to identify and classify bottlenecks, while others include tuning and retesting. The plan should clarify whether the team will fix issues immediately, document them for later, or stop the test when certain thresholds are reached.
Requirements for Performance Testing Exit Criteria
Once performance testing is complete, the following exit criteria help determine whether the test effort can be closed.
Performance Testing Completion
All planned scenarios should be executed, or any skipped scenarios should be documented with a reason. Stakeholders should be informed that test execution is complete.
Assessment Against Requirements
Results should be compared against the requirements, SLOs, SLAs, and objectives defined in the test plan. The team should keep evidence showing whether the application met the agreed criteria.
Documenting Defects and Bottlenecks
All relevant performance issues should be documented. This includes slow transactions, failed requests, errors, resource bottlenecks, environment issues, third-party failures, and monitoring gaps.
Fixing or Accepting Bottlenecks
Performance testing is intended to uncover issues that may affect users. Once bottlenecks are identified, teams should either fix them, accept the risk, or document follow-up work with clear ownership.
Meeting Performance Goals
The test should confirm whether the application met the goals defined in the performance strategy and plan. If objectives were not achieved, the team may need to tune the application, adjust infrastructure, refine the test, and retest.
Final Report and Sign-Off
The final report should summarize test scenarios, workload model, results, bottlenecks, fixes, unresolved risks, and recommendations. Stakeholders should review the report and decide whether the application is ready to proceed.
Conclusion: Performance Testing Entry and Exit Criteria
Performance testing strategy, planning, STLC, and entry and exit criteria all work together. You should not run a performance test without first defining what must be ready, what success looks like, who is responsible, and what happens after results are collected.
Clear entry criteria help ensure the test is valid. Clear exit criteria help determine whether the application met performance goals and whether additional tuning or retesting is required. When these criteria are documented upfront, teams get more reliable results and make better release decisions.
If you are preparing to run performance tests for your web pages or applications and want help building a realistic plan, you can schedule a demo with one of our performance engineers. They can help you understand the LoadView platform and our performance testing services. You can also sign up for the free trial to try the platform yourself, or contact us with questions.