Time to put everything together. In this exercise, you will write a complete performance test plan for the Banking Portal. This is not a fill-in-the-blanks exercise -- you will make real decisions about scope, workload, environment, and criteria, just like you would on a real project.
You are the performance test lead for a mid-size banking application. The app is currently live with 100,000 registered users and the business expects to grow to 250,000 users within the next year. A major release (v3.5) is planned that includes a new bill payment feature and a redesigned dashboard. Management wants to know: Can the system handle the expected growth after this release?
| Parameter | Value |
|---|---|
| Registered users (current) | 100,000 |
| Registered users (projected, 1 year) | 250,000 |
| Daily active users | 22,000 |
| Peak concurrent users (current) | 1,800 |
| Peak hour | 9:00 AM - 10:30 AM, weekdays |
| Average session duration | 3 minutes |
| Current production TPS at peak | 180 |
| SLA: Page response time | < 3 seconds (p95) |
| SLA: API response time | < 1.5 seconds (p95) |
| SLA: Error rate | < 0.5% |
| SLA: Availability | 99.9% |
| Database: total accounts | 100,000 |
| Database: total transactions | 25,000,000 |
| App servers (production) | 4x (4 vCPU, 16 GB RAM) |
| Database (production) | PostgreSQL on RDS r6g.xlarge |
| Third-party integrations | Payment gateway, SMS OTP, email service |
Write a complete performance test plan covering all 10 sections from the template we discussed. Here are the specific decisions you need to make:
There is no single "correct" answer for this exercise. Real performance test planning involves judgment calls. The important thing is that your decisions are justified and internally consistent. If you say the target is 4,500 concurrent users, you should be able to show the math: 250,000 users x 1.8% concurrency ratio (from current data: 1,800/100,000) = 4,500 users.
Does every number have a source or justification? No arbitrary numbers like "let us test with 1,000 users."
Are acceptance criteria specific and measurable? Not "should be fast" but "login p95 < 1,500ms at 4,500 concurrent users."
Is the test environment documented with a scaling factor? Can someone read the plan and set up the environment?
Does the test data section specify volume, variety, and cleanup? Will the data be ready before the first test run?
Is there a clear execution order (baseline first)? Does each phase have defined user counts and durations?
Are third-party integrations handled? Mocked with realistic latency?
Is the reporting section specific about format, audience, and timeline?
Did you include at least 3 risks with mitigation strategies?
Key Point: A complete performance test plan connects every number to a real-world justification -- no arbitrary user counts, no vague goals, no undocumented environment differences.
Answer all 8 questions, then submit to see your score.
1. What is the primary purpose of a performance test plan?
2. When gathering requirements for a performance test, which metric is MOST important to get from production data?
3. A test database has 500 rows while production has 10 million rows. What is the biggest risk?
4. What happens when you run 3,000 virtual users WITHOUT think time?
5. In the five-phase execution strategy, why should you run a baseline test before a load test?
6. What is the main purpose of a soak (endurance) test?
7. Which performance test type is most appropriate to run in a CI pipeline on every build?
8. What should the FIRST section of a performance test report contain?