How to Write Test Cases for Login Page

A login page is one of the initial points of interaction between a user and a system and definitely one of the most significant ones. Web and mobile apps, e-commerce platforms, and a variety of other software solutions offer only limited functionality to unlogged users. A person needs to register and enter to access the core features that make the essence of software and its value.

What does it mean for QA specialists? Working on test cases for a login page requires being as meticulous as you can. If you need some help with this task, here’s a short guide on test case writing.

Different Formats of Test Cases

A couple of things can influence your choice of the test case format. Firstly, the more complex functionality is, the more details you will need to include in a test case. Secondly, the format can be dictated by the configurations of test case management software your team uses. Finally, it can depend on the generally accepted practices within a QA company or a development team.

How to Write Test Cases: a Comprehensive Guideline

If you don’t use any test management software, you can write test cases in Google Spreadsheets or Microsoft Excel. You’ll find an example of the formatting further in the article.

It is better to clarify which format to use before you start writing test cases. It can save you a lot of time.

Test Case Example #1

At the very beginning, we need to make sure that the login page looks like it is intended to look. Let’s suppose everything is fine and there are no UI defects. Then, you can get a test case that looks like this.

ID

LP-1 (LP for Login Page, 1 as an ordinal number)

Summary

Check Login Page displaying.

Steps

1. Open front end (or: open the website + active link).
2. Proceed to the login page.
3. Pay attention to the page layout.

Expected results

The login page opened.

The page looks as expected.

Actual results

The login page opened.

The page looks as expected.

Status

Passed

Now, let’s imagine things aren’t that good, and there is a bug. In this situation, everything in your test case will remain the same, except for two last clauses – actual result and status. It can go like this:

Actual results

The login page opened.

The label text overlaps with the input field.

Status

Failed.

Or like this:

Actual results

The login page didn’t open.

Status

Blocked.

As you can see, the wording will depend on what actually happens at this stage.

Test Case Example #2

Test cases have slightly different names of clauses they include or a different sequence of those clauses. You can find an example below. Let’s start with bug-free functionality again.

Test #

LP-2

Test description

Check top navigation for a logged-in user.

Inputs

1. Open front end.
2. Log in as a registered user.
3. Check links in the header of the page.
4. Try to open the My Account section.

Expected Output

A logout link is displayed for a logged-in user.
A logged-in user can open the My Account section.

Pass/Fail
Pass

If there is a bug, you add one more clause at the end and describe what happens:

Defect

A logged-in user can’t open the My Account section.

Or:

A logout link is not displayed for a logged-in user.

Test Case Example #3

Some cases require preconditions (actions to perform before executing a test case) and postconditions (actions that return the system to its initial state). Sometimes software testers also decide to include priority in their test cases. Thus, you can end up with yet another format of this test artifact:

1. Preconditions.
2. Summary.
3. Priority.
4. Steps.
5. Expected result.
6. Postconditions.

Given the importance of a login page, the majority of test cases for login page will have a high priority. Here’s an example of a test case with preconditions, postconditions, and priority included.

Test Case #3

Preconditions
A user is logged into the system.

Summary
Check the Back button.

Priority
Medium.

Steps

1. Log out of the system.
2. Click the Back button.

Expected result
The user is not logged. The login page is displayed.

Postconditions
To access the features for logged-in users, a user has to log in again.

All the test case examples shared above are correct and frequently used. Moreover, you can be certain to discover even more variations of test case formats. Once again, if it’s your first time creating test cases, specify the details with other team members. If you are studying or working on a test task, go with the most detailed test case or mix several, showing that you are aware of the variations 😉

List of Test Cases for Login Page

All the login pages are more or less the same. There will be slight differences in design, but they don’t affect the approach to test case writing fundamentally.

We won’t write a test case example for every possible user input here. Instead, we’ll share some ideas that will make test case writing easier. Below, you will find summaries that can become the background for test cases for your project. We’ll include the Forgot Password summaries, too, though technically, you can distinguish them as a standalone group of test cases.

Positive Test Cases for Login Page

• Log in with valid credentials.
• Check the Show Password feature.
• Check the Remember Me checkbox.
• Check the autofill.
• Check the Log Out button.
• Restore the password with a registered email.
• Check the Forgot Password email.
• Create a new password using valid data.
• Log into the account using a new password.
• Switch between input fields using Tab.
• Log into the system using the Enter button.
• Log in with valid credentials in different browsers.
• Log in with valid credentials using different devices.

Negative Test Cases for Login Page

• Log in with empty required fields.
• Log in with an invalid email.
• Login with an unregistered email.
• Log in with an invalid password.
• Log in with both email and password invalid.
• Restore a password with an invalid email.
• Restore a password with an unregistered email.
• Restore a password with empty required fields.
• Restore a password using non-matching new passwords.
• Log in to the account using an old password.

Top E-Commerce Test Cases

To Sum Up

The login page is often the foundation for the core features. If it doesn’t function properly, a software product/service becomes pretty much useless. Make sure to cover a variety of situations that can happen during a user’s interaction with the system.