Last month I set the context and the objectives for this series – how do you teach someone new to testing how to test?  In that article I talked more about the framework which needed to be in place to support a new testers, but this series will include far more a look at the key ideas of testing for someone new to the area.

The Testing Mindset

Typically when a developer writes an application, they will run a couple of checks on the software, it looks okay.  QED: “it works”.  If they’re writing for instance a registration page, they’ll enter their name and details (it’s the details which come to mind easiest for anyone), it processes their details, and they summarize that …

It-works-for-me

For testers, this is a good start, but just because it works for someone, doesn’t mean it’ll work for anyone.

The heart of being a tester is being able to ask “what if” questions – and for that scenario, testers would currently ask a barrage of questions,

  • What if my name contains more than letters – for instance if the name is double barrelled or has an apostrophe?
  • What if my name is really long?
  • What if I’m really old or really young?
  • What if my birthday is 29th February?
  • What characters should not be allowed in my email address?
  • What if I use a weak password?
  • What if I leave a key field blank?

The answers to these questions form a series of tests or experiments that the tester chooses to run on the system, to find out places where the system behaves in a way which doesn’t make sense.

Defining testing

We’ll use the following definition for testing to guide us in this series – there are a lot of definitions out there, and I encourage you to read them all, and expose them to your scrutiny.  But for now,

Testing is about applying variety to a system in order to find problems in code.

Part of the core skills of a tester though is knowing “which variety” to apply.  Testers who have been around a while, tend to guide what they choose to test from problems either they or their peers have experienced.

Obviously this makes things tough for a new tester, as without that experience to guide them, where do you start?  A good first point is to have some exposure to heuristics – which are essentially rules of thumb which people have collected from testers’ experiences of “things which often go wrong”.

The rules of this series

There are three fundamental aspects which are the core of most online systems today,

  • registration
  • log in
  • account self-management

Doesn’t matter if you’re Amazon, Facebook, Twitter or Hotmail, these elements are going to be within your system somewhere.  So we’re going to go through and explore each one, with a list of how I’d approach testing any such system.

For this series, I’m going to use as the core system under test Twitter, so if you’ve never used Twitter, now’s a good time to get a handle.  Now obviously some screens will change once this is published, but it’s likely the core basics will stay the same (so roll with it).

Oracles

As I don’t work for Twitter, so I have no idea of what requirements they have for their processes.  Thankfully though requirements aren’t the only way to guess how a system should operate.  There is a testing superpower I call “common sense” (which to be fair, is fairly uncommon) or James Bach calls oracles which is useful here.

For my team, we define an oracle as a “guide for understanding how the system’s supposed to behave”.  Whilst it’s true a requirement is an oracle, they’re not the only ones.

An oracle thus is something that also helps you to determine if a test has passed or fail.  A standard kind of oracle is “if I do everything a page asks of me, and when I submit, it says I’m missing data/done something wrong”.

sign-in-to-twitter

Let’s think about an item we’ll look at in the future regarding “logging in”.  You enter your username and an incorrect password.  I have no requirements here – but what do you think will happen next?  [No, I’m not going to say until a future installment – but really hope you’ve guessed]  And how do you know you’re right?

In part because you’ve used other systems with these core elements in, and expect the behaviour from one to be pretty close to the behaviour from another.  And partly because it makes a kind of sense.  If you can log into an account with any old password (oops – spoilers?) – Then really, what’s the point of your login screen?

Heuristics

Together with some oracles to guide us, I’m going to use heuristics to generate test ideas.  Heuristics are rules of thumb used to test an element of a system.  Typically for instance when you see a name field, you’ll be generating test ideas such as,

  • What if I leave it blank?
  • What if my name is REALLY long?
  • What if I’ve got apostrophes and double-barrelled elements to my name?
  • What if my cat runs along the keyboard and it’s a jumble like 89dee8(#EH#(*E?  [If you look at the pattern those letters make across the keyboard, then it’s likely the cat was really breakdancing]

All these test ideas are called heuristics, they are rules of thumb where you know systems can get into difficulty.  So they’re a good idea to test.

Occasionally I meet a worried customer who’ll desperately ask me “your testing will include some negative testing, won’t it?”  It’s the sign of a customer who has had someone work for them going “I log in with my name and password … the login page is now tested”, it means that the tester is likely to have not used enough heuristics to generate test ideas.

And let’s be frank, sometimes you don’t have enough time to apply every test heuristic, but you should try out as many as you have time for, often starting with the ones you know are likely to cause the most trouble!

During this series I’ll be using Elisabeth Hendrickson’s excellent heuristic cheat sheet as the source for a few ideas … if you’ve never come across this page before, (a) print it and (b) laminate it.  It’s that useful!

Final thoughts

We’ll move beyond this to the application of these oracles and heuristics to a registration page next month.  Take the time to look through that heuristic cheat sheet to familiarise yourself with it, and think about how you’d apply some of those rules.

If you have any questions or thoughts, please contact me through Testing Circus, and I’ll include a reply next month.

https://i0.wp.com/www.testingcircus.com/wp-content/uploads/It-works-for-me.png?fit=602%2C417&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/It-works-for-me.png?resize=150%2C150&ssl=1Mike TalksArticlesHow to Test,Testing ArticleLast month I set the context and the objectives for this series – how do you teach someone new to testing how to test?  In that article I talked more about the framework which needed to be in place to support a new testers, but this series will include...