Step 4: Test an Expired OTP
Generate an OTP and wait until its configured validity period has passed.
For example, if the test environment uses a two-minute expiry period, attempt verification after that period.
Expected behavior:
- The expired OTP should be rejected.
- The verification status should remain unsuccessful.
- The response should match the documented expiry behavior.
For repeatable testing, use a configurable expiry time or a controlled test clock where possible instead of relying only on manual waiting.
Step 5: Test OTP Resend Functionality
Call the resend endpoint, if the application provides one.
Check whether:
- A new OTP request is processed correctly.
- Resend limits are enforced.
- The previous OTP is invalidated if the application’s rules require it.
- The resend cooldown works correctly.
- The response does not reveal sensitive OTP information.
Some systems allow multiple OTPs to remain valid for a short period. Therefore, confirm the intended behavior before marking a test as failed.
Important OTP API Test Cases
The following test cases cover common functional, negative, boundary, and security scenarios.
| Test scenario | Expected result |
|---|---|
| Request OTP with a valid mobile number | Request is processed as specified |
| Request OTP with an invalid mobile number | Request is rejected or handled according to the API contract |
| Request OTP with a missing mobile number | Validation error is returned |
| Submit the correct OTP | Verification succeeds |
| Submit an incorrect OTP | Verification fails |
| Submit an expired OTP | Verification fails |
| Submit an OTP that has already been used | Reuse is rejected when single-use behavior is required |
| Submit an OTP with fewer digits than expected | Request is validated according to the OTP format |
| Submit an OTP with extra digits | Request is validated according to the OTP format |
| Submit letters or special characters instead of digits | Invalid input is handled correctly |
| Request an OTP repeatedly | Rate limits and resend rules are enforced |
| Exceed the allowed verification attempts | Further attempts are restricted according to policy |
| Submit a request without the required fields | Appropriate validation response is returned |
| Submit malformed JSON | Request is rejected safely |
| Verify an OTP for a different user or request | Verification is rejected |
| Reuse a request ID with a different OTP | The API follows the documented request-binding rules |
| Send requests concurrently | No unexpected duplicate verification or race condition occurs |
| Check the API response for sensitive information | OTPs and unnecessary personal data are not exposed |
These cases should be adjusted according to the application’s requirements. For example, a system may use a six-digit numeric OTP, while another may use a different format.