Login and Sign Up

Your banking app, your food delivery app, your email, your gym’s booking site: almost every product starts with the same two screens. Log in and Sign up. They’re the front door. If the door is stuck, nobody gets in. If the lock is weak, the wrong people do.

That’s why login is often the first feature a new tester is asked to test, and why it’s a favorite interview question (“How would you test a login page?”). By the end of this lesson you’ll have a confident, structured answer, and you’ll have found real bugs in a broken login screen.

How it works

Logging in is called authenticationAuthenticationChecking who a user is, usually with a password, a code or biometrics.Open in glossary →: proving who you are. It’s different from authorizationAuthorizationChecking what a logged-in user is allowed to see or do.Open in glossary →, which decides what you’re allowed to do once you’re in (for example, only admins can issue refunds).

Here’s what happens behind the screen when you tap Log in:

Appphone or browser

Serverchecks who you are

Databaseusers + hashes

1. 1Sends email + password over HTTPS

   POST /login

2. 2Finds the user and compares password hashes

3. 3Match found

4. 4Creates a session and returns a token

   token: 8f2a…

5. 5Stores the token safely (Keychain, Keystore or a cookie)

6. 6Every next request carries the token

   GET /orders

7. 7Checks the token and answers

   200 · Anna's orders

The family of login features

“Login” is rarely just one screen. Here’s what you’ll meet in real projects:

Feature	What it does	What to watch out for
Sign up (registration)	Creates a new account: name, email, password, maybe terms checkbox	Password rules really enforced, duplicate emails, confirmation email
Log in (sign in)	Proves you own an existing account	Wrong-credential handling, lockout, “remember me”, sessions
Password reset	“Forgot password?” sends a one-time link or code by email or SMS	Link expires, works only once, old password stops working, generic message
Two-factor authentication (2FA)	After the password, asks for a second proof: SMS code, authenticator app code, or a push approval	Wrong or expired codes, resend limits, “trust this device”
Social login	“Sign in with Apple” or “Sign in with Google” lets another company vouch for you	Canceling halfway, Apple’s “Hide My Email”, linking to an existing account
Biometrics	Face ID, Touch ID or fingerprint unlocks a saved login on the device	Fallback to password, new fingerprint added, biometrics turned off
Logout	Ends the session on this device (sometimes “log out everywhere”)	Back button, cached screens, other tabs and devices

Example requirements

Before you test, you need to know what “correct” means. Here’s a realistic user storyUser storyA short description of a feature from the user's point of view.Open in glossary → for a grocery delivery app, with acceptance criteriaAcceptance criteriaConditions a user story must meet to be considered done and accepted.Open in glossary →:

Notice how many criteria are about things other than “it logs in”. Criteria 2, 4, 5, 7, 9 and 10 each prevent a real bug that teams ship all the time.

Why “generic error message” matters

If the app says “No account with this email” for one address and “Wrong password” for another, an attacker can feed it a list of emails and learn which people have accounts. That’s called account enumerationAccount enumerationFinding out which emails are registered from differences in error messages or responses.Open in glossary →. They can then target those people with phishing or password guessing.

What usually goes wrong

These bugs appear in login features again and again. Learn them once and you’ll recognize them everywhere.

#	Bug	What you see	Typical severity
1	Case-sensitive or untrimmed email	Anna@test.com or anna@test.com (with a space from autofill or the keyboard) says “no account”	High
2	Account enumeration	Different messages for “unknown email” and “wrong password”	Medium–High (security)
3	Lockout missing or bypassable	Unlimited password guesses, or the counter resets when you reload or switch screens	High (security)
4	Password leaks	Password in the URL, in logs, in analytics events, or visible in a screenshot of the app switcher	Critical (security)
5	double submitDouble submitA bug where an action runs twice because the user tapped or clicked twice quickly.Open in glossary →	Tapping Log in twice creates two sessions or two accounts	Medium
6	Rules not enforced	The UI says “at least 8 characters” but 1234 is accepted (often only the client checks, or the wrong number)	Medium–High
7	Session not really ended	After logout, Back shows the account screen, or the old token still works	High (security)
8	Session expires badly	User is kicked out mid-checkout and loses their basket, or never expires at all	Medium
9	Autofill and password managers break	The keyboard doesn’t offer saved passwords, or autofill fills the wrong field	Medium
10	Unhelpful error messagesError messageText that tells the user something went wrong and, ideally, how to fix it.Open in glossary →	“Error 500” or “Something went wrong” with no next step, or errors that never clear	Low–Medium
11	Reset link problems	Link works twice, never expires, or opens the browser instead of the app	High
12	Accessibility gaps	Fields without labels, errors not announced by screen readers, show-password icon with no name	High (for affected users)

