Stress testing: how does the system break?

The correct answer: A. Stress testing

✅ Why this answer

Stress testing, with its three harsh conditions: scarce resources (memory or disk running out) + exceptional concurrency beyond what the system was designed for + denial-of-service attacks. Its methodical question: “when and how does the system break?” The aim is not to prevent failure, since every system has a breaking point, but to know how it fails: does it fail safely (slowing down and refusing new requests without losing data) or catastrophically (corruption and loss)?

❌ Why the other options are wrong

• Integration testing (B): how components interact.
• Regression testing (C): making sure the old still works after a change.
• System testing (D): the whole system against the specifications, not deliberately exceeding limits.

💡 Key concept

The basic distinction: load testing measures performance under the expected load (a related question in the full bank). Stress testing deliberately exceeds the expected until the system breaks. The first asks: does it work well under usual conditions? The second asks: when does it break, and does it break safely?

In the exam: stress testing has three signs: scarce resources, a load beyond what the system was designed for, and simulated flooding attacks. The phrase “to see whether and how it fails” confirms it. Withstanding a flood protects availability, one side of the CIA triad.

🔗 Related facts and questions

• The types of performance testing: load for the expected level, stress for what goes beyond it, and volume testing for large amounts of data (a related question in the full bank).
  Practice question: testers load the database with ten years of records to see whether reports stay fast. Which type is this? → Volume testing.
• The expected load:
  Practice question: the portal is tested with two thousand users at the same time, the number expected on a usual working day. Which type is this? → Load testing.
• Failing safely:
  Practice question: at five times the expected load the portal showed “the service is busy, try again later”, and no data were lost. Is this an acceptable test result? → Yes. The portal refused the extra requests without losing data, which is a safe failure.
• The expected load of an exceptional event:
  Practice question: a health campaign is expected to send a million people to the portal in an hour. The team tests the portal with a million users, then keeps raising the number until it stops responding. What is each of the two tests called? → The first is a load test and the second a stress test. A million is the load expected for the campaign; going above it is the deliberate excess that finds the breaking point, and the plan to add resources before the campaign is built on it.
• Two more tests with close names: endurance testing (also called soak testing): the same expected load, but for a long time, to reveal what builds up over time, such as a memory leak. Spike testing: a sudden, short jump in load, then back to the usual level.
  Practice question: the portal ran at its usual load for 72 hours without a break, and memory use kept rising until it slowed down. Which kind of test revealed that? → Endurance testing. The load never went beyond the expected; what changed was the duration.
• Denial-of-service (DoS) attacks: flooding the system with requests until real users cannot reach it. Simulating them in a stress test shows whether the protections hold.