Before go-live, a team must confirm two things: that the database sustains the projected holiday peak of 5,000 transactions per second, and that a recent schema change did not break any of the existing finance reports. Which testing combination addresses both?
Select an answer to reveal the explanation.
Short Explanation
Stress testing asks how hard you can push it before it breaks. Regression testing asks whether the stuff that worked yesterday still works today. Two different questions, two different tests, and swapping them is the classic trap.
Full Explanation
Stress testing drives the database at and beyond expected peak load to observe throughput, latency, resource saturation and failure behavior, which directly answers whether the system sustains 5,000 transactions per second and how it degrades past that. Regression testing re-runs existing functionality after a change and compares the results with known good output, which answers whether the schema change broke the finance reports. Failover testing confirms that a standby takes over when the primary fails, which says nothing about sustaining 5,000 transactions per second, and a restore test proves backups are recoverable rather than that report queries still return correct results after the schema change. Unit testing exercises individual components in isolation, usually with small data, and cannot demonstrate system-wide throughput; penetration testing evaluates security weaknesses rather than functional correctness of reports. Using stress testing for both assumes that surviving load proves unchanged behavior, but a report can return wrong totals quickly and without errors, so correctness must be checked explicitly. Exam caveat: load testing at expected volume and stress testing beyond it are sometimes distinguished; either way, the purpose differs from regression testing. Operational check: run the stress test with production-like data volumes, and diff each finance report's output against its pre-change baseline.