Find the bug

Time to practice. FreshCart’s login and sign up screens below have six bugs. Explore them like a tester:

• Log in with the test account. Then try variations of the same email.
• Try a wrong password, and an email that doesn’t exist. Compare the messages.
• Watch the server log for every request.
• Tap buttons quickly, more than once.
• Create a new account and read the password rule.
• Log out, then use Swipe back.

🐞 Bug hunt: FreshCart login

This demo has 6 hidden bugs. Explore it like a tester, then check your findings.

Found0/6

9:41

FreshCart

Groceries in 30 minutes

Log inSign up

Email

Password

Remember meForgot password?

Log in

or

Sign in with AppleGSign in with Google

New to FreshCart? Create an account

Device

Restart app

Swipe back

Test account

anna@test.com / Secret123!

From the spec: passwords need at least 8 characters, the account locks after 5 failed attempts, and error messages must not reveal whether an email is registered.

Locked yourself out? Tap Restart app.

Server log

• Log in or sign up to see requests…

1. 1

   Hint: Log in as Anna@test.com, or add a space after the email.

   Email is case-sensitive and spaces are not trimmed

   Anna@test.com and anna@test.com both fail with "No account found", although it is the same account. The server log shows the raw value (Anna%40test.com, %20 at the end). Expected: the email is trimmed and compared case-insensitively.

   Reveal answer✓ I found this
2. 2

   Hint: Compare a wrong password for anna@test.com with any unknown email.

   Error messages reveal which emails are registered

   Unknown email shows "No account found with this email", a wrong password shows "Incorrect password". This is account enumeration: an attacker can test a list of emails and find real customers. Expected: one generic message such as "Email or password is incorrect".

   Reveal answer✓ I found this
3. 3

   Hint: Read the first line of each login request in the server log.

   Password is sent in the URL

   Login is a GET /api/login?email=…&password=Secret123! request. URLs end up in server logs, proxies, analytics and browser history, so the password leaks in plain text. Expected: a POST request with credentials in the body (sign up already does this correctly).

   Reveal answer✓ I found this
4. 4

   Hint: Tap Log in twice quickly with the correct password, then look at Active sessions.

   Double tap on Log in creates two sessions

   The button shows a spinner but stays enabled, so each tap sends a new request. The account screen lists two active sessions, and logging out only ends one of them. Expected: the button is disabled while the request is in progress and only one session is created.

   Reveal answer✓ I found this
5. 5

   Hint: Create an account with the password "abcd".

   Sign up accepts passwords shorter than 8 characters

   The helper text says "At least 8 characters", but a 4-character password is accepted and the server returns 201. A 3-character password is rejected, so the check uses the wrong number (a classic boundary bug). Expected: 7 characters rejected, 8 accepted, on the client and the server.

   Reveal answer✓ I found this
6. 6

   Hint: Log in, log out, then use Swipe back.

   Swipe back after logout shows the account again

   Logout puts the Log in screen on top of the account screen instead of replacing the history, and the cached profile is not cleared. Swiping back shows Anna's name, address and card again without logging in. Expected: after logout the history is reset and personal data is cleared from memory.

   Reveal answer✓ I found this

Test scenarios

