About 8 years ago Ministry of Testing (then Software Testing Club) crowdsourced ideas for testing a login page. The responses from the group were documented, Iāve attached them to this post. You can see the login screen on the second page.
I think many take login screens for granted as having an obvious set of tests. There are many different things to consider with login screens. They are usually the first thing users will meet for your application so giving a good impression at this point is pretty important!
Would you add anything to the listed ideas? Maybe youād elaborate on or extend some of them a bit more.
The information covers most of the testing around the login screen. I would expand on data and security/error handling.
The data field may allow characters that are not handled correctly by the database without proper encoding. Copy and pasting of the password is mentioned but itās not clear that testing could cover copying from the field and pasting in notepad could show the password in clear case versus copying the password from a MS Word document, that include unintended hidden characters.
In regards to security and error handling, some applications lock the user out of their account after X number of tries. Emails may be sent to the email on file notifying user the account is locked. Procedures for unlocking the account should be tested (i.e., lock clears after 30 minutes, after user resets their password from a link, etc.).
Testing a login form seems a trivial process, but to keep up with security requirements and usability efforts, this trivial process has got very complex.
A few things we test for that were not mentioned in the PDF guide, are focused on testing the security of the login form.
data overload: how much data can we submit through the form so the system fails. We copy a complete encyclopedia (~4GB of data) and paste it in the password input field as there is less validation on input.
common password lookup: after the multiple breaches that occurred in the past decade, millions of passwords have been analyzed and a list is being published each year with the most common passwords (see WikiPedia). Is the login form performing a lookup in this list?
JavaScript off test: since most forms are now making asynchronous posts using JavaScript for input validation and password strength checking, is the form still working when JavaScript is disabled?
When two-factor authentication is being provide, the tests are extending even further.
test with invalid token
test with valid token
test with invalid backup code
test with valid backup code
test lockout procedure
test recovery process
And when teams are involved, roles of team rights for account restore procedure needs to be tested as well.
Jared Spool (aka God of UX) did a brilliant talk on what he called SUX: Security UX. Iād highly recommend watching the video or reading through the slides. To quote "If itās not usable itās not secure." https://www.uie.com/jared-live/#fix-ux-of-security
This is fab, I have used a Login Screen print out as an exercise to give candidates for test jobs for the last couple of years. Not as a pass/fail but as a quick measure of someoneās knowledge and ability. My ākey areasā list is pretty much the same as the original document, but also has responsiveness and performance on top.
I was reading Wired over the weekend and came across this article of Mister John Null. Just like most Irish people (e.g. OāDonnel) he too is not accepted as a person when signing up for online services.
Iāve also seen cases where you could sign up with all of these things but you couldnāt sign in with them. @dominic1 has a good set of examples that he uses too if I recall correctly
The ābig list of naughty stringsā I knew, but not the plugin. Thanks! Seems handy also to just quickly input valid data (I use Autofill to quickly fill in long forms that I encounter often, Bugmagnet seems usefull to just quickly generate a name or Lorem Ipsum text).
Iām thinking of the context first. What are we talking about here?
What I know so far is that thereās a login screen:
Login = an act of logging in to a computer, database, or system.
Screen = a flat panel or area on an electronic device such as a television, computer, or smartphone, on which images and data are displayed.
There are different types of āālogināā/authentication: logon, login, sign-in. Are they under the same discussion?
Do we just consider a fully virtual environment or a combination with real device, physical actions also? like eye or hand scan, badge or card, keyboard code buttons; interaction between multiple devices or platforms? have a token to login to bank account, have a key/badge and a code to start/stop the house alarm, IoT + other platform/deviceā¦
What about the device type used? pc, mobile, tablet, ioT, token, medical device, other kinds of hardwareā¦
OS dependent or or is it built/linked to the device?
Login screen type?: pin, command line, text-field, dots, fingerprint-reader, signatureā¦
Application type?: hosted, server, web app, mobile app.
Online or offline login?
The list of questions can get pretty bigā¦and in my opinion these can be considered tests also.
Regarding testing of field validations, we know that exploratory testing isnāt amenable to automation however it would easily be possible to create an automation framework containing the types of test data used in Bug Magnet, link it into (say) Selenium and fill various form fields with them to iteratively test for errors or some unexpected behaviour. When an error is found a further check could be made on test data of a specific category (i.e. names with accents, extreme or out of bounds numbers).
It wouldnāt take much effort to create it and I need a hobby anywayā¦
thatās quite impressive.