Test case library · Login & identity
These cases cover the email or username and password login screen of a mobile app, from typing credentials to staying signed in after the app is killed or the phone restarts. Login often breaks outside the test lab: keyboards change what users type, password managers fill the wrong field, and battery savers on budget phones end sessions overnight.
From the reviews. Login and OTP failures were 16.4% of the malfunction reviews in our India App Quality Report, and 7.1% of all reviews on banking app storefronts, the highest of any category.
Expected: The home screen opens showing the account's name or avatar. No error, extra prompt or second login screen appears.
Expected: The same account opens as when signing in with the email. No email-format error appears for the username.
Expected: The password switches between plain text and dots with the text and cursor unchanged. Sign-in succeeds with the typed password.
Expected: The home screen opens directly for the same account. The login screen does not flash before it.
Expected: The login screen appears and no account data is visible before signing in. The email is prefilled only if the product is designed to remember it.
Expected: The app opens the account linked to that Google email. The chooser closes and no browser tab is left open.
Expected: The first sign-in creates an account and the second opens the same one. The profile shows the relay email or a placeholder, not an error.
Expected: A message such as 'Incorrect email or password' appears without saying which one is wrong. The email stays filled in.
Expected: Inline messages appear under the empty or invalid field and no loading spinner starts. The typed values stay in place.
Expected: The correct password does not sign in while the account is locked. The message says how to unlock the account or when to try again.
Expected: Both phones show the locked-account message until the lock ends. Reinstalling or clearing app data does not remove the lock.
Expected: A message says the account uses Google sign-in and points to that button or a way to set a password. No generic server error appears.
Expected: Each shows its own message, such as an option to resend verification or a support contact. Neither reaches the home screen.
Expected: Sign-in succeeds for the existing account. No 'user not found' error or duplicate account appears.
Expected: Only the new failure counts and the account is not locked. Any attempts-left message starts again from the full count.
Expected: The app opens the existing account, or asks for the password before linking. The saved data is visible, not an empty new profile.
Expected: The app opens the same account or clearly says no password account exists for that email. Two accounts with split data are not created silently.
Expected: The email, password and show/hide state are unchanged after each change. Sign-in works without retyping.
Expected: The app refreshes the session or asks the user to sign in again. It does not show a blank screen, a crash or data that fails to load.
Expected: The app shows the home screen, or the login screen with a retry option. It is not stuck on a spinner.
Why a real phone: Real carrier calls take over the screen differently across OEM dialers.
Expected: A clear no-connection or timeout message appears with the email still filled. The retry signs in once, without an 'already signed in' error.
Why a real phone: Depends on real signal loss and recovery on Jio, Airtel or Vi.
Expected: The request completes, or fails with a retry message after a short wait. The retry does not create a second session or show an error.
Why a real phone: The handover from Wi-Fi to carrier data only happens on a phone with a SIM.
Expected: The sheet is still open, or the login screen is back with the buttons active. No endless loading state appears.
Expected: The app restarts signed in, or returns to the login screen with a retry message. It never shows an empty white screen.
Why a real phone: Process death under real memory pressure happens on budget phones, not emulators.
Expected: The app opens signed in to the same account without asking for the password. It does not crash or show a blank screen on launch.
Why a real phone: Stored tokens rely on the phone's hardware keystore, which differs across OEM firmware.
Expected: The app opens signed in or refreshes the session without asking. The user is not sent back to the login screen.
Why a real phone: OEM battery savers stop and clear apps only on real phones with those skins.
Expected: Each copy shows only its own account. Signing out of one does not sign out or change the other.
Why a real phone: App cloning is an OEM feature on Xiaomi, Vivo, Oppo and Samsung phones.
Expected: The email goes into the email field and the password into the password field. The save prompt appeared once, with the correct username.
Expected: Both fields fill and sign-in succeeds. The keyboard and Sign in button stay usable after the autofill sheet closes.
Why a real phone: OEM password managers and their autofill sheets exist only on that maker's phones.
Expected: The email is not autocorrected and the password field shows no word suggestions. The password never appears as a keyboard suggestion elsewhere.
Why a real phone: Phone makers' default keyboards treat password fields differently from stock keyboards.
Expected: Both show the same text and take about the same time. Nothing reveals whether the email is registered.
Expected: Phone A shows a signed-out message and returns to the login screen. Its cached personal data is no longer visible.
Expected: Phone A shows the signed-out message on its first contact with the server. It does not keep working as if signed in.
Expected: The login screen appears and Back does not reveal earlier account screens. No cached personal data shows after reopening.
Expected: The thumbnail does not show the password in plain text. The masked field offers no Copy or Cut option.
Expected: Each field is read by its label, the eye icon says whether it shows or hides the password, and the error is read out. No control is announced only as 'button'.
Why a real phone: VoiceOver does not run in the iOS Simulator, so a real iPhone is needed.
Expected: Labels and errors wrap without being cut off, and Sign in can be reached with the keyboard open. No text overlaps the fields.
Expected: All labels and messages show in Hindi without truncation or raw text keys. The fields still accept English letters for email and password.
Expected: The keyboard switches to an English layout or makes switching easy. Any non-English characters typed by mistake are visible when the password is shown.
Why a real phone: Indic and OEM keyboards choose layouts for password fields in their own way.
They fit the Standard package: 10 × 45-minute sessions on 4 phones or browsers of your choice, up to ~50 cases, ₹18,999 + GST ($249), verified report in 3 business days. The 10 P1 cases alone fit Starter (₹9,999 + GST).
Download the CSV, pick the package at checkout and upload the file with your build. Testers run them on their own phones, on Jio, Airtel and Vi.
There is no single right number, as it depends on the product's risk and support load. Test against the configured limit and check that the server enforces it, so a second phone or a reinstall cannot bypass it. Also check that the lockout message tells the user how to recover.
Usually not. A message like 'Incorrect email or password' avoids telling an attacker which emails have accounts. Check that unknown emails and wrong passwords get the same text and a similar response time.
Common causes are sessions kept only in memory, stored tokens that fail to decrypt after a reboot, and battery savers that clear the app's background work. Test on at least one Xiaomi, Realme or Vivo phone with default battery settings and reboot it with the app signed in. Note whether the app crashes, refreshes the session silently or asks for the password.
35 cases · 9 need a real phone
34 cases · 13 need a real phone
38 cases · 16 need a real phone
39 cases · 12 need a real phone
34 cases · 14 need a real phone
99tests runs your cases, AI-generated ones included, on the phones, laptops and browsers your users own. Every finding is verified, serious bugs come with a screen recording, and each case comes back pass, fail, blocked or not run.