A test scenarioTest scenarioA high-level idea of what to test, such as 'User resets a forgotten password'.Open in glossary → is a one-line idea of what to check. Group them by type so you don’t forget whole areas. Here’s a strong starting set for login and sign up. For the sign up form itself (field rules, real-world names and addresses, error messages), see Forms and Validation.

Functional

The happy paths, the core of positive testingPositive testingTesting with valid input to confirm the software works as expected.Open in glossary →:

• Log in with a valid email and password and land on the Home screen.
• Sign up with valid data, then log out and log in with the new account.
• Remember me on: close and reopen the app (or browser), you’re still logged in. Off: you have to log in again.
• Forgot password: the email arrives, the link opens the reset screen, the new password works, the old one doesn’t.
• 2FA: a correct code logs you in; “Resend code” sends a new one and the old code stops working.
• Social login: Sign in with Apple and Google create an account on first use and log in to the same account next time.
• Biometrics: after enabling Face ID or fingerprint, the next login only needs a glance or a touch.
• Logout ends the session and returns to the Log in screen.

Negative

negative testingNegative testingTesting with invalid or unexpected input to check the software handles it gracefully.Open in glossary →: the app should refuse politely, and never crash or leak information.

• Wrong password for an existing email.
• Email that has no account.
• Empty email, empty password, both empty.
• Badly formatted email: anna@, anna.test.com, anna@@test.com.
• Sign up with an email that’s already registered.
• Sign up with a password that breaks the rules (too short, or missing a required number).
• Expired or already-used password reset link.
• Wrong, expired or reused 2FA code.
• Cancel the Apple or Google sheet halfway through.

Edge cases

Edge casesEdge caseAn unusual situation at the extreme of what the software should handle.Open in glossary → are where the interesting bugs live:

• Email case: ANNA@TEST.COM and Anna@Test.com should log in to the same account as anna@test.com.
• Spaces: a leading or trailing space in the email (very common with autofill). Spaces inside a password must be kept, since they can be part of it.
• Password length boundaries: with a minimum of 8, try 7, 8 and 9 characters. That’s boundary value analysisBoundary value analysisTesting values at and just around the edges of valid ranges, where bugs love to hide.Open in glossary →. Also try the maximum (e.g. 64 or 128) and one more.
• Very long input: paste 1,000 characters into each field. Does the layout break, does the app freeze, does the server answer with a 500?
• Unicode: names like Zoë, José, Łukasz or 王芳; passwords with emoji or ü. A password set on the web must also work in the app.
• Special characters in passwords: " ' < > & % \ ; (they also catch basic SQL injectionSQL injectionAn attack where text typed into a field is run as a database command.Open in glossary → and Cross-site scripting (XSS)Cross-site scripting (XSS)An attack where text a user enters is run as code in other people's browsers.Open in glossary → problems).
• Plus addressing: anna+groceries@test.com is a valid email and must be accepted.
• Lockout boundaries: 4 wrong attempts then a correct one (should work and reset the counter); exactly 5 wrong (locked); a correct password while locked (still locked).
• Slow or lost network while tapping Log in: clear loading state, no frozen spinner, no double session.
• Double tap on Log in or Create account.
• Password changed on another device: the old session should end.

UI & usability

• Every field has a visible label, not only a placeholderPlaceholderHint text shown inside an empty input field that disappears when the user starts typing.Open in glossary → that disappears when you type.
• Show/hide password toggles the masking and keeps the cursor position.
• The keyboard type fits the field: email keyboard with @, no auto-capitalization or autocorrect on email and password fields.
• Password managers and autofill work: iOS offers saved passwords above the keyboard, Android Autofill and browsers fill the right fields, and “suggest strong password” works on sign up.
• Pressing Return/Enter on the keyboard moves to the next field or submits.
• Error messages are clear, near the field, and tell the user what to do. They disappear once the problem is fixed.
• Password rules are shown before the user types, not only after a failure.
• The Log in button shows a loading stateLoading stateWhat the UI shows while it waits for data or an action to finish, such as a spinner or skeleton.Open in glossary → and is disabled while waiting.
• The screen works in landscape, with large text, in dark mode, and on small phones (the button isn’t hidden behind the keyboard).

