How to write Test cases for Change Password to Help Speed Up Your Test Design

Test Cases for Change Password featured image 800x419

Within the software testing industry, there are some tests you’ll probably run many times during your career.

The ‘Change password’ is one such functionality you can add to your repertoire of tests.

In this article I have created a detailed test case for “change password “ functionality.

The test case below is a good starting point that encompasses most of the common features you’d expect as part of a password change feature.

It’s VERY difficult to make this compatible with every single operating system, browser, desktop, mobile app etc.

Please remember to make the necessary changes to suit your own system requirements.

Hopefully this gives you a real head start when designing your tests.

If you want to learn more about how to write a test case, then you should familiarise yourself with that first.

Context in which the Test Case was written

It’s important to understand the context in which this test case is written.

There are “many ways to skin a cat” (English proverb) so let’s set some expectations for clarity.

Purpose of Test

The purpose of this test is to prove that the change password feature works on a web based desktop application.

The user still has a valid password which has NOT expired.

They simply want to change it as part of their IT security policy as the password will expire in a few days..

High Level User Journey

In order to complete the test, the User would typically embark on a high-level journey which I have highlighted below.

  • 1. Login to Application
  • 2. Locate the ‘profile’ /’settings’ / ‘account’  option.  
  • 3. Enter Old Password
  • 4. Enter New Password
  • 5. Confirm Password
  • 6. Submit for Authentication
  • 7. Validate Password Change

For the complete test which includes all the steps, please keep reading.

Test Requirements and Conditions

If you have some kind of requirement document(s) such as a BRD or FRS, then I’d expect to add them to a Requirements traceability matrix and design my tests from there.

It makes it a lot easier when you have requirements in an RTM.

An example of some requirements are listed in the table below.

Password Policy Requirements

Below is a table that outlines some password requirements.  This is just for illustration purposes.

Table 1 – Password Requirements

Requirement IDRequirement DescriptionNotes
BRD-REQ-001System must allow user to change passwordThis is a high level requirement that will generally be captured in the BRD.
ITSEC-REQ-0001Password must be masked
ITSEC-REQ-0002Password must be at least 6 characters which must include at least 1 letter in upper and lowercase, a number and alphanumeric character 
ITSEC-REQ-0003The new password must have not been used in the last 12 months (old password) 
ITSEC-REQ-0004Password expires after 30 days
ITSEC-REQ-0005Password cannot contain the user’s username.
ITSEC-REQ-0006Password cannot contain the user’s full name.
ITSEC-REQ-0007If user ‘old password’ is entered incorrectly 3 times, the account is locked.
ITSEC-REQ-0008Password must not be a ‘common’ password.This will not be shown to users but common passwords like ‘12456’, ‘password’ and ‘letmein’ will prompt you to re-enter a more secure password.
ITSEC-REQ-0009Browser should not allow storing of passwordThis might not always be allowed but might be possible when inside a controlled work environment.

You might also want to read the article titled ‘Password administration for system owners’ by the UK’s National Cyber Security Centre.

It gives some great advice on how you should approach password policies for your organisation.

Pre Conditions

Some Pre Conditions you may want to think about are;

  • User has already sanity checked that the account is valid and working.  This may be in the form of another test case that runs prior to the test case in this article.

Data Setup

The data setup items that come to mind are;

  • The User account must already be setup
  • The account must be set up so it generates a warning message to the User informing that the account is due to expire in ‘x’ number of days.

The Final Test Case with Test Steps 

Let’s take the user journey above and break this down into a Test case.

