Back to basics 3: Login

You can find the "game rules" for this series here.

I'm looking at some core examples of website functionality and test ideas for them based on oracles and heuristics.  Last time we looked at registering / creating an account.

One key heuristic you hear in use a lot is CRUD or create, retrieve, update delete.  This is the standard lifecycle of a lot of items you can create in a computer system.

In many ways an account is no different, we

• create - when we register for an account (part 2)
• retrieve - every time we login to the system (this part)
• update and delete - when we need to modify our account (part 3)

So we're really going to do the CRUD testing over the whole series of these articles.

Oracles


Occasionally I come across someone who'll ask about testing the login "I enter my username and password, how hard can it be?". I need a meme to help me explain this, but ...

Really our oracle is not only "how we've seen login systems work before", but also our understanding of why the login exists.  The login exists to allow me access to my account, but to also keep others out.  Thats why we have the password!

So any testing needs to be around the rules of when I should be able to log in, and when I shouldn't.  With computing power being what it is now, we don't today have systems that allow unlimited tries to login.  Typically there's a rule out there that if someone forgets their password a set number (typically 3-5) consecutive times, then the account is locked.  This stops someone just nuking the account with password attempts until it breaks open.

Locking can mean different things - it could be the user has to contact the helpdesk to get it unlocked.  It could be it remains locked for a hour (limiting the hacker to 48 attempts to crack the password a day, not great but still better than unlimited).  But however, it fundamentally limits the number of tries you make, because any successful login after so many fails will be treated as a fail.

Also we need to think of not just login but also logout.  You want the system to auto log you out after inactivity.  You don't want to be able to logout, then someone log you in again by just hitting the back button.  If your login url is "yourapp/login" and your account url is "yourapp/account?userID=1234" you don't want to be able to get into the account just by changing "login" into "account?userID=1234" on the browser address bar.  [You may laugh, but it's been done].  

I have to admit the last two there "back button doesn't relogin" and "changing address bar to hack in" are blurring the line of understanding that I have between an oracle expected behaviour and a heuristic.  But in a way, it doesn't matter - you don't get exam questions on this - the important thing is that it's used to generate a test to try.

Finally, people do forget their password once in a while, there should be an option to say "send me a temporary password" via email to login to the system.

Oh - did I mention that the password should be obscured as you enter it so your neighbour can't just watch you enter it?

Heuristics

Actually not that many - there's just a few on-screen variables here.  You should probably try that the maximum length of username entered matches the maximum length from the registration page.  And likewise for the password field.

You should want to try a variety of character types used for password and username to check nothing's getting stripped or objected to.

Test 1: Happy Day or "I can login"

The following combinations will allow a user to login to their system,

• Enter their username exactly as entered into the registration page and with correct password
• Enter their username, but with different capitalisation and with correct password
• Enter their phone number starting 0064 for phone number area code and with correct password
• Enter their phone number starting +64 for phone number area code and with correct password
• Enter their email address exactly as entered into the registration page and with correct password
• Enter their email address, but with different capitalisation and with correct password

Should probably mention something about "password is always obscured", but you surely have that by now?  If that requirement shocks you, you need to try out using more web systems for familiarity!

Test 2: I can't login

If the username/phone number/email address is entered with the following, the user is not let into the system (with a suitable error message given),

• Incorrect password
• Correct password for another account
• A password which has since been changed (old password)
• The correct password but using different capitalisation
• The correct password but using the first x characters of an x+1 character length password
• The correct password but using x+1 characters for an x character length password (add a space at the end/start)
• A temporary password that has been used once.
• A temporary password, when another temporary password has been subsequently ordered.

If I give a username/phone number/email address for which there is no account, it makes sense the error message is suitably generic.  Otherwise likewise, scammers/phishers can go "this email has an account, but this one doesn't".


Test 3: Locked out

Lets say the lock out number is 5.

The basics

• I login with the wrong details for an account 5 times.  I login with the correct details, but I'm not let in. [It takes 5 consecutive failed logins to lock]
• I login with the wrong details using a combination of username/email/phone number 5 times but incorrect password each time.  I login with the correct details, but I'm not let in. [5 consecutive failed logins against the account not the handle you're using]
• I login with the wrong details for an account 5 times.  I login with the correct details once and am let in.  I login with the wrong details for an account 3 times.  I login with the correct details once and am let in.  [It takes 5 consecutive failed logins, not 4 .... and they must be consecutive]

Trying out the unlock feature

• I login with the wrong details 5 times. The account is unlocked.  I can login. [I can unlock my account]
• I login with the wrong details 5 times. The account is unlocked.  I login with the wrong details for an account once.  I login with the correct details once and am let in   [Once locked once, it doesn't trigger for every failed login since]
• I login with the wrong details 5 times. The account is unlocked.  I login with the wrong details for an account 5 times.  I login with the correct details, but I'm not let in.  [Locking the account isn't a one shot deal]

Test 4: Forgotten password

Lets order a new one!  Click the button, to get the above page.

• You should get a new password via email if you enter, the email / phone number / username there.  And by "you should" I mean you are going to test all those options ... not just one of them!  
• An unused email / phone number / username version of any of them should be rejected
• Email and username should probably be case insensitive (miketalks being treated the same as mIketALKs)

If you've ordered a temporary password,

• If you use it to log in you are successfully logged in but made to change your password immediately
• You probably should still be able to use your old one, and if you login with the old (good) password, it should make the temporary password unusable (try it)
• You should be able to copy and paste the temporary password from the email into the screen
• There should probably be a time limit on how long the temporary password can be used for.  And guess who's going to test it?
• If you order a temporary password twice, the first one should be made unusable.  And hint - the temporary password should be unguessable, not "newPassword01".
• You can't use a temporary password to login twice

Test 5:Logout

When you are inside the system, you are logged out,

• After a set period of inactivity.  Stopwatch ready, because guess what you're doing.
• If you close the tab/window, and then reopen it, you're taken to the login window to find you're logged out.
• If you select the "logout" button.

You cannot use the back button to get back into the system once logged out.  Neither can you just type in the address bar for your account and bypass the login page.

Two tier variant

Some systems have what's called a "2-tier login" system, where you use a password, then a token is sent to your mobile device (or from a token system), which you have to use.  This like a temporary password has one use, a new one can be requested (invalidating the old one), and has a limited time for which it can be used.  All variables which can be tested.

The principle is it's safer to login using a password (which could be broken) together with an item you're known to have on you (token or mobile).  If your system has an SMS stub, you're in luck, and you can use a variety of mobile numbers, but still read the token details from the raw SMS stream.

If not, then it means sadly you only ever have one phone number you can use - your own.  Suddenly that suite of phones for testing seems a good idea.

Observation

There's a heck of a lot to test there.  I've hung at work for an hour and a half whilst the trains are out writing this (we have some extreme weather in Wellington right now).  Even so it's been a lot of typing, and my fingers are somewhat sore.  To script it up in full would be at least 3 days, and for not much more benefit.

Now your turn

Have a play with your account, and again try this out on Facebook, Hotmail etc.  Get a real feel for the behaviour, and as always comment below if you think there's anything you've noticed or would like to add!