How to test an event ticketing platform
Direct answer
Shipped untested, an event ticketing platform lets broker bots split purchases across many accounts and cards to get past the per-buyer ticket limit, and shows face value on the seat map while adding service and facility fees only at checkout. 8 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with end-to-end functional tests: the first seat price, the checkout total with all fees and the per-buyer ticket limit are checked in the same purchase.
8 mandatory testsfirst: end-to-end functional tests
What counts as an event ticketing platform
An event ticketing platform here is a site and app on web, iOS and Android that sells live-event tickets at a fixed onsale time, through a virtual queue, a seat map with seat holds, checkout and scannable or transferable tickets. It covers presale and general onsale, per-buyer limits, fee display, wheelchair and companion seats and ticket transfer links. Venue gate scanning hardware and resale between fans on a separate exchange are out of scope until they ship.
Adjacent product types not covered here
- travel booking app: A travel booking app resells supplier inventory such as flights and rooms, so supplier cancellations and refunds replace onsale crowds and bot purchases.
- online marketplace: An online marketplace lists goods from many third-party sellers at any time, so seller verification and payout holds replace a single onsale minute and seat holds.
- ecommerce store: An ecommerce store sells stock without seat maps or a queue, so checkout and stock errors replace bots beating ticket limits and venue accessible seating rules.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Fraud or abuse by users fraud-abuse | money | primary | Broker bots split purchases across many accounts and cards to get past the per-buyer ticket limit, then resell the seats. | |
| Accessibility complaint or lawsuit accessibility-liability | legal | primary | Wheelchair seats that can only be bought by phone, or not during the online onsale, break ADA ticketing rules for the venue. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | A seat map that shows face value and adds service and facility fees only at checkout breaks the federal fee rule for live-event tickets. | |
| Personal or sensitive data exposed data-breach | data | secondary by design analysis | A ticket transfer link or barcode endpoint that accepts another order number exposes the buyer's name, email and seat to anyone. | |
| Outage during a demand peak outage-under-load | outage | practitioner single incident, no second source | A stadium tour presale opens to fans and bots at the same minute, and the queue and seat map fail for part of the buyers. |
Mandatory tests (8)
Step 1: release smoke tests
Done when: On the release build before each onsale, with the test queue opened at the scheduled onsale time, buyers join the queue, pick seats on the map, pay and receive scannable tickets.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 2: end-to-end functional tests
Why:regulatory-penaltyfraud-abuse
Done when: The first price shown for a seat equals the checkout total with all fees, and a buyer at the ticket limit cannot add one more ticket.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 3: penetration testing
Done when: The tester's report states that scripted buyers could not exceed the per-buyer ticket limit across accounts or open another buyer's ticket by changing an order number.
Tool class: proxy. Who usually runs it: security specialist.
Step 4: compliance checks
Why:regulatory-penaltyaccessibility-liability
Done when: A signed checklist shows total-price display on every price screen and that accessible seats go on sale online at the same time as other seats.
Tool class: test management. Who usually runs it: product manager.
Step 5: accessibility testing
Done when: A screen reader user finds and buys a wheelchair space and companion seat during a test onsale without help.
Tool class: accessibility checker. Who usually runs it: accessibility specialist.
Step 6: security scanning
Why:data-breach
Done when: The scan report for the site, apps and ticket API lists no open high-severity finding on the ticket transfer links or barcode endpoints.
Tool class: DAST scanner. Who usually runs it: security specialist.
Step 7: performance and load testing
Done when: With a simulated onsale crowd larger than the biggest past onsale, the queue keeps admitting buyers and no seat is sold twice.
Tool class: load generator. Who usually runs it: QA engineer.
Step 8: resilience and failure testing
Done when: When one seat-map server is shut down mid-onsale, buyers in the queue keep their place and held seats stay held.
Tool class: chaos tool. Who usually runs it: developer.
Recommended and optional tests
integration testsrecommended
Becomes mandatory when venues use their own access control system.
device and browser compatibilityrecommended
Becomes mandatory when mobile tickets replace printed tickets at the gate.
data integrity and migration testingrecommended
Becomes mandatory when resale between fans ships.
payment and money-flow testingrecommended
Becomes mandatory when buyers are charged twice, or charged without a ticket, during an onsale.
unit testsoptional
May help when fees vary by venue or price tier.
regression suiteoptional
May help keep onsale fixes from regressing.
exploratory testingoptional
May help find seat-hold states the scripted cases miss.
Not needed and why
Not needed: price display is covered by the end-to-end and compliance tests. Becomes recommended when seat map abandonment data points to confusion.
Not needed: the platform sells in one language and currency. Becomes recommended when events in a second country go on sale.
analytics and event tracking tests
Not needed: sales and seat counts come from the order ledger. Becomes recommended when analytics events drive dynamic pricing.
Order of work
First release
- release smoke tests: On the release build before each onsale, open the test queue at the scheduled onsale time, then have buyers join it, pick seats on the map, pay and receive scannable tickets.
- end-to-end functional tests: Compare the first price shown for a seat with the checkout total including all fees, then try to add one ticket past the per-buyer limit.
- penetration testing: Have a tester run scripted buyers across many accounts against the per-buyer limit and change order numbers on transfer links and barcode endpoints.
- compliance checks: Check every price screen for total-price display and confirm accessible seats go on sale online at the same time as other seats, then sign the checklist.
- accessibility testing: Have a screen reader user find and buy a wheelchair space and a companion seat during a test onsale without help.
- security scanning: Scan the site, apps and ticket API, with the ticket transfer links and barcode endpoints in scope.
- performance and load testing: Open a test onsale to a simulated crowd larger than the biggest past onsale and confirm the queue keeps admitting buyers and no seat sells twice.
- resilience and failure testing: Shut down one seat-map server mid-onsale and confirm buyers keep their queue place and held seats stay held.
Ongoing cadence
- release smoke tests: On every release build and before each onsale.
- performance and load testing: Before each onsale expected to draw a larger crowd than any past onsale.
- resilience and failure testing: After each change to queue or seat-hold infrastructure.
- penetration testing: When broker bots get past the per-buyer limit in a live onsale.
- compliance checks: After each change to fee rules or price screens.
- data integrity and migration testing: When resale between fans ships, and after every onsale from then on.
- integration tests: When a venue connects its own access control system.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of event ticketing platform (web, ios, android). Not recommendations.
release smoke tests
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
end-to-end functional tests
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
- EspressoAndroid UI testing framework from Google. androidopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- MaestroMobile UI flows written in YAML. iosandroidfreemium
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
penetration testing
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
accessibility testing
- Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
- axe-coreAccessibility rules engine for automated checks. webopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- Pa11yCommand-line accessibility testing. webopen-source
security scanning
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- MobSFStatic and dynamic analysis for mobile binaries. iosandroidopen-source
- OWASP ZAPDynamic application security scanner. webapiopen-source
- SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
- SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium
performance and load testing
- ArtilleryLoad testing with YAML scenarios. apiwebfreemium
- GatlingLoad testing with Scala, Java or Kotlin scenarios. apiwebfreemium
- JMeterLoad testing tool from the Apache Foundation. apiwebopen-source
- k6Load testing scripted in JavaScript. apiwebopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- LocustLoad testing scripted in Python. apiwebopen-source
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JestJavaScript test runner with mocking and snapshots. webapiopen-source
- JUnitTest framework for the JVM. apiandroidopen-source
- VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
device and browser compatibility
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
payment and money-flow testing
- Adyen test environmentTest cards and scenarios for Adyen integrations. webapiiosandroidcommercial
- Stripe test modeTest cards and scenarios for Stripe integrations. webapiiosandroidfreemium
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for event ticketing platform has the same 8 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the event ticketing platform is accepted when a test buyer can join the queue, pick a seat, pay and receive a scannable ticket, and the first price shown for a seat equals the checkout total with all fees. A buyer at the per-buyer ticket limit cannot add one more ticket from any account. Under a simulated onsale crowd the queue keeps admitting buyers, no seat is sold twice, and wheelchair spaces can be bought online during the onsale.
Brief
# Test brief: event ticketing platform Product type: event ticketing platform. High-demand ticket sales with queues, seat maps and transfers. Risk map and evidence: https://howtotestaproduct.com/how-to-test/ticketing-platform/ Printable checklist: https://howtotestaproduct.com/checklists/ticketing-platform/ Run these 8 mandatory tests in this order. A test is done only when its done condition is true on the build you will release. 1. release smoke tests (risks: outage-under-load). Tool class: browser automation. Usually run by: QA engineer. Done when: On the release build before each onsale, with the test queue opened at the scheduled onsale time, buyers join the queue, pick seats on the map, pay and receive scannable tickets. 2. end-to-end functional tests (risks: regulatory-penalty, fraud-abuse). Tool class: browser automation. Usually run by: QA engineer. Done when: The first price shown for a seat equals the checkout total with all fees, and a buyer at the ticket limit cannot add one more ticket. 3. penetration testing (risks: fraud-abuse, data-breach). Tool class: proxy. Usually run by: security specialist. Done when: The tester's report states that scripted buyers could not exceed the per-buyer ticket limit across accounts or open another buyer's ticket by changing an order number. 4. compliance checks (risks: regulatory-penalty, accessibility-liability). Tool class: test management. Usually run by: product manager. Done when: A signed checklist shows total-price display on every price screen and that accessible seats go on sale online at the same time as other seats. 5. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist. Done when: A screen reader user finds and buys a wheelchair space and companion seat during a test onsale without help. 6. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist. Done when: The scan report for the site, apps and ticket API lists no open high-severity finding on the ticket transfer links or barcode endpoints. 7. performance and load testing (risks: outage-under-load). Tool class: load generator. Usually run by: QA engineer. Done when: With a simulated onsale crowd larger than the biggest past onsale, the queue keeps admitting buyers and no seat is sold twice. 8. resilience and failure testing (risks: outage-under-load). Tool class: chaos tool. Usually run by: developer. Done when: When one seat-map server is shut down mid-onsale, buyers in the queue keep their place and held seats stay held. Acceptance criteria wording: A release of the event ticketing platform is accepted when a test buyer can join the queue, pick a seat, pay and receive a scannable ticket, and the first price shown for a seat equals the checkout total with all fees. A buyer at the per-buyer ticket limit cannot add one more ticket from any account. Under a simulated onsale crowd the queue keeps admitting buyers, no seat is sold twice, and wheelchair spaces can be bought online during the onsale. Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file). Licence: CC BY 4.0.
For founders: what to forward and what to ask back. For product managers: turning this page into tickets.
Questions about testing an event ticketing platform
What testing does an event ticketing platform need?
8 tests are mandatory, starting with an onsale smoke test and end-to-end tests of total-price display and the per-buyer ticket limit. Each is tied to one of the 5 risks in the map, such as bots beating ticket limits, a queue and seat map that fail when the onsale opens or wheelchair seats sold only by phone. Integration, compatibility, data integrity and payment tests are recommended, each with the event that makes it mandatory.
What does GDPR mean for testing an event ticketing platform?
The map cites the General Data Protection Regulation for the data breach risk. The data breach case is a ticket transfer link or barcode endpoint that accepts another order number and exposes the buyer's name, email and seat, so penetration testing changes order numbers on those endpoints.
How should checkout be tested in an event ticketing platform?
Compare the first price shown for a seat with the checkout total including all fees, and try to buy one ticket past the per-buyer limit. Then run the same checkout under a simulated onsale crowd and confirm no seat sells twice, and with one seat-map server shut down confirm held seats stay held.
Which tests in a vendor test plan for an event ticketing platform are not needed?
Usability testing is not needed while price display is covered by end-to-end and compliance tests, until seat map abandonment data points to confusion. Localization is not needed while the platform sells in one language and currency, until events in a second country go on sale. Analytics tracking is not needed until analytics events drive dynamic pricing.
What is the minimum testing for an event ticketing platform at MVP stage?
The minimum is the 8 mandatory tests, because their conditions apply from the first onsale that opens to a crowd at a fixed time, sets a per-buyer limit and sells seats at public venues. Unit, regression and exploratory tests are optional, and usability, localization and analytics tests are not needed until the conditions on this page change.
Evidence
ev-0177post-mortemprimary
Taylor Swift | The Eras Tour Onsale Explained, Ticketmaster
The ticket seller's own account of a presale where bot traffic and fans without presale codes drove record system load and disrupted part of the queue. Supports outage-under-load and fraud-abuse for an event ticketing platform.
published 2022-11-19 · verified 2026-10-07
ev-0178regulatorprimary
FTC Brings First-Ever Cases Under the BOTS Act, Federal Trade Commission
Federal enforcement against ticket brokers who used automated software to get around per-customer ticket limits on a primary ticket seller. Supports fraud-abuse for an event ticketing platform: purchase limits that bots bypass are an attack surface the platform must test.
published 2021-01-22 · verified 2026-10-07
ev-0180regulatorprimary
ADA Requirements: Ticket Sales, U.S. Department of Justice, Civil Rights Division
Federal guidance: venues must sell wheelchair-accessible seats through the same channels, including websites and third-party sellers, and during the same hours as other tickets. Supports accessibility-liability for an event ticketing platform with seat maps.
published 2020-02-28 · verified 2026-10-07
ev-0179regulatorprimary
16 CFR 464.1: Definitions (Rule on Unfair or Deceptive Fees), Federal Trade Commission (16 CFR Part 464, text via Cornell Legal Information Institute)
The federal fee rule names live-event tickets and short-term lodging as the covered goods, and its section 464.2 requires the total price to be shown with any advertised price. Applies to an event ticketing platform and to a travel booking app that sells hotel stays.
published undated · verified 2026-10-07
ev-0012standardprimary
OWASP API Security Top 10 2023, OWASP Foundation
The API Security Top 10 names API-specific failures such as broken object level authorization and unrestricted resource consumption.
published undated · verified 2026-10-07
ev-0025regulatorprimary
Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex, European Union
The GDPR sets lawful basis, consent, data subject rights, security of processing (Article 32) and breach notification duties for anyone processing personal data of people in the EU.
published undated · verified 2026-10-07
Disclaimer
This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.