Step NumberTest StepRequirement IDExpected ResultActual ResultStatus(Pass / Fail)Positive / Negative Test
Login to Application 
1Access Login form page for Application under Test (AUT)User lands on the login page.+
2User enters a valid usernameUsername field is populated with correct and valid username+
3User enters a valid passwordPassword field is populated with valid password+
4User enters a Captcha / 2FA / or answers a security question.  <Amend accordingly depending on your organisational requirements.>User populates the field with additional security information.+
5User clicks on ‘login’User successfully logs into the Application.+
6Locate the ‘profile’ /’settings’ / ‘account’  option.  
Note:  Change this to the option in your web based application.  
The ones listed are popular ones I have come across.
User is navigated to their profile page which displays a ‘change password’ option.+
7Locate the ‘change password’ / ‘reset password’ option and select it.User is on the ‘Change Password’ page.
The following fields should be displayed;
Current PasswordNew PasswordConfirm New Password
+
Enter Old Password
8Negative Test Validation: In the ‘old password’ field, enter an incorrect password.
Note:  Leave the 2 other fields empty  
Incorrect password is entered.
Password is masked
Select the ‘Submit’ button.The appropriate validation message is displayed.
For example;“Current password is incorrect”
“New Password” field cannot be blank
“Please confirm your New Password” as this cannot be blank.
9Enter old password which is a required field
Enter correct password
User enters correct password
Password field is  masked.
+
Enter New Password
Enter valid password in  the New Password field (required field)  New Password is populated in field
Password is masked.
+
Confirm New Password
10Re type new Password (required field).  
Note: Must match the field above.
‘Confirm New password’ field is populated with the exact password populated in the previous field.
Password is masked.
Submit for Authentication
11Click the ‘submit’ button.System allows password change
System confirms that password has been successfully changed.
Browser does NOT allow saving of user credentials.
12User logs outUser logged out
User logs back in and Validates Password Change
User navigates to Login pageUser is on login page
13Enter valid usernameValid username is entered
14Enter correct NEW password
Note:  This is the updated password
New password entered
Password field is masked
15Click submit button to validate loginThe user is allowed access and can login to the application with the NEW changed password.
*** End of Test ***

Positive Tests

When writing your test, start with a positive end to end flow (happy path) and then add in the negative tests (only where it makes sense and doesn’t break the flow).

Negative Tests

You’ll want to add some negative tests as part of the tests to ensure the system is resilient against your organisation’s security requirements.

When planning your negative tests, try and test these first before the positive flow as this will allow you to test both negative and positive as part of an end to end test.

Other considerations

Boundary Value Analysis

If the password is supposed to be a minimum of 6 characters then the boundary value will be 5 and 6.  

Equivalence Partition Tests

If the password is supposed to be a minimum of 6 characters, your partitions are essentially going to be;

  1. 0-5 
  2. 6 >

You should only go to these lengths if there is a requirement to test the password policy requirements.  

Otherwise keep your tests very succinct and avoid overkill.

Building your Regression Pack

The great thing about writing evergreen test cases is that you can add them to your test suite.

This is ideal for when you conduct regression testing.

I really like creating a regression pack and it’s always good to see them being updated and getting bigger and better.

The test case mentioned in this article is a really good example of one that can be reused over and over again either as a manual or automated test.

Various Scenarios to Test

The ‘change password’ feature can occur during several different scenarios, below are some scenarios you might want to consider as part of your test plan which are currently out of scope in this article.

Validate Single Sign-On Authentication works when Password is Changed

If you’re using a Single Sign-On (SSO) feature then you will need to ensure that all applications are accessible via a single authentication.

Simply change the password from the source, login via your SSO and ensure applications are accessible.  Of course that will depend on your current permissions.

When password HAS expired and user is expected to change password next time they log in

In this scenario, the user will be expected to login using their previous credentials and will be forced to change their password straightaway.

For this test, you can remove the steps where the user navigates to the relevant page.  Just change it so that the user has to change it from the main login page.

User is forced to change their password due to a data breach

This test is almost identical to the test above.

The only difference is that the password has not expired but the user is forced to change their password due to a security breach.  

Wrapping Up

I really hope this test case has provided value to you.

It should be sufficient to run any kind of sanity check for changing of passwords as well as testing detailed conditions..

The great thing with the change password type of test is that there aren’t any optional fields.  You’ll have to enter an old valid password and a new password with a confirmation.

That’s it.

If you need to test your password policy then just add in those test conditions to thoroughly test it.

There are some example steps included.

Otherwise you can create further test cases to test specific areas.  There’s no right or wrong way of doing things.  

Just make sure you have full coverage of your requirements.

You might also want to consider creating a test case for date of birth as part of the test suite.

Please let me know your thoughts and if you have any suggestions.