Login page test cases: what a stranger tries

Login pages fail at their edges, and your own sign-in never reaches the edges. Your browser fills the saved password, so the form never sees a typed one. Your session stays open, so a sign-out you never tested still looks like a sign-out. An invitee types the password from an email, sometimes with a trailing space, and gets an error that does not say which field is wrong. Then they open the reset link on a phone, and it points at a domain that is not the live site.

• Sign in with a saved password, then with one typed from scratch on a phone.
• Enter a wrong password once and check the message and the email field.
• Request a reset, open the link on a phone, then open it a second time.
• Sign out, press the back button and check whether the dashboard comes back.

A browser that autofills a saved password can fill the visible field without firing the input events the page script listens for. The form then reads an empty password, and the button stays disabled or sends nothing. Pressing Enter in the password field should submit the form, but some scripts only listen for clicks. A stranger on a phone may never reach the button at all.

A tell separates the causes. Open the browser's network panel and press sign in. If no request leaves the browser, the page stopped the submit on its own side, so check the form's own validation and the autofilled values. If a request goes out and returns a 401 or 403, the server refused the credentials, and the page should say so. A 500 is a server fault, and a clearer message will not fix it.

'Something went wrong' tells a stranger nothing, and they assume the account is gone. A message that says 'No account with that email' tells anyone typing a guess which addresses have accounts. The right version is one message, such as 'Email or password is incorrect', shown for both an unknown email and a wrong password, with the email kept in its field and the password cleared.

A locked account needs the same care. A few failed attempts with no message look like a broken site to an invitee who only mistyped twice. The message should say the account is temporarily locked and point to the reset link, without saying how many attempts remain or hinting that the email exists. Test it with a wrong password first, then the correct one.

A reset email reaches a visitor's inbox. The link inside it is built from the site address the app was given at deploy time. If that address still names staging, the email arrives and the link opens a page that does not match the live app, or no page at all. A link that works once and says expired on reuse is expected. A link that says expired on the first click is a bug.

Right looks like this, in order: the email arrives, the link opens the live domain, the new password form accepts a password different from the old one, and the old password stops working. Wrong looks like a reset email whose link goes to staging, or a reset form that rejects a new password with a message about the old one.

Login breaks again when the auth provider updates, a cookie moves to a new domain or a session length changes in a settings file. Run the same login cases on every preview before a beta invite goes out, and again after each change to sign-in. On paid credits, visitors can sign in with a test account you give them, so the correct sign-in case runs on every pass.