Because it offers access to a whole website or programme, the login procedure is the most critical feature of any system/application. You'll learn a lot about login testing from this post.

When a user logs into an online or mobile application, they are presented with a login screen, which needs them to provide a username and password. Because it allows access to a complete website or programme, the login procedure is the most important aspect of any system/application. As a result, the login screen must be thoroughly tested.

You can use the guidelines below to test your logins.

UI/UX:

It is important to check the order in which the tab key is used.

The pointer should be at the username field when you land on the website.

Entrée: Verify if Login button is active when entering.

All fields on your page should be clearly defined and labelled.

Examine the page's appearance and alignment.

Check the page's content to see if it's up to par. Exist any spelling or grammatical errors on the screen?

Current links - Verify that any existing links on the page are still valid.

Check the login screen's responsiveness in different sizes.

Security Checks:

A password is either visible or concealed (using asterisks)

Try copying and pasting a password from another application.

Password - Check to see if the password has a minimum level of difficulty

Make sure there is a "Show password" option available. If so, check to see if it's working properly.

Find out if the login screen searches for the most common passwords (CommonPasswordsList)

Source – Check the application's source code to see whether any useful information has been divulged. It's possible that the login page could be vulnerable to SQL injection.

If you can view the other pages of the application without signing in, this is a good indicator that you can.

Editing URLs to obtain access to other pages of the programme is one way to see if you can acquire access where it shouldn't be possible (without login).

When utilizing several accounts, check to see if you may be logged in simultaneously in the same browser by using various accounts.

Try editing and/or disabling cookies.

Functionality:

The login function can be tested with and without credentials.

Try logging out if you haven't already done so. Ensure that the user is completely logging out.

Lost password - Check to see if there is a lost password option available. Then again, if it's there, does it work correctly. Look for security issues and possible URL manipulation as well.

Using the browser's Back and Forward buttons will let you know how well the application performs.

Look for the option to "Remember me" if it is available. And if it's there, does it work as expected. Check what happens if the password is changed.

The Login/Logout functionality should be tested in various browsers for all conceivable valid/invalid scenarios.

Data - Validate the username and password entries (Is there a minimum or maximum length of characters, boundary-values, what are the allowed characters, etc.).

What happens when there is an error? (for negative cases).

Examine the login form with JavaScript disabled.

2FA If you're using two-factor authentication, check the login process. If you're not, check the lockout procedure and the recovery process.

INDIVIDUAL TEST USERS

Some issues were not repeatable during the early stages of our work. After clicking a button or link on the screen, an entirely another website may open, or an error may appear without any explanation. Investigating this was difficult due to its non-reproducible nature and the fact that it didn't happen all the time. It was only after some time that we figured out what was going on: user accounts.

There were test users created at the outset of this project in every environment and since I was the only tester, I would have access to those accounts. It took a while, but we eventually determined that our configurators and developers should unit test their new features before releasing them for testing, to increase the quality throughout our entire development process. In making this decision, we didn't take into account which users would be used for these intakes. So they used the test user accounts, which is fine if no one else is using the account at the same time, but it becomes a problem if many users are using the account at the same time. Your test results are ruined because Salesforce becomes confused and messes up all of your data.

Afterwards, everyone had to create their own test account. Save yourself a lot of time by eliminating false positives!

Thanks for reading and happy testing!

Related Post