SMS OTP Testing Checklist for QA Testers

This SMS OTP testing checklist covers what a QA tester should check on any one-time-code flow: the happy path, wrong and expired codes, resend behaviour, rate limits, phone number formats and locales, security leaks, and a final check on real networks. Run it in staging with a stubbed or sandboxed SMS provider first, then repeat the delivery items with real phones before release.

Before you run the SMS OTP testing checklist

Get these details from the spec or the developers, because they're what you test against. If nobody can tell you, that's your first bug report.

• Code length and whether it's digits only
• Code lifetime in seconds
• Wrong attempts allowed before the code is burned
• Resend cooldown, and the maximum sends per number, per account and per IP address
• Whether a new code cancels the previous one
• Where codes go in test environments: a stub outbox, the provider's test mode or a log

Make sure test environments can't text real strangers. Reserved fictional numbers, such as 555-0100 to 555-0199 in North American format, are a cheap safeguard for stubbed tests.

Happy path

• The code arrives in the expected time.
• The message names the product, shows the code, states the expiry, says not to share it and is in the user's language.
• The correct code is accepted and the user lands in the right place.
• The same code is rejected the second time.
• Pasting the code works, including with spaces around it.
• The phone's keyboard offers the code from the incoming text, where the platform supports it.
• Codes starting with 0 work: 012345 must not become 12345.

Wrong codes

• A wrong code shows a clear error without hinting which digits were right.
• After the allowed number of wrong attempts, the code stops working even if the correct one is then entered.
• Letters, symbols and the wrong number of digits are handled without a crash.
• A code sent to one number or account can't verify a different one.

Expiry

• A code entered just before the stated lifetime is accepted.
• A code entered just after it is rejected, with a message that says what to do next.
• The lifetime in the SMS text matches what the server enforces.

Rather than waiting real minutes, ask for a configurable lifetime in staging or clock control in automated tests.

Resend

• The resend button is disabled during the cooldown, with a visible countdown.
• Reloading the page doesn't reset the cooldown.
• A double click sends one SMS, not two.
• After a resend, the old code behaves as specified, usually rejected.
• Editing the phone number restarts the flow and sends to the new number only.

Rate limits

• Sends per number are capped, and the error explains when to try again.
• Sends per account and per IP address are capped too.
• Requests to many different numbers from one source are limited, which blocks SMS pumping: bots triggering texts to run up your bill.
• Limits reset after the window ends.
• The response doesn't reveal whether a number is registered.

Phone number formats and locales

• The country selector defaults sensibly and is searchable.
• International format with + is accepted, as is the local format with a leading 0 for countries that use one, such as the UK or the Netherlands.
• A leading 0 typed after the country code is handled: corrected or clearly rejected.
• Spaces, dashes, brackets and pasted numbers are cleaned up; too short or too long ones get a helpful error.
• Landline or VoIP numbers are handled as the policy says, with a clear message.
• Translated messages stay within the expected number of SMS parts. One character outside the basic GSM-7 alphabet cuts a single message from 160 characters to 70.
• Right-to-left languages display correctly on the code screen.
• Error messages and the countdown are announced by screen readers, not only shown visually.

Security and privacy

• The code never appears in an API response, a URL, analytics, browser storage, server logs or error trackers.
• Verification happens on the server; changing the response in the browser doesn't skip the step.
• The code is tied to the sign-in session that requested it.
• Brute-force attempts spread across several sessions still hit a limit.

Real-network check

Stubs prove the logic, not delivery. Before release, test on real phones:

• Each country you launch in, ideally on more than one carrier.
• Delivery time is acceptable on a normal mobile connection.
• The sender name or number shows as expected in each country.
• Messages aren't filtered or mangled, and long ones reassemble.
• The full flow works on both major mobile platforms.

For a quick manual check in several countries, the free public numbers on Temp SMS show incoming texts on a web page, with US, Canadian, UK, Dutch, Finnish, Swedish and Belgian numbers listed. Use them only with test accounts and test data: every message is visible to anyone, the numbers are shared and retired over time, and they must never be used for banking, a main email account or two-factor authentication.

FAQ

How do you test OTP without a real phone? Use a stubbed SMS provider or the provider's test mode, and read codes from the stub's outbox. Keep real phones for the final delivery check.

What should be tested in SMS OTP verification? Correct and wrong codes, expiry, resend, rate limits, number formats, localisation, security leaks and real delivery.

How do I test OTP expiry without waiting? Ask for a shorter lifetime in staging or for clock control in automated tests, then test just before and just after the limit.

Should QA test OTP with real phone numbers? Yes, for the final check. Stubs can't show carrier filtering, delivery delays or how the sender appears on a real phone.

More on SMS verification for developers:

• Testing SMS OTP in Python with pytest
• Testing SMS OTP with Playwright
• SMS character counter (GSM-7 vs UCS-2)