Manual testing guide
15 OTP Test Cases: Expiry, Resend and Security
One-time passwords are short-lived security credentials. Effective coverage verifies the complete credential lifecycle—from issue and delivery through expiry, resend, consumption and protection against guessing.
Example requirement
A user can verify their identity using a six-digit OTP that expires after five minutes, can be used only once and is protected against repeated guessing and excessive resend requests.
Generate test cases for this example15
Test cases
6
Coverage types
10
High priority
CSV
Export format
OTP verification test coverage
Test the full credential lifecycle rather than the six-digit field alone: creation, delivery, entry, expiry, resend, consumption and abuse controls.
- Check immediately before, at and after the expiry boundary.
- Confirm whether resend replaces every earlier code.
- Test guessing, resend and request-rate limits independently.
- Cover delayed delivery, autofill, paste and accessible errors.
15 example test cases
Filter the coverage, switch between card and table views, then copy or export the cases you need. Replace assumptions with the confirmed rules, environments and risks of your product.
Showing 15 of 15 cases
Verify using a valid OTP
Precondition
A current OTP was issued to the user.
Expected result
Verification succeeds once and the authorised flow advances to the expected state.
Steps
- 1.Enter the six-digit OTP within five minutes
- 2.Submit verification
Reject an expired OTP
Precondition
An OTP was issued more than five minutes ago.
Expected result
Verification is rejected without authorising the protected action.
Steps
- 1.Enter the expired OTP
- 2.Submit verification
Prevent reuse after successful verification
Precondition
An OTP has already completed verification.
Expected result
The consumed credential is rejected and cannot be used for a second protected action.
Steps
- 1.Start another verification attempt
- 2.Submit the consumed OTP
Apply the documented resend rule
Precondition
An OTP was recently issued.
Expected result
Resend timing is enforced and code validity follows the documented replacement policy.
Steps
- 1.Request another OTP before the resend delay
- 2.Request again after the delay
- 3.Try the old and new codes
Limit repeated incorrect attempts
Precondition
The verification screen and attempt policy are available.
Expected result
The configured delay or block is applied without revealing the correct code or compromising the account.
Steps
- 1.Submit incorrect codes up to the allowed threshold
- 2.Submit one additional code
Validate OTP format and input behaviour
Precondition
The OTP input is available.
Expected result
Only the documented six-digit format is accepted and invalid input cannot bypass verification.
Steps
- 1.Enter fewer and more than six digits
- 2.Try letters, symbols, spaces and pasted content
- 3.Submit each invalid value
Accept the OTP immediately before expiry
Precondition
The expiry time can be controlled precisely.
Expected result
Verification follows the documented inclusive or exclusive boundary consistently.
Steps
- 1.Enter the valid OTP immediately before expiry
- 2.Submit verification
Reject the OTP immediately after expiry
Precondition
The expiry time can be controlled precisely.
Expected result
The expired credential is rejected and cannot authorise the action.
Steps
- 1.Wait until immediately after expiry
- 2.Enter and submit the OTP
Limit excessive resend requests
Precondition
The resend policy is configured.
Expected result
The configured cooldown or block is applied without creating unlimited valid codes.
Steps
- 1.Request resends up to the limit
- 2.Request one additional resend
Handle codes delivered out of order
Precondition
Two codes can be delivered in a controlled order.
Expected result
Validity follows the replacement policy regardless of delivery order.
Steps
- 1.Request a code
- 2.Request a replacement
- 3.Deliver the newer code before the older code
- 4.Try both
Bind the OTP to the correct account and purpose
Precondition
Two accounts or verification purposes are available.
Expected result
The code cannot verify a different account, session or protected action.
Steps
- 1.Request codes for both contexts
- 2.Use the first code in the second context
Support operating-system OTP autofill
Precondition
A supported device can receive a correctly formatted OTP message.
Expected result
The complete code populates the intended input and verification can proceed once.
Steps
- 1.Request an OTP
- 2.Choose the operating-system autofill suggestion
- 3.Submit verification
Paste a complete OTP
Precondition
A valid code is copied to the clipboard.
Expected result
Paste works safely across the component without reversed, duplicated or missing digits.
Steps
- 1.Focus the OTP input
- 2.Paste the complete code
- 3.Submit verification
Announce invalid-code errors to screen readers
Precondition
A screen reader is available.
Expected result
The error is announced, associated with the OTP input and does not rely on colour alone.
Steps
- 1.Submit an invalid code
- 2.Review focus and the announced error
Keep OTP values out of URLs and analytics
Precondition
Safe access to request URLs, logs and analytics events is available.
Expected result
The OTP is absent from URLs and analytics and is redacted from application logs.
Steps
- 1.Request and submit an OTP
- 2.Inspect URLs, client events and approved logs
Coverage checklist
- Test immediately before and after the exact expiry boundary.
- Confirm whether resend invalidates all earlier codes.
- Verify limits for both code attempts and resend requests.
- Do not expose the OTP in logs, URLs or analytics events.
- Cover delayed delivery and codes arriving out of order.
Common defects
- • An older code remains valid after resend contrary to policy.
- • Expiry is checked only in the browser.
- • Attempt limits can be bypassed with a new session.
- • Delayed messages cause the wrong code to be accepted.
- • OTP values appear in URLs, logs or analytics.
Suggested test data
- • Current, expired, consumed and replaced codes
- • Correct and incorrect six-digit values
- • Accounts with repeated attempts and resend counts
- • Delayed and out-of-order message delivery
- • Supported devices with OTP autofill
Automation notes
- • Control time in the test environment for reliable expiry boundaries.
- • Verify server-side credential state rather than relying only on the message shown.
- • Isolate attempt-limit tests so shared accounts do not affect unrelated scenarios.
Frequently asked questions
What should OTP test cases cover?+
Cover valid verification, format, expiry boundaries, resend rules, one-time use, attempt limits, delayed delivery, accessibility and protection of the code.
How do you test OTP expiry?+
Test immediately before, at and after the configured boundary using a controlled clock or test fixture whenever possible.
Should an old OTP work after resend?+
The product must define that rule. Many systems invalidate earlier codes; testing should prove the selected behaviour even when messages arrive out of order.
Related test case examples
Password reset test cases covering OTP delivery, expiry, one-time use, password policy, account discovery and active-session behaviour.
Login testingPractical login page test cases covering valid access, invalid credentials, validation, accessibility, session handling and security risks.
Registration testingExample registration test cases for required fields, duplicate accounts, password rules, verification, accessibility and input boundaries.
Mobile app testingMobile application test cases covering installation, permissions, connectivity, interruptions, orientation, accessibility and supported devices.
Generate cases for your own requirement
Paste your real user story, choose the coverage categories and receive structured manual test cases you can review and export.
Open the free generator