Browse the Knowledge Hub32 resources
Test cases
OTP test cases about the guessing window
Twenty six cases covering code expiry, attempt limits, single use enforcement, older codes staying live, resend throttling, delivery failure, number normalisation, verification bypass, autofill and the accessibility of segmented code inputs.
All 26 test cases, ready to copy
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
26 worked examples
Verify successfully with a valid code
TypeFunctionalPriorityHigh- Test data
- Freshly issued code entered within the validity window
- Expected result
- Accepted, the code is consumed, the user proceeds, and the attempt counter for that identity resets.
Reject an incorrect code
TypeNegativePriorityHigh- Test data
- Valid format, wrong digits
- Expected result
- Refused with a generic message and the remaining attempts stated. No indication of which digits were wrong.
Enforce the attempt limit
TypeSecurityPriorityHigh- Test data
- Wrong code entered up to and beyond the allowed attempts
- Expected result
- Blocked after the limit with a stated cooldown, and the code is invalidated rather than left available for a further attempt after the wait.
Brute force the verification endpoint directly
TypeSecurityPriorityHigh- Test data
- One thousand codes submitted to the API for one identity
- Expected result
- Rate limited per identity and per source, and locked after the attempt limit. A six digit code with no limit is guessable in minutes.
Use a code after expiry
TypeBoundaryPriorityHigh- Test data
- Just inside the validity window, then one second beyond it
- Expected result
- Accepted inside, refused outside with an offer to resend. Validity should be short, typically five to ten minutes.
Reuse a code that has already been verified
TypeSecurityPriorityHigh- Test data
- Same code submitted a second time
- Expected result
- Refused. Codes are single use even inside their validity window.
Use an older code after requesting a new one
TypeSecurityPriorityHigh- Test data
- Request a code, request a second, then submit the first
- Expected result
- The first is invalid. Leaving multiple codes live at once multiplies the guessing surface and is a common implementation slip.
Use a code issued for a different identity
TypeSecurityPriorityHigh- Test data
- Valid code from account A submitted for account B
- Expected result
- Refused. Codes are bound to the identity and the specific verification attempt.
Throttle resend requests
TypeSecurityPriorityHigh- Test data
- Resend pressed ten times in one minute
- Expected result
- A visible countdown, a small number of resends per window, and a hard daily cap per identity. This protects both your costs and the recipient.
Check the cost and abuse ceiling on delivery
TypeSecurityPriorityHigh- Test data
- Requests for many different phone numbers from one source
- Expected result
- Blocked or challenged. Unthrottled message sending is a direct financial abuse route, and premium rate destinations make it worse.
Verify code format and character handling
TypeBoundaryPriorityMedium- Test data
- Fewer digits, more digits, letters, spaces, and a code pasted with a trailing space
- Expected result
- Length and character rules enforced with a clear message, and pasted values are trimmed rather than refused.
Verify codes are random and not sequential
TypeSecurityPriorityHigh- Test data
- Twenty codes issued in sequence and compared
- Expected result
- No predictable pattern, generated from a cryptographically secure source. Timestamp derived codes are guessable.
Confirm the code is not returned in the response or logs
TypeSecurityPriorityHigh- Test data
- Inspect the request response and every log sink after requesting a code
- Expected result
- The code appears only in the delivered message. Debug behaviour that returns it in the API response must never reach production.
Handle delivery failure
TypeNegativePriorityHigh- Test data
- Provider rejects the number, message undeliverable, provider timing out
- Expected result
- The user is told delivery failed and offered an alternative channel or support route, rather than being left waiting for a message that will never arrive.
Verify an alternative channel
TypeFunctionalPriorityMedium- Test data
- Fall back from SMS to voice call or email if supported
- Expected result
- The alternative issues a new code, invalidates the previous one, and shares the same attempt and expiry rules.
Validate phone number formats
TypeBoundaryPriorityHigh- Test data
- International prefix, local format, leading zeros, spaces and brackets, an invalid country code
- Expected result
- Normalised consistently so the same number cannot be registered twice in two formats, and invalid numbers are refused before a message is attempted.
Change the destination number or address mid flow
TypeStatePriorityHigh- Test data
- Request a code, edit the number, then submit the original code
- Expected result
- The original code is invalidated by the change. Verification applies to the new destination only.
Verify behaviour across two concurrent sessions
TypeStatePriorityMedium- Test data
- Start verification on two devices for the same identity
- Expected result
- Documented behaviour, and only one code is valid at a time. The second request must not silently break the first device without telling the user.
Interrupt the flow and return
TypeStatePriorityHigh- Test data
- Background the app or navigate away, then return within the validity window
- Expected result
- The pending verification is still available with the remaining time shown, rather than restarting and sending another message.
Verify autofill and paste behaviour
TypeCompatibilityPriorityHigh- Test data
- iOS and Android SMS autofill, plus paste into a multi box input
- Expected result
- One time code autofill works, and pasting a six digit code into segmented boxes distributes correctly rather than putting everything in the first box.
Verify the countdown and resend availability
TypeFunctionalPriorityMedium- Test data
- Watch the timer to zero, then resend
- Expected result
- The timer is accurate, resend becomes available exactly when stated, and the timer survives a page refresh rather than resetting to give a free retry.
Check the message content
TypeFunctionalPriorityMedium- Test data
- Delivered SMS or email
- Expected result
- Names the product, states the expiry, includes the code in a copyable form, carries the platform autofill markers, and warns against sharing it.
Verify an account is not left in a half verified state
TypeStatePriorityHigh- Test data
- Abandon verification after the code is issued but before it is entered
- Expected result
- No partially provisioned account or session with elevated rights. The identity remains unverified until a code is accepted.
Confirm verification cannot be skipped
TypeSecurityPriorityHigh- Test data
- Call the post verification endpoint directly, and replay a successful verification response
- Expected result
- Refused without a server side record of a consumed valid code. Trusting a client flag is the bypass to look for.
Time zone and clock skew handling
TypeBoundaryPriorityMedium- Test data
- Device clock set several minutes wrong, and a time based authenticator app if supported
- Expected result
- Expiry is computed server side, so a wrong device clock changes nothing. Time based codes allow a small tolerance window.
Complete verification by keyboard and screen reader
TypeAccessibilityPriorityHigh- Test data
- Keyboard only, then NVDA or VoiceOver, with segmented code boxes
- Expected result
- Boxes are labelled as one field, focus advances and reverses sensibly with Backspace, the remaining time and errors are announced, and the timer does not steal focus while the user types.
What goes in each field
ID
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat is being verified, in one line.
Type
Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.
Priority
Risk based. Attempt limits, expiry, code reuse and resend throttling are all High: a six digit code with unlimited attempts is not a second factor, it is a formality.
Test data
The specific values, including the invalid and boundary ones.
Expected result
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
Count the guesses, then count the codes
A six digit code is one million possibilities, which is nothing without an attempt limit and everything with one.
Attack the endpoint, not the form
Submit a thousand codes to the API. Interface level attempt counters are frequently absent on the server.
Request twice, submit the first
If both codes work, you have doubled the attacker window. Requesting a new code must kill the old one.
Hold resend down
Unthrottled sending is a direct cost, and it makes your product a tool for harassing a phone number.
Skip the step entirely
Call the endpoint after verification directly. If a client side flag is trusted, the whole factor is decorative.
Four gaps that make a code decorative
Multiple live codes is the most frequent implementation slip we find. A user presses resend three times, each request issues a code, and all three remain valid until they expire. The guessing surface triples, and nobody notices because every code works, which looks like correct behaviour. Requesting a new code must invalidate every previous one for that identity.
Server side attempt limits are the second. The form counts three tries and locks, and the endpoint behind it accepts unlimited submissions. Six digits fall to a scripted attack in minutes. Test with a script rather than by typing, and check the limit is per identity as well as per source, since one attacker with many addresses defeats a source only limit.
Resend throttling protects two things at once: your delivery costs and the person receiving the messages. Without a countdown, a per window cap and a daily ceiling, your service can be used to flood someone with messages, and each one is billed to you.
Finally, the segmented code input is one of the most common accessibility failures on modern products. Six separate boxes typically announce as six unlabelled fields, paste puts the whole code in the first box, Backspace does not move focus back, and a countdown that updates aggressively interrupts a screen reader mid word. All four are fixable, and all four are usually shipped.
Suggest an improvementBuilding phone or email verification?
QAble tests verification flows including provider failures, rate limits and the bypass paths that only appear when you call the API directly.
Security testing servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.Test cases for user roles and permissions
Test cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.Test cases for a date picker
Test cases26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.Test cases for pagination
Test cases24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.Test cases for push notifications
Test cases26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.Test cases for reports and data export
Test cases25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.Test cases for a chatbot
Test cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Sources
- OWASP ASVS verification requirements for authentication, session and access control.
- WCAG 2.2 the success criteria behind the accessibility cases.
- WAI-ARIA Authoring Practices expected keyboard and screen reader behaviour for widgets.
Want your second factor to actually be a second factor?
QAble tests authentication and verification with ISTQB-certified engineers. Start with a free QA audit of your product.