Security basics

You don’t need to be a security expert to catch these. security testingSecurity testingChecking that data and features are protected from unauthorized access and attacks.Open in glossary → at this level is mostly careful observation (see Security basics for more):

• Generic error messages for wrong email and wrong password (no account enumeration). Same for password reset.
• Lockout or rate limiting after the agreed number of failed attempts, enforced on the server (refreshing or reinstalling must not reset it).
• Password never in the URL, logs or analytics. Check with DevToolsDevToolsDeveloper tools built into browsers for inspecting pages, network traffic and errors.Open in glossary → (Network tab) on the web or a proxy tool on mobile.
• HTTPS only. Try http:// on the web: it should redirect to https://.
• Logout really logs out: Back button, browser history and reopened tabs must not show protected pages. An old token copied before logout must be rejected.
• Session expiry: after the agreed idle time, the next action asks you to log in again, and returns you to where you were afterwards.
• Password field is masked and its value is not copyable (Copy is disabled on masked fields).
• Reset links expire and work only once. Changing the password ends other sessions.
• The app switcher on mobile shouldn’t reveal sensitive data (many banking apps blur the screen).

Accessibility

accessibility testingAccessibility testingChecking that people with disabilities can use the product, for example with a screen reader.Open in glossary → for login matters a lot: if someone can’t log in, they can’t use anything else.

• With a screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary → (VoiceOver, TalkBack), every field announces its label, e.g. “Email, text field”.
• The show-password button has a name (“Show password”) and announces its state.
• Error messages are announced when they appear, and focus moves to or near the first error.
• On the web, you can complete the whole flow with the keyboard only, with a visible focus ring, in a logical order.
• Text contrast is at least 4.5:1, and errors aren’t shown by red color alone (add text or an icon).
• Touch targetsTouch targetThe area of the screen that responds to a tap, which should be large enough for a finger.Open in glossary → for the eye icon and links are at least 44×44 pt (iOS) / 48×48 dp (Android).
• No time limit that’s too short to type a password or a 2FA code, and pasting into fields is allowed (people who use password managers rely on it).

Example test cases

Scenarios become test casesTest caseA written set of steps, data and an expected result used to check one specific behavior.Open in glossary → once you add exact steps, test dataTest dataThe input values, accounts and records you use while testing.Open in glossary → and expected results:

Mobile vs web

The idea is the same everywhere, but the details, and the bugs, differ a lot.

Mobile appWebsite

• Biometrics: test enabling and disabling Face ID / Touch ID / fingerprint, failed scans and the fallback to passcode or password. Also what happens if a new fingerprint or face is added in device settings (many banking apps then require the password again).
• Keychain and Autofill: iOS Password AutoFill and Android Autofill should offer saved passwords and “suggest strong password” on sign up. If they don’t, the fields are probably missing the right content type hints.
• Keyboard types: email keyboard with @, no auto-capitalization or autocorrect on email and password. Check that the keyboard doesn’t cover the Log in button.
• App backgrounding: put the app in the background during login (or while the 2FA SMS arrives) and come back. The form should keep its data, the session shouldn’t break, and the app switcher shouldn’t show sensitive data.
• Staying logged in: mobile apps usually keep you logged in for weeks. Test restarting the app, restarting the phone, updating the app, and reinstalling (the iOS Keychain can survive a reinstall, so check whether you’re unexpectedly still logged in).
• Deep links from emails: a password reset or “confirm your email” link should open the app (a deep linkDeep linkA link that opens a specific screen inside an app instead of just its home screen.Open in glossary →, see Deep links), not the browser. Test with the app installed, not installed, and logged in as a different user.
• 2FA codes: iOS and Android can autofill SMS codes from messages. Check that the code field supports it.
• Back button (Android): after logout, the system Back button must not return to the account.

