Every "how to test login" article gives you the same list: valid credentials, invalid credentials, empty fields, SQL injection, forgot password link. Those test cases matter. They're also incomplete for mobile.
Mobile login has four methods (email/password, biometrics, social SSO, and OTP), each with its own failure modes. The keyboard covers the Login button on small screens. Face ID behaves differently from fingerprint. Google SSO redirects to an external browser and back. OTP auto-fill works on some devices and fails silently on others. A Samsung One UI battery optimization dialog can block the login screen entirely on first launch.
In this covers 20 test cases organized by login method, plus the mobile-specific edge cases that web-focused login testing guides miss entirely. For the test case format (fields, template, good vs bad comparison), see our test case template. For how to write mobile test cases in general, see our test case writing guide.
Method 1: email and password login (5 test cases)
These cover the standard credential-based login that every app has.
1. Valid login. Launch the app. Type "user@test.com" in the email field. Type "Test@1234" in the password field. Tap "Log in." Expected: home screen loads within 3 seconds, header shows "Welcome, User," bottom navigation is visible.
2. Invalid password. Type valid email, enter wrong password, tap "Log in." Expected: error message "Invalid credentials" appears within 2 seconds. Password field clears. Email field retains the entered email (the user shouldn't have to retype it).
3. Empty fields. Tap "Log in" without entering anything. Expected: inline validation errors appear under both fields ("Email is required," "Password is required"). The form doesn't submit.
4. Account lockout. Enter wrong password 5 times consecutively. Expected: account locks after the 5th attempt. Error message shows "Account locked. Try again in 15 minutes" (or similar). The 6th attempt is blocked even with the correct password.
5. Password visibility toggle. Type a password. Tap the eye icon. Expected: password characters become visible. Tap the icon again. Expected: characters are masked again. The toggle should work on every tap without lag or visual glitch.
Method 2: biometric login (4 test cases)
Biometric login (Face ID, Touch ID, fingerprint) adds hardware-dependent behavior that varies across devices and OS versions.
6. Successful biometric login (Face ID / fingerprint). Preconditions: user previously logged in with email, biometric login enabled in settings, device has Face ID (iOS) or fingerprint sensor (Android) enrolled. Launch the app. Biometric prompt appears. Authenticate. Expected: home screen loads within 2 seconds. No email/password prompt shown.
7. Biometric failure with fallback. Launch the app. Biometric prompt appears. Fail the biometric check (cover the camera for Face ID, use the wrong finger for fingerprint). Expected: after 2-3 failed attempts, the app offers a fallback option ("Use password instead"). Tapping it shows the email/password form.
8. Biometric not enrolled. Preconditions: device has no fingerprint or Face ID enrolled. User previously enabled biometric login in app settings. Launch the app. Expected: app detects that biometrics aren't available and falls back to email/password login. No crash, no blank screen, no confusing error.
9. Biometric after OS update. Preconditions: user has biometric login enabled. Device receives an OS update (iOS 17 to 18, or Android 14 to 15). Launch the app after the update. Expected: biometric prompt appears and works. Some OS updates reset biometric permissions, so the app should handle re-enrollment gracefully.
Method 3: social SSO login (4 test cases)
Social login (Google, Apple, Facebook) redirects the user to an external authentication flow and back. This redirect chain is where mobile-specific bugs hide.
10. Successful Google SSO. Tap "Continue with Google." Expected: Google account picker appears (either in-app WebView or Chrome). Select an account. Authenticate (may include 2FA if enabled on the Google account). Expected: redirect back to the app. Home screen loads. User profile shows the Google account's name and email.
11. SSO redirect loop. Tap "Continue with Google." Authenticate. Expected: the app receives the OAuth token and completes login. What to watch for: a redirect loop where the app opens Chrome, Chrome redirects to the app, the app opens Chrome again. This is a deep link or intent filter misconfiguration. The test should verify that login completes in a single redirect cycle.
12. SSO with app killed during redirect. Tap "Continue with Google." While the Google authentication screen is loading, kill the app (swipe it out of recents). Reopen the app. Expected: the app shows the login screen, not a blank screen or a crash. The user can start the SSO flow again cleanly.
13. SSO when the social app isn't installed. Preconditions: Google app / Facebook app is not installed on the device. Tap "Continue with Google." Expected: the flow opens in the device's default browser instead of the app. Login completes via the browser-based OAuth flow. The user is redirected back to the app after authentication.
Method 4: OTP login (4 test cases)
OTP (one-time password) login sends a code via SMS and is common in fintech, e-commerce, and apps targeting markets where email adoption is lower.
14. Successful OTP delivery and auto-fill. Enter phone number "+91-9876543210." Tap "Send OTP." Expected: OTP received within 30 seconds. On Android 11+, the SMS auto-fill prompt appears and populates the OTP fields. On older Android or iOS, the user types manually. Tap "Verify." Expected: login completes, home screen loads.
15. Invalid OTP. Receive OTP. Enter a wrong code. Tap "Verify." Expected: error message "Invalid OTP" appears. OTP field clears. User can request a new code.
16. OTP expiration. Receive OTP. Wait for the expiration period (typically 2-5 minutes). Enter the expired OTP. Expected: error message "OTP expired. Please request a new one." The app offers a "Resend OTP" button.
17. OTP on a device without SMS access. Preconditions: device is a Wi-Fi-only tablet with no SIM card. Enter a phone number. Tap "Send OTP." Expected: the app doesn't crash. If the OTP is sent to a different device (the user's phone), the user types it manually. If the app requires the OTP on the same device, it should show a message explaining that SMS-based login isn't available on this device and offer an alternative (email login, for example).
Mobile-specific edge cases (3 test cases)
These are the test cases that web-focused login guides miss completely. They're the ones that generate "the login doesn't work" support tickets.
18. Keyboard covers the Login button. Preconditions: Samsung Galaxy A14 with One UI 5 (or any device where the keyboard height covers the bottom of the screen). Tap the password field. Keyboard opens. Expected: the screen scrolls or the layout adjusts so that the "Log in" button remains visible above the keyboard. On some devices with One UI, the button gets pushed below the keyboard and the user can't tap it without dismissing the keyboard first. This is a compatibility testing issue that only surfaces on specific device/OEM combinations.
19. OEM popup blocks login screen. Preconditions: Xiaomi device with HyperOS, first launch of the app. Expected: a "Security" popup appears asking for additional permissions. The test should verify two things: that the popup doesn't permanently block the login screen, and that dismissing the popup leads to a functional login screen. On some Xiaomi devices, if the user taps "Deny" on the popup, the app's notification permissions are permanently revoked, and the user never receives OTP or push notifications.
20. Login state after app kill and reopen. Log in successfully. Kill the app (swipe out of recents). Reopen the app. Expected: the user is still logged in (session token persists). The app opens to the home screen, not the login screen. Now test the opposite: log in, wait for session timeout (if applicable), reopen the app. Expected: the user is redirected to the login screen with a "Session expired" message.
Automating login test cases on mobile
Once you've validated these 20 test cases manually, the repeatable ones (1-6, 10, 14-16, 20) should be automated for regression testing. Every build should confirm that login still works across methods and devices.
With Drizz, these test cases translate directly to plain-English steps:
Tap on "Log in"
Type "user@test.com" in email field
Type "Test@1234" in password field
Tap "Log in"
Validate "Welcome" is visible
Vision AI finds the email field, the password field, and the Login button by what's visible on screen, not by element IDs. The same test runs on a Samsung, Pixel, Xiaomi, and iPhone without separate scripts. The popup agent handles the Xiaomi Security popup from test case #19 automatically. Self-healing adapts when the login screen layout changes between builds.
For OTP-based login (test cases 14-17), Drizz's memory commands store the OTP value during execution and reuse it in the verification step, all within the same test run. That's what makes OTP automation practical instead of requiring manual intervention or a separate SMS retrieval service.
FAQ
How many test cases should a login page have?
At minimum, 15-20 covering all login methods your app supports (credentials, biometrics, SSO, OTP), plus mobile-specific edge cases (keyboard coverage, OEM popups, session persistence after app kill).
What's the most commonly missed login test case on mobile?
The keyboard covering the Login button on small screens or OEM-skinned devices. It passes on emulators and Pixels but fails on Samsung Galaxy A-series with One UI. Always test with the keyboard open.
How do I test biometric login without a real device?
You can't fully. Emulators simulate biometric prompts but don't replicate real Face ID/fingerprint behavior. For accurate biometric testing, you need a real device with biometrics enrolled or a cloud platform with real hardware.
Should OTP login be automated?
Yes, but it requires handling dynamic data. Use a test phone number with a fixed OTP (like Firebase Auth's test numbers), or use Drizz's memory commands to store and reuse the OTP value within the test execution.
What login security tests should I include?
SQL injection in the username/password fields, brute-force lockout after 5 failed attempts, session token expiration, HTTPS enforcement, and password not stored in plaintext on the device.
How do I test SSO login across Android and iOS?
The OAuth redirect flow differs between platforms (Custom Tabs on Android, ASWebAuthenticationSession on iOS). Test that the redirect completes in one cycle on both. Verify that killing the app during the redirect doesn't crash or leave a blank screen.
