How to test a login page

To test a login page, derive the cases from its rules instead of collecting them from a list. Split each field into partitions (the right username, the same name in other letter case, an unknown name, empty), combine the two fields in a decision table (right or wrong username × right or wrong password), follow the states (signed out, signed in, signed out again, a protected page and back), and add the checks every login page needs: one message for every wrong pair, a hidden password, no redirect to another site. For a simple page this gives about twenty cases, and each one can find something the others cannot.

About 20 cases: derived, not collected
5 sources: partitions, table, boundaries, states, risks
1 case: written out in full

How to test a login page, step by step

Step 1
Write down the rules
Messages, where the page sends you after signing in, which pages need an account, how signing out works. Ask about anything the requirement leaves out, such as a lockout.
Step 2
Split each field into partitions
Matches an account, other letter case, spaces around, no such account, empty. Take one value from each partition.
Open
Step 3
Build a decision table for the pair
Right or wrong username × right or wrong password gives four rules: one signs in, three show the same refusal.
Step 4
Carry over the sign-up boundaries
A password of the longest allowed length must sign in; the same password with its last character changed must not.
Step 5
Follow the states
Signed out, signed in, signed out again, and a protected page that sends you to sign in and back.
Step 6
Add the login-page risks
One message for every wrong pair, a hidden password, no redirect to another site, text that looks like a query, the Back button after signing out.
Step 7
Write each row as a test case
Exact data, labels as on screen, an expected result after each step, one invalid value per case.
Open

Start from the rules of the page

A login page looks simple, so it is often tested from memory. Write down what it should do first: every case below comes from one of these lines. If the requirement says nothing about something, such as what happens after five wrong attempts, ask before you test it.

Shelf is the practice shop the courses use. Its sign-in page at /login has the heading "Sign in", the fields Username and Password, a "Sign in" button and a "Create an account" link. The examples use an account shelf_tester_15 with the password kettle42.

The rules of the Shelf sign-in page

Empty Username: "Enter your username."
Empty Password: "Enter your password."
Wrong username or password: "The username or password is wrong."
Usernames ignore letter case; spaces around them are removed.
Passwords must match exactly, letter case included.
After signing in: back to the page that sent you here, or the catalog.
Cart, Checkout, Orders, an order page and Account need an account:
  signed out, they send you to /login and back after signing in.
Signing out: the "Sign out" button on the Account page.
A session that has ended: "Your session has ended. Sign in again to continue."

Step 1: partitions for each field

Split each input into groups the page should treat the same way, and take one value from each. The sign-in page checks only that a field is not empty and that the pair matches an account; it does not check length or characters. So its partitions differ from the sign-up form's: what matters here is whether a value matches, not whether it is well formed.

Look at kettle4 in the table. It is 7 characters, one under the sign-up minimum, yet the sign-in page should refuse it with the usual wrong-pair message, not with a length rule. A sign-in page that repeats the sign-up rules tells a stranger something about the passwords it accepts.

Partitions

Username (password kettle42)  Value              Expected
matches an account            shelf_tester_15    signed in
other letter case             SHELF_TESTER_15    signed in
spaces around                 2 spaces + name    signed in
no such account               shelf_nobody       wrong-pair message
empty                         (none)             "Enter your username."
spaces only                   3 spaces           "Enter your username."

Password (shelf_tester_15)    Value              Expected
matches                       kettle42           signed in
other letter case             KETTLE42           wrong-pair message
one character short           kettle4            wrong-pair message
empty                         (none)             "Enter your password."

Step 2: a decision table for the pair

Two fields that are each right or wrong give 2 × 2 = 4 combinations. Only one of them signs in; the other three must show the same message, word for word. Testing all three is the point: a page that says "no such user" for one and "wrong password" for another tells anyone which usernames exist.

Empty fields stay out of this table: the form stops them before the pair is checked, so each gets its own case. Leave both fields empty once as well, to see both messages appear together.

Decision table

Rule                        1    2    3    4
Username matches an account T    T    F    F
Password matches it         T    F    T    F
Signed in                   X
"The username or password        X    X    X
 is wrong."

Rule 3: an unknown username with kettle42, a real password of another account.

Step 3: boundaries carried over from sign-up

The sign-in page has no limits of its own, but the passwords it compares were created under the sign-up rule of 8 to 72 characters. The edges of that rule are worth a second look here: an account whose password is exactly 72 characters must sign in with all 72, and must be refused when only the last character differs. That pair catches a password cut short somewhere between sign-up and sign-in, a defect no short password can find.

