Back to basics 2: Registration

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

Registration is the first time that a user encounters your system - make it too difficult or painful, and they won't get past this.  Most people - and especially developers - when faced with "testing" this page will just enter their own personal details, hit "create" and if it works, then job done.

However there's certain things you'd want to try out beyond that.  Having a system that allows you to login is okay - as long as you're going to be the only person who uses the system (unlikely).  As a tester your mission is to try out a representative sample of scenarios which will cover all the other potential genuine and malicious users.

Okay - this is Twitters current registration page ...

Oracles

As discussed we don't have any requirements from Twitter, but having done this on other systems, we have a good indication of expected behaviour, and this forms our oracle.  Let's write out some of the basics,

• The system should set up a brand new account when done (but we won't test this fully until part 3) and an email sent to user
• If the system doesn't like what I'm doing, it should at least fail gracefully with an error message that gives me meaningful information
• My email/username should not have been used by anyone else before.
• The terms and conditions should be clearly readable
• All fields are mandatory - if not entered, no account will be created
• Email field must be valid according to rules from here (that page forms an oracle)
• Password will need to be of a set complexity (but exact rules unknown)
• The text you enter into the password field should be obscured to prevent someone from leaning over your shoulder and seeing it

Not at use here, but what I'd expect on this kind of page,

• I need to confirm I'm above a certain age (usually by entering your birthday)
• I need to agree to terms and conditions before creating my account (here they have put that "by selecting 'create my account' you are agreeing to our terms and conditions)

Picking out heuristics

From the cheat sheet, areas which seem to be in play here,

• strings - most of the fields are strings to enter, so most of the areas there apply to each field
• date and time - would apply if we had a date of birth field (we're going to pretend there is)
• boundaries - would apply for date of birth if we had a minimum age (again, going to pretend there is)
• input method - makes sense to ensure we can copy and paste to fields

What we're going to do now is to combine these to generate test ideas.  Don't be afraid to try them out with me.  Here goes ...

Test 1: Looking holistically ...

We're going to look initially at the system holistically, and then break down to be put each element under duress.

Let's start off with a few really basic tests ...

• Enter your details, including all the fields, confirm that account created (might need to check the database for this) and potentially an email is generated when account created.  According to the CRUD heuristic, you might also like to once created to retrieve the account in some way.  We'll cover some of this in part 3, but you might check in the back end to make sure the data entered is really that the system stores (not just for this test, but for other variants where an account is created).
• Enter absolutely no data, and try and create.  Expect an error message to be created.  [It actually 'wags' the 'create my account' box at you to show an error, but close enough]
• Create all the registration information, bar one field which is kept blank. Try to create.  It should warn you.

Test 2: Name field

Okay so it can work for some people from those tests.  Lets try out some other options.  We're going to exercise the name field under duress now.

The most obvious things to apply here from the cheat sheet are strings and input methods. So ...

• We've tried it being blank already.  But let's make it really long, and see what happens.  There are some tools out there to make really long strings.  But I like going "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMONPQRSTUVWZYZabcd...".  Typically eventually the field just stops, and I remember what letter it stopped at.  I then create the account, and retrieve the name (either from the account or by looking in SQL) and check it stops at the same letter, ie the name hasn't been unnecessarily truncated
• The field "the quick brown fox jumps over the lazy dog" is helpful as it includes all the letters of the alphabet - if you use this and it's returned in full, then there's no crazy truncation of letters or after spaces.  It's useful to also include in UPPER CASE.
• Not all names are alpha characters.  Some people have an apostrophe or insist on having a double barrelled name.  And yet their names are valid names.  How does your system handle that?
• Some people will insist on being French or German.  Yes there is a world of accented characters out there - àáâãäåçèéêëìíîðñòôõöö - how does your system cope?
• Can you copy and paste your name into the field?
• How does it handle characters you don't ordinarily associate with names?  Things like numbers or special characters like '123...' or '!@#*$(%*'.  Eliminating these characters from entry into your system helps security - particularly the * is used in Unix and SQL can can cause all kinds of mischief.
• If my name is entered and including spaces, make sure that "Mike Talks" is retrieved as "Mike Talks" and not truncated on the space down to "Mike".
• What happens if I start my name with a SPACE or use multiple spaces?

Test 3: Email field

As with the name field, you can try really long fields, copy and pasting etc.  But there are also special rules for email fields.

A lazy (but useful) basic test would be to try the valid email addresses found here and the invalid email addresses found here.  Or at least try your own variants.

As mentioned in the oracles, if you include an email address previously used, you'd expect some kind of warning.

Also would expect some "case insensitivity" in the checking of email.  If I've used an email "testsheepnz@tester.co.nz", I don't expect to be allowed to use "testsheepNZ@tester.co.nz".

Test 4: Password field

As said, blank should be unacceptable.  Typically as mentioned in oracles, passwords have to be longer than 6 characters, and include not just lower case alpha, but some upper case of numberic/special characters are mandated.

Tests for passwords which are too short or too long should be considered, or those which break the rules.  Also include copy and pasting passwords in.

Test 5: Username

Again too long/too short variants again need to be used.  If you try to go too long it should warn you, and you should try out using numbers and special characters to see whats allowed and what's discouraged.

As with email address, if you try to use an account already used it should warn you.  And likewise employ a case insensitive check to prevent you from creating "testsheepnz" when there is already a "TestSheepNZ".

Test 6: Date of birth (bonus feature)

Okay, Twitter doesn't have date of birth, but a lot of places do.

To throw some very basic spanners in the works, you should try and enter,

• A completely garbage date, confirm the system warns you it's not a valid date
• Include a date in the future for date of birth
• Try the 29th February for some valid/invalid leap year options
• Try some dates that don't exist such at the 30th February or the 32nd September
• Try first/last valid dates in the months
• Try entering dates in different date format - ie 12/01/94 or 12 01 1994 etc, to see how the system copes
• If the system asks you to select a date from a GUI, try different options, including selecting days that aren't there.

Typically most systems have business rules that "you need to be 13 or more to sign up for an account".  This is a great time to try some boundaries,

• Try someone who is minimum age to the day
• Try someone who is minimum age minus one day
• Try someone who is minimum age plus one day
• Try someone who is over 100 years old.  Pre year-2000, many computer systems stored date of birth year as a 2-digit field.  So people over 100 sometimes cause a bit of a fit in legacy systems.

Test 7: Terms and conditions

Yeah, most people just go "yadda, yadda, yadda" for the terms and conditions.  Typically you should not be able to create an accoutn unless you select you're accepting the terms and conditions.  But also they need to be displayed well.

On Twitter it doesn't seem to be very well displayed, until you click in the box, and it expands like so ...

Nice!

Wrapping up ...

As you can see just from this very basic pass, we have created a whole ream of test ideas for a very basic operation.

You can see how a lot of testers (especially context driven ones) will look at these ideas and prefer to either have a check list of them or mind map.  It's going to take a lot of time to write those all up as formal scripts, but you probably have a good idea how to execute them right now (which makes one wonder 'so what benefit exactly do I get from scripting?').

In fact, have a go at trying a few tests on the Twitter registration right now.  Then take a look at the registration pages for Facebook, Hotmail, Instagram - pretty much anything you can find (that doesn't involve a legal obligation).  Drop in the comments below any oddities you found, or indeed any different oracles or heuristics you used when you did ....

Happy testing!