Login, logout and password reset testing

Login looks simple until a user is locked out at the worst moment. This page lists what to test in login, logout and password reset flows, the safe limits for testing them, and a ready-to-run task for your AI beta tester.

Who it’s for

  • Teams shipping changes to authentication, SSO or session handling
  • SaaS products with paying users who must never get locked out
  • Developers adding magic links, 2FA or social login
  • Anyone who has never tried their own "forgot password" flow

Updated 2026-10-19.

Login is the most used screen in most products, and one of the least tested after launch. Login testing checks that the right people get in, wrong attempts fail gracefully, password resets work end to end and sessions behave predictably. A login beta test is short, but a single bug here can lock out every user at once.

What login testing covers

Login testing is functional beta testing, not a security audit: the goal is to find broken flows, confusing messages and session bugs a real user would hit. Penetration testing and brute-force attempts are a different job and need explicit authorization and specialist tools; the OWASP Authentication Cheat Sheet is the reference for the security side.

How to run a login beta test

  1. Create a dedicated test account (never a real customer's or an admin account) and note your lockout threshold.
  2. Set up a test inbox the beta tester can read, or agree that it stops after requesting a reset.
  3. Run the valid login on desktop and mobile width, in two browsers.
  4. Run the failure cases with at most one or two wrong attempts.
  5. Run the password reset from "Forgot password?" to logging in with the new password.
  6. Test sessions and logout: Back button, bookmarked URLs, multiple tabs, remember me.
  7. Test social login and SSO buttons if you offer them.
  8. File bugs with evidence, then add the core flow to a scheduled smoke test.

Login testing checklist

Core login

  • Valid login: the test account logs in and lands on the expected page, not a blank screen or a redirect loop.
  • Wrong password: a clear message, the email field keeps its value, and the password field is cleared.
  • Unknown email: the message should not reveal whether an account exists ("email or password is incorrect" is the safe pattern).
  • Case and spaces: an email typed with uppercase letters or a trailing space should still work.
  • Show password toggle: works and does not reset the field.
  • Enter key: pressing Enter submits the form.
  • Password managers: fields have proper autocomplete attributes so browsers can fill them.
  • Loading state: the button shows progress, and double-clicking does not cause errors.

Password reset flow

  1. The "Forgot password?" link is easy to find on the login page.
  2. Requesting a reset shows a confirmation that does not leak whether the email is registered.
  3. The reset email arrives, has a clear subject, and the link works once.
  4. The link expires after use and after a reasonable time; an expired link explains what to do.
  5. The new password rules are shown, and after resetting, the user is logged in or sent to login with a success message.
  6. Other sessions are handled as intended after a password change (for example, signed out elsewhere).

Your tester can only finish step 3 onward if it can reach the inbox, so give it a test inbox or ask it to stop after the request step.

Sessions and logout

  • Logout actually ends the session: pressing Back or opening a bookmarked dashboard URL should send the user to login.
  • Protected pages opened while logged out should redirect to login and then return the user to the page they wanted.
  • Remember me: if offered, does it work after closing and reopening the browser?
  • Multiple tabs: logging out in one tab should not leave another tab in a broken half-logged-in state.
  • Session expiry: an expired session explains itself instead of failing silently on the next save.

Two-factor authentication

  • Setup instructions are clear, and backup codes are offered.
  • Entering a wrong or expired code shows a helpful message.
  • The "remember this device" option behaves as described.

Social login and SSO

For Google, Apple, Microsoft or SSO buttons, check that each one opens the right provider, that cancelling returns the user to a sensible page, and that an account created by email can still sign in when the same email is used with a social button (or that the product explains why not).

Example bug report

Title: Password reset link logs user into a redirect loop after reset

Environment: Production, Chrome desktop and Safari iPhone-size viewport,
test account beta-login@ (email/password), test inbox
Severity: Critical (users who reset their password cannot get in)

Steps to reproduce:
1. Open /login and click "Forgot password?"
2. Enter beta-login@ test email and submit
3. Open the reset email in the test inbox and click the link
4. Set a new valid password and submit

Expected: Success message, then the dashboard (or login page with a notice)
Actual: Page alternates between /login and /dashboard; after several
seconds the browser shows "too many redirects". Logging in manually
with the new password works only after clearing cookies

Evidence: Screen recording of steps 3-4, annotated screenshot of the error

How to prioritize login findings

  1. Lockouts: valid users cannot log in or reset their password.
  2. Sessions that do not end: logout or password change leaves access open.
  3. Information leaks: messages revealing whether an email is registered.
  4. Broken recovery: expired or reused reset links with no explanation, 2FA dead ends.
  5. Friction: password manager problems, unclear rules, lost input.
  6. Polish.

Common mistakes

  • Testing with an admin or real customer account and locking it out.
  • Only testing in a browser that already has saved cookies and passwords.
  • Never testing the reset email itself, only the request screen.
  • Forgetting the "return to the page I wanted" redirect after login.
  • Testing login once at launch, then breaking it with an auth library upgrade.

Safe limits

Never lock a real account while testing. Use a dedicated test account and keep wrong-password attempts to one or two. If your product has rate limits or lockouts, test them on staging with a throwaway account, and tell the tester what the limit is.

Manual testing vs an AI beta tester

Real users reveal habits no script predicts: logging in from a shared computer, forgetting which social button they used, or searching an overflowing inbox for the reset email. Those real inbox habits and phone-based steps like push approvals are outside what an automated tester can reproduce.

An AI beta tester like betatest.ing is a good fit for the checks that must pass on every release. It logs in with your saved test login (encrypted and typed into the browser, never shown to the AI), runs the failure cases with limited attempts, follows the reset flow when it has a test inbox, checks logout and session behavior across tabs, and reports bugs with steps to reproduce, severity, annotated screenshots and a screen recording. A scheduled smoke test of login catches a broken auth deploy quickly. It does not run brute-force attempts, attacks or security scans.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Test login, logout and password reset on [LOGIN URL] using the saved test login. Log in, check where it lands, log out, then press Back and open a protected page directly to confirm the session ended. Log back in. Try a wrong password and an unknown email (at most 2 wrong attempts in total, never lock the account) and check the messages do not reveal whether an account exists. Try the email with uppercase letters and a trailing space, the show-password toggle, the Enter key, and "remember me" if present. Open the "forgot password" flow and request a reset; [RESET EMAIL HANDLING]. Check social login buttons open the right provider and cancelling returns somewhere sensible. Repeat the login form at mobile width. Log each bug with steps to reproduce and an annotated screenshot, and finish with a short report and a pass/fail table per check.

Fill in your details

Here, or later in the chat with your tester.

  • [LOGIN URL] Your login page, e.g. https://app.example.com/login (save the test login in the project first)
  • [RESET EMAIL HANDLING] e.g. "open the reset email in the test inbox and finish the reset" or "stop after the request step"

What the AI beta tester checks

  • Valid login and the landing page after it
  • Wrong password and unknown email messages (no account enumeration)
  • Email case and whitespace handling
  • Show-password toggle, Enter key and autocomplete attributes
  • Forgot-password request and confirmation message
  • Reset link, expiry and the new-password step (when the inbox is reachable)
  • Logout, Back button and protected pages while logged out
  • Remember me and multiple tabs
  • Social login buttons and cancel behavior

What you get

  • A pass/fail table for every login, reset and session check
  • Bugs with steps to reproduce and annotated screenshots
  • A screen recording of any broken flow
  • Notes on confusing or inconsistent error messages

How to run it with betatest.ing

  1. Add your app as a project and save a dedicated test login in the encrypted vault
  2. Paste the test task and fill in the login URL and how to handle the reset email
  3. Send it; the tester signs in and out in a real browser
  4. Review the pass/fail table and the bugs it filed

Tips

  • Use a test account that nobody relies on, so a lockout costs nothing
  • Tell the tester your lockout or rate-limit rules before it starts
  • Schedule this test after every auth or dependency upgrade
  • Check the reset email on mobile too: many users reset from their phone

Login testing: FAQ

Does the AI see my test password?

No. Logins are saved in an encrypted vault and typed into the browser for the tester; the AI itself never sees the password.

Is this a security test?

No. It checks that login flows work and behave sensibly for real users. It does not run attacks, brute-force attempts or security scans.

Can it test two-factor authentication?

Only if it can get the code, for example from a test authenticator setup you provide or a test inbox. Otherwise it stops at the 2FA step and reports the flow up to there.

Will it lock my account?

The task limits wrong attempts to two. Still, use a dedicated test account and tell the tester your lockout threshold.

What is account enumeration?

It is when login or reset messages reveal whether an email is registered, for example "no account with this email". The safer pattern is a neutral message for both cases.

Can it test the password reset email?

Yes, if you give it a test inbox it can access. Then it can open the reset email, follow the link and check that it works once and expires. Without an inbox it stops after the reset request and reports the flow up to there.

Do I need a separate test account for login testing?

Yes. Use a dedicated test account that is not an admin or a real customer, so a lockout or password change never affects anyone real. Tell the tester your lockout threshold.

How often should login be tested?

Run a short login smoke test after every deploy, and especially after authentication library, SSO or session changes. Login bugs can lock out every user at once, so it's worth catching them quickly.

Related beta testing guides

  • Signup flow testing — Signup and onboarding are where most new users decide whether to stay. This page covers what to test in a signup flow, the edge cases teams usually miss, and a test task your AI beta tester can run on your app today.
  • Form validation testing — Forms are where users give you their data, and where broken validation quietly loses leads, orders and signups. This page lists the edge cases worth trying on every form and a ready test task for your AI beta tester.
  • Regression testing after deploys — Regression testing checks that what worked yesterday still works after today’s change. For small teams shipping often, a short regression suite run after every deploy prevents most "it used to work" bugs from reaching users.
  • SaaS beta testing — In a SaaS product the beta test that matters follows a new customer from signup to the moment they get value and decide to pay. This page explains what to test at each stage, how to set up test accounts and billing test mode, and gives you a task your AI beta tester can run against your app.
  • Free tool: Test case generator — A table of test cases with steps, data and expected results, edge cases included. CSV and Markdown export.

More in by test type