Test Cases For Change Password

Test Cases For Change Password: It’s important to keep your work data safe, and one way to do that is by regularly changing your passwords. This may seem inconvenient, but avoiding potential dangers is worth doing. For example, if you save passwords on a computer you no longer own, those passwords could be at risk.

So in this blog post, we will see how a user can write an effective test case to change the password. But before that, one should know the basic requirements for a password.

Post On:	Test Case For Change Password
Post Type:	Test Case Template
Published On:	www.softwaretestingo.com
Applicable For:	Freshers & Experience
Join Here:	SoftwareTestingo Group Link

Why do We need a Strong Password?

Creating a strong password that would be difficult for someone to guess is important to keep your accounts secure. One way to ensure you won’t forget your password is by storing it in a password manager. A stronger password makes it more resistant to being guessed, so it’s less likely to be found in a brute-force dictionary hack.

Strong Password Examples:

The list of some of the Strong passwords is very difficult to guess. Here is the list: 1Ki77y, jelly22fi$h,!Lov3MyPiano,SterlingGmail20.15, etc.

As you know, to give access to the application to only valid users, each organization creates accounts for the users. That’s the reason validating the Password field in a detailed manner is a major concern. For this reason, only each organization forces users to change their password for a specific duration.

So, in this post, we will see how a tester can validate the change password flow in a detailed manner so that unauthorized users can not access the application.

UI Test Case for Change Password

• Verify When the user clicks on the change password link, the User should navigate to the Change password page.
• Check the 3 Password Fields: Old password, New password, and confirm whether password fields display.
• Verify the mandatory password fields are marked with a red star “*” symbol.
• Check whether the label text is properly displayed or not.
• Check whether the placeholder is properly displayed or not.
• Check that the alignment of the text field is properly displayed or not.
• Check that tab key functionality is properly working or not not

Functional Test Cases for Change Password

• Check whether the password fields are clickable or not.
• Check whether the change password button is Clickable or not.
• Check whether the validation messages are displaying or not based on the test data.
• Check whether the change password functionality is working by entering a valid password.
• Check the MAX and MIN Limit for passwords as per the requirement document.
• Check the progress bar for the password field is displaying or not by entering a password.
• Check whether the password strength displays (Easy, weak, or Strong) as per the SRS document.
• Check whether the Change Password functionality works by entering valid old passwords and matching new and confirmed passwords.
• The change password should not work by leaving the old password field blank and entering the valid new and confirmed password.
• Check the password change functionality by entering the old invalid and valid (matching) new and confirmed passwords.
• Check the Functionality of changing the password by entering the valid old password and confirming the password by leaving the new password field blank.
• Check the Functionality of changing the password by entering the valid old password and a new password by leaving the Confirm password field blank.
• Check the Functionality of changing the password by entering the valid old password and leaving the New Password and Confirm password fields blank.
• Check the functionality of changing passwords: Leave all the fields (old password, new password, confirm password ) blank.
• Check the Change password functionality by entering the valid old password and entering only the blank space in the new and confirmed password.
• Enter the mixed password (Alphabet, Number, Special symbol) to check the functionality.
• Check the alert message for the mixed password when the user clicks on the change button without entering the mixed password if it is mandatory.
• Check if the alert message is displayed by clicking the change password button without entering the data in the mandatory field.
• Check whether the confirmation message displays after the password has been changed successfully.
• Check the alert message when the user enters the wrong password.
• Check whether the reset button is Clickable or not.
• Check the reset button functionality by entering the Password.
• Check the reset button functionality without entering the password.

Negative  Test Cases for Change Password

• The user cannot change the password by entering an invalid current password.
• Users should not be allowed to change their passwords by entering mismatched new and confirmed passwords.
• Users should not be allowed to enter more than the maximum character allowed per the requirement document.
• The user should not be allowed to change the password by entering blank values.

Conclusion:

I hope this change password test case has been helpful to you. It should be sufficient to run any sanity check for changing passwords and test detailed conditions. It can be helpful to have all fields be required in a change password test so that users are less likely to forget to update their passwords. We have checked our other posts and discussed the test case for a password reset.

You must test your password policy thoroughly to ensure it’s effective. You can add test conditions or create test cases to focus on specific areas. There’s no one way to validate change password test cases – make sure you cover all the bases and requirements. Let me know what you think and if you have any suggestions.