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.
Table of Contents
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.
- Pre-Condition: Register New User in the Application.
- 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 ID | Requirement Description | Notes |
|---|---|---|
| BRD-REQ-001 | System must allow user to change password | This is a high level requirement that will generally be captured in the BRD. |
| ITSEC-REQ-0001 | Password must be masked | |
| ITSEC-REQ-0002 | Password must be at least 6 characters which must include at least 1 letter in upper and lowercase, a number and alphanumeric character | |
| ITSEC-REQ-0003 | The new password must have not been used in the last 12 months (old password) | |
| ITSEC-REQ-0004 | Password expires after 30 days | |
| ITSEC-REQ-0005 | Password cannot contain the user’s username. | |
| ITSEC-REQ-0006 | Password cannot contain the user’s full name. | |
| ITSEC-REQ-0007 | If user ‘old password’ is entered incorrectly 3 times, the account is locked. | |
| ITSEC-REQ-0008 | Password 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-0009 | Browser should not allow storing of password | This 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 Number | Test Step | Requirement ID | Expected Result | Actual Result | Status(Pass / Fail) | Positive / Negative Test |
|---|---|---|---|---|---|---|
| Login to Application | ||||||
| 1 | Access Login form page for Application under Test (AUT) | User lands on the login page. | + | |||
| 2 | User enters a valid username | Username field is populated with correct and valid username | + | |||
| 3 | User enters a valid password | Password field is populated with valid password | + | |||
| 4 | User enters a Captcha / 2FA / or answers a security question. <Amend accordingly depending on your organisational requirements.> | User populates the field with additional security information. | + | |||
| 5 | User clicks on ‘login’ | User successfully logs into the Application. | + | |||
| 6 | Locate 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. | + | |||
| 7 | Locate 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 | ||||||
| 8 | Negative 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. | |||||
| 9 | Enter 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 | ||||||
| 10 | Re 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 | ||||||
| 11 | Click the ‘submit’ button. | System allows password change System confirms that password has been successfully changed. Browser does NOT allow saving of user credentials. | ||||
| 12 | User logs out | User logged out | ||||
| User logs back in and Validates Password Change | ||||||
| User navigates to Login page | User is on login page | |||||
| 13 | Enter valid username | Valid username is entered | ||||
| 14 | Enter correct NEW password Note: This is the updated password | New password entered Password field is masked | ||||
| 15 | Click submit button to validate login | The 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;
- 0-5
- 6
- 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.
You can use this type of tests when you’re designing test cases for a hotel booking system or even an ATM Machine.
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.