• Browser autofill and password managers: Chrome, Safari, Firefox and tools like 1Password should detect the fields and offer to save the password after sign up. Check that they fill the right fields.
• Remember me cookies: with “Remember me”, closing and reopening the browser keeps you logged in. Without it, the session should end. Look at the cookieCookieA small piece of data a website stores in your browser, for example to keep you logged in.Open in glossary → in DevTools (Application tab): expiry date, and flags like Secure and HttpOnly.
• Multiple tabs: log out in one tab, then click something in another. The second tab should send you to the login page, not keep working. Log in as a different user in a new tab and check the first tab doesn’t mix up data.
• Back button and history: after logout, the browser Back button must not show cached account pages. The password must never appear in browser history (which happens with GET forms).
• HTTPS: http:// should redirect to https://, and the browser should show no “Not secure” warning on the login page.
• Network tab: in DevToolsDevToolsDeveloper tools built into browsers for inspecting pages, network traffic and errors.Open in glossary →, check that login is a POST, that the password isn’t in the URL, and what the error responses contain.
• Cross-browser: test login in Chrome, Safari and Firefox, including private/incognito windows (cookies behave differently there).
• Keyboard only: Tab through the form, submit with Enter, and check the focus ring is always visible.

Checklist

Login and sign up checklist

0 of 15 checked

Copy

• Valid email and password log in and open the Home screen
• Email is case-insensitive and leading/trailing spaces are ignored
• Wrong email and wrong password show the same generic message
• Account locks after the agreed number of failed attempts, enforced on the server
• Password rules from the spec are enforced at sign up (test the boundaries: 7, 8, 9 characters)
• Log in and Create account buttons cannot be submitted twice
• Password is masked, has a show/hide button, and is never sent in the URL
• All traffic uses HTTPS
• Remember me keeps you logged in after a restart; without it the session ends
• Password reset link arrives, works once, expires, and shows a generic message for unknown emails
• Logout ends the session: Back, history and other tabs cannot show account data
• Session expiry asks you to log in again without losing your work
• Autofill and password managers fill the right fields; keyboard types are correct
• 2FA, social login and biometrics work, including cancel and fallback paths
• Labels, error announcements and keyboard navigation work with a screen reader

Check your understanding

Quick quiz

0/5 answered · 0 correct

1. 1.Which error message is the safest for a failed login?

   A"No account found with this email."B"Incorrect password for anna@test.com."C"Email or password is incorrect."D"Error 401."

2. 2.Your login works with "anna@test.com" but fails with "Anna@test.com". What kind of bug is this?

   AA cosmetic bug, nobody types capitalsBAn input handling bug: emails should be compared case-insensitivelyCA performance bugDExpected behavior, emails are case-sensitive

3. 3.The rule says "at least 8 characters". Which set of password lengths gives the best boundary test?

   A1, 50, 100B7, 8, 9C8 onlyD4 and 12

4. 4.In DevTools you see: GET /api/login?email=anna%40test.com&password=Secret123!. What is the problem?

   ANothing, it uses HTTPSBThe email is URL-encodedCThe password is in the URL, so it ends up in logs and historyDGET is slower than POST

5. 5.After tapping Log out, you press Back and see the account screen with the user's address. What should you do?

   AIgnore it, the user chose to press BackBReport it as a security bug: logout must clear the history and cached dataCReport it as a low-priority UI glitchDClear the app cache and retest

Key takeaways

• Login is authenticationAuthenticationChecking who a user is, usually with a password, a code or biometrics.Open in glossary →: credentials go to the server once, and a session token proves who you are after that.
• Test the whole family: sign up, log in, password reset, 2FA, social login, biometrics and logout.
• The classic bugs: case-sensitive emails, account enumeration, missing lockout, passwords in URLs, double submit, rules not enforced, and logout that doesn’t really log out.
• Use boundary values for password rules and lockout counts, and always try uppercase, spaces, long input and unicode.
• Watch the network (DevTools or a proxy) and check Back, other tabs and app restarts after logout.