Before go-live of a new county payments page, operators must prove the site handles peak tax-season traffic. Which test type fits?
Select an answer to reveal the explanation.
Short Explanation
Load tests are the "tax-season line around the block" rehearsal—prove the payments page holds before opening day. One clerk click or a spell-check is not peak capacity proof.
Full Explanation
Load testing simulates expected or peak concurrent traffic to validate capacity before go-live. A new county payments page that must survive peak tax-season concurrency needs a load test that generates representative payment traffic—sessions, posts, and downstream calls—at peak-like levels. Passing that rehearsal is how operators prove the site can handle the line around the block before opening day, not after citizens discover timeouts.
A single manual click by one clerk with no concurrent users fails by concept because one user is a smoke check, not a capacity proof. A spell-check of the help text with no traffic generation fails because copy review does not exercise runtime capacity. Skipping capacity validation because tax season is months away fails by deferring the only test that answers the go-live risk; peak readiness must be shown before go-live, not hoped for later.
Exam caveat: load tests should model realistic concurrency and critical transactions (payments), not only homepage GETs. Distinguish load/performance testing from functional UI checks and from chaos experiments. Also size environments so the test is representative of production bottlenecks (app, DB, payment gateway limits).
Operational check: before go-live, run a load test at projected tax-season concurrency against the payments page, confirm error rate and latency stay within SLOs, and document max sustained throughput. Fix bottlenecks and re-test rather than declaring readiness from a single clerk click.