Event Ticketing: Testing Before a Fixed Launch
A community arts group is selling tickets for a 400-seat concert through a small web app. Sales open at 9 am on a Saturday and the event usually sells out within an hour. The app handles ticket selection, a 10-minute hold on chosen seats, payment via a third-party gateway, and email confirmation. Testing so far has been manual, done by two volunteers on one laptop. Last year a similar app sold the same seat twice and sent confirmation emails for failed payments. The launch is in 5 weeks and cannot move because the venue and performers are booked. The group has no dedicated tester.
1. Design a test approach proportionate to the risk and the 5-week constraint. Identify the highest-risk areas and the test types you would prioritise.
Read the worked answer
Risk ranking: The two past failures point to the highest risks: seat allocation under concurrent demand, and payment-to-email consistency. Both cause direct harm (angry customers, refunds, lost trust) and both appear only under load or failure conditions, which manual testing on one laptop will not reveal.
Prioritised tests:
- Concurrency: simulate many users selecting the same seat at once to confirm the hold prevents double sale. This tests the hold logic, not just a single user path.
- Hold expiry: verify a seat is released after 10 minutes and that a late payment cannot claim an expired hold.
- Payment failure paths: declined card, timeout, and gateway error should not produce a confirmation email.
- Email consistency: confirmation sent only after payment success is recorded.
- Boundary: the 400th seat, zero seats remaining, and duplicate submissions from a double-click.
Proportionate method: automate the concurrency and payment-path tests with a script so they can be rerun cheaply; keep manual checks for the purchase flow a volunteer can judge.
Constraint fit: With no dedicated tester, automation of the repeatable high-risk cases is the realistic way to cover them in 5 weeks.
2. The group asks whether they can skip load testing because the audience is only 400 people. Respond with reasoning and a recommendation.
Read the worked answer
The audience size is not the load. The load is requests per second at 9 am, when many of the 400 arrive at once. If most buyers attempt in the first few minutes, the app may see a burst far above its average, and the seat-hold step multiplies requests because each selection writes state.
Why it matters: Last year's double sale is exactly the kind of fault that appears when requests overlap. A quiet single-user test cannot expose it. Skipping load testing leaves the highest-risk failure untested.
Recommendation: Run a scaled load test that simulates the expected burst, such as all 400 buyers attempting within 10 minutes with several selecting the same popular seats. This is cheaper than a full-scale test and still exercises contention. Also consider a queue or waiting room to smooth the 9 am spike. If time is short, test the seat-hold contention first, because a double sale is worse than a slow page. Document the tested limit so the group knows the margin.