The shortest valid password needs no extra case: kettle42 is 8 characters, so the main positive case already covers it. The boundaries guide shows how the 8 and the 72 are tested on the sign-up form itself.

Boundary value analysis and equivalence partitioning

Step 4: states and pages that need an account

A login page changes one thing: whether the visitor is signed in. Treat it as a model of states and follow every move once. Each move is one case, and a path through all of them makes a quick check after every new build.

Sign in from /login
Signed out, sign in with the right pair. Expected: signed in, on the catalog.
Sign in from a page that needs an account
Signed out, open /cart. Expected: the sign-in page; after signing in, the cart.
Sign out
Signed in, select "Sign out" on the Account page. Expected: signed out; opening /orders sends you to sign in.
A session that has ended
Expected: the next page that needs an account shows the sign-in page with "Your session has ended. Sign in again to continue." and returns you there after you sign in.

Step 5: checks every login page needs

These come from what goes wrong on login pages in general, a technique called error guessing. Each still has an expected result from a rule; the rule is just one that every login page shares. Run them only on systems you are allowed to test.

Pages with more features need more cases: a "Forgot password" link and its reset link used twice, "Remember me", a lockout after several wrong attempts. Shelf has none of these, so its list stops here.

One message for every wrong pair
Compare rules 2, 3 and 4 word for word. Any difference reveals which usernames exist.
The password is hidden
Typed characters show as dots, in every browser you support.
No redirect to another site
Open /login?next=https://example.com and sign in. Expected: you stay on Shelf, on the catalog.
Text that looks like a query
Enter ' OR '1'='1 as the username with any password. Expected: "The username or password is wrong."
Enter submits the form
Press Enter in Password. Expected: the same result as selecting "Sign in".
Back after signing out
Sign out, then press the browser's Back button. Expected: nothing there works until you sign in again.

One case written out

Every row above becomes a test case with exact data. Here is the letter-case row, written in the format the test cases guide describes. A case like this one is worth having in a regression suite: a change to how usernames are stored can break it without touching the sign-in page.

Example

Title: Sign in with the username in capital letters
Priority: Medium
Module: Sign in
Preconditions: Signed out. The account shelf_tester_15 exists, password kettle42.
Steps and expected results:
  1. Open /login  ->  the "Sign in" form with Username and Password
  2. Enter "SHELF_TESTER_15" in Username  ->  no message
  3. Enter "kettle42" in Password  ->  the characters show as dots
  4. Select "Sign in"  ->  signed in, on the catalog
Postconditions: Signed in as shelf_tester_15.

Why twenty derived cases beat a list of fifty

Lists of "50 test cases for a login page" are easy to find. Read one with partitions in mind and most lines collapse: "wrong password", "invalid password", "incorrect password" and "password with a typo" are one partition and one test. The same lists often miss the cases that need thinking: one message for every wrong pair, letter case in the username, a password at its maximum length, the page you return to after signing in.

Count your set the other way round: one case per partition, one per rule of the table, one per carried-over boundary, one per move between states, one per shared login-page risk. For the Shelf sign-in page that gives about twenty cases, and every one of them has a reason to exist.

Where to learn this

Questions and answers

How many test cases does a login page need?

As many as it has partitions, table rules, states and shared risks, not a fixed number. A simple page with a username and a password gives about twenty; a page with password reset, "Remember me" and a lockout gives more.

What are the negative test cases for a login page?

An empty username, an empty password, both empty, an unknown username, a wrong password, the password in other letter case, and text that looks like a query. Each gets its own case, so a failure points at one input.

Should a login page say whether the username or the password is wrong?

No. One message for every wrong pair keeps strangers from finding out which usernames exist. Check it by comparing the messages for an unknown username and a wrong password word for word.

Should usernames be case-sensitive?

That is the product's rule to decide, so find it before you test. Passwords must always match exactly, letter case included. On Shelf, usernames ignore letter case and passwords do not.

Should I test SQL injection on a login page?

One or two simple inputs belong in any login test, and the expected result is the normal refusal. Deeper security testing is a separate job, done only on systems you have permission to test.

How do I test a lockout after failed attempts?

With boundary values on the count. If the rule allows five attempts, test the last allowed attempt and the first blocked one, the right password right after the lockout, and what resets the count.

More guides

See the first course

The full outline of every course is available: you can see each lesson before you start.

All courses

How to test a login page