Skip to main content

Applying Performance Testing: AtlasBank Loan Application Under Load

Prerequisites: You should already understand every module in Sections 1–4 of this path. Leads to: After this, you'll be ready for Applying Performance Testing: AtlasShop Checkout Under Load.

Every module so far taught one concern at a time — a metric, a test type, a tool concept, a reporting format. This module combines several against one realistic, integrated feature: AtlasBank's loan-application flow under load, the way a real performance-testing effort actually has to.

The Feature: AtlasBank Loan Application Under Load​

Verifying that AtlasBank's loan-application flow — form submission, document upload and verification, and an eligibility calculation — stays within its defined SLO under realistic and stressed traffic, particularly relevant around known high-volume periods (a rate-drop announcement, month-end payday-driven traffic).

Strategy and Metrics (Sections 1–2)​

Applying Performance Testing Strategy: loan applications rank high-priority for dedicated testing — high business criticality, a recent redesign (per that module's own risk criteria), and a known upcoming rate-drop marketing announcement expected to drive a traffic surge. Applying Performance Metrics and SLAs: the team sets a p95 SLO of 2,000ms for full submission (tighter than the business's 5-second SLA, per that module's own safety-margin reasoning). Applying Test Data for Performance: test data is shaped to match real applicant distribution — most applications carrying a small, standard document set, a smaller share carrying larger, multi-document submissions (self-employed applicants, joint applications), rather than uniform test cases.

Execution and Tools (Section 3)​

Applying Performance Testing Types and Executing Load, Stress, Spike, Soak, and Volume Tests: a load test confirms expected traffic is handled within SLO; a stress test increments past that; and — specifically because of the known rate-drop announcement — a spike test simulates the announcement's actual delivery pattern (near-immediate surge, not gradual). Applying Bottleneck Analysis and Monitoring: monitoring is captured across all four resource dimensions throughout every run.

A real finding surfaces here: the load and stress tests both pass comfortably — but the spike test reveals a distinct problem neither of the others found: the document-verification service (a separate internal component call) takes nearly 40 seconds to scale its own worker pool in response to a sudden surge, correlating exactly with the spike test's timeline, while the loan-application service itself scales acceptably. This is a genuinely new finding, invisible to the load and stress tests, which never subjected the system to a sudden increase — the same distinction Executing Load, Stress, Spike, Soak, and Volume Tests established between gradual and sudden load.

Analysis and Capacity (Section 4)​

Applying Result Analysis and Reporting: the finding is reported both ways — a technical report naming the document-verification service's specific scaling lag, and a business-impact summary stating the rate-drop announcement risks applicant-facing failures unless addressed before the announcement date, with a clear recommendation (pre-warming the service's worker pool ahead of the known announcement time). Applying Capacity Planning: separately, the confirmed stress-test ceiling is combined with the product team's observed 6% month-over-month application growth, projecting the ceiling will be reached organically in roughly five months — a second, independent finding, unrelated to the spike-specific defect, requiring its own recommendation and timeline.

What This Application Module Shows​

Two real, genuinely distinct findings — a spike-specific service-scaling defect and an organic-growth capacity forecast — were found by applying different sections' techniques to the same integrated feature, not by any single technique alone. Neither required a new technique this path hadn't already taught; each was caught by carrying a specific, already-learned check through into a realistic, multi-part feature, and by testing deliberately for the specific known risk (an announced spike) rather than only generic load conditions.

Common Mistakes​

Mistake 1: Testing only load and stress, skipping a spike test because a load test already "passed." The service-scaling defect was invisible to both the load and stress tests — only a spike test, matching the feature's actual known risk (a sudden announcement), found it.

Mistake 2: Treating a capacity forecast and a spike-test defect as the same finding. These are genuinely independent — one is a code/architecture-level scaling defect fixable now, the other is a longer-term organic-growth trend requiring its own separate timeline and recommendation.

Mistake 3: Using uniform test data instead of matching the real applicant distribution. Per Test Data for Performance, a uniform document-set assumption would have missed how larger, multi-document applications specifically stress the verification service differently than standard ones.

Best Practices​

Practice 1: Match the test type to the feature's actual, specific known risk — here, a real announced event specifically justified a dedicated spike test. This is what surfaced the service-scaling defect no load or stress test would have found.

Practice 2: Treat a capacity forecast and a defect finding as separate report items, each with its own recommendation and timeline. Conflating them risks the wrong team acting on the wrong fix, or one urgent finding getting lost inside a longer-term forecast.

Practice 3: Shape test data to match real population distribution, not a uniform assumption, especially for features with genuinely varied real-world inputs. The multi-document applicant segment specifically was where the real scaling defect concentrated — a uniform dataset would have diluted or missed it entirely.

Key Takeaways​

  • Combining strategy, execution, and analysis techniques against one integrated feature finds defects no single technique, tested alone, would surface.
  • A spike test can reveal a genuinely distinct defect that load and stress testing, however thorough, structurally cannot — matching test type to a feature's actual known risk matters.
  • A capacity forecast and a specific defect finding are independent report items, each needing its own recommendation.

What You Just Learned​

  • How to combine performance strategy, metrics, test-type selection, execution, and analysis against one realistic, integrated feature
  • How a spike test found a real service-scaling defect invisible to load and stress testing
  • How a separate capacity forecast, based on real growth data, produced an independent, actionable finding
  • Why matching test data to real population distribution — not a uniform assumption — matters for finding defects that concentrate in a specific segment

Next: Applying Performance Testing: AtlasShop Checkout Under Load

Interview Questions​

Q1: Why might a feature that passes both load and stress testing still fail under real-world conditions?

What to look for: A candidate who names spike testing specifically — a sudden, rather than gradual, increase can expose a scaling-reaction defect neither load nor stress testing (both typically ramped more gradually) would find.

Q2: How would you decide whether a performance finding is an urgent defect or a longer-term capacity concern?

What to look for: A candidate who distinguishes a defect (a specific, fixable scaling or code issue, often tied to a specific condition like a sudden spike) from a capacity issue (the system consistently approaching a known ceiling due to steady growth) — and who treats each as needing its own separate recommendation and timeline.

Glossary​

No new terms are introduced in this module — every concept used above is defined in its linked source module.

Quick Revision​

Remember these five points:

✓ Combine strategy, execution, and analysis techniques against one integrated feature — don't just re-confirm each technique in isolation.

✓ Match test type to a feature's actual known risk — a real announced event justifies a dedicated spike test.

✓ A spike test can reveal defects load and stress testing structurally cannot.

✓ Treat a capacity forecast and a specific defect finding as separate, independently actionable report items.

✓ Shape test data to match real population distribution, not a uniform assumption.