← Back to Blog Home

More Ways to Test – Learning from Fairy Tales

Exploratory Testing
by: Phil Kirkham

Article summary

When coming up with data to test out your app, you might get stuck deciding what to enter. We’ve all used our own name and data or the classic “asdf asdf 123.” One way to get creative with your testing is to turn to fairy tales. And there’s a concept we can clearly learn from Goldilocks and the Three Bears — too little, too much, and just right.

Just Right

I usually start with the Happy Path data set, giving the app the inputs it is expecting. It should work fine as all the automated tests have passed, right? But a quick pass-through can show you the type of data involved and suggest some ideas to use later on. And maybe it’ll reveal a glitch if you’re using Safari while the devs have been using Chrome and Firefox.

Too Little

Start off by leaving all fields blank and then move on to using just one character. (This catches off-by-one errors.) For fields where an empty option is not valid, see if it can be fooled by entering a space. Try adding leading and trailing spaces onto fields, too. I’ve caught more than one error simply by adding spaces to the start or end of inputs. If part of the input is uploading a file, try it again with an empty file.

If all of the validation for “too little” is good when entering data to create an entity, try testing what happens when the entity is edited. Does the same validation apply consistently, or does it behave differently when editing rather than creating?

Too Much

Now overload all of the fields, and check that validation catches it all. You can go crazy and try pasting War and Peace into an input field if you so desire. If you can upload files, try uploading large or invalid files.

Similar to “too little,” once the validation has been checked, move on to something else. Try to see what happens when you’re editing. Does the same validation happen?

Once you check this, you can see if you have any Ugly Duckling data. You know — the ugly duckling that turns into a swan? See if any of the data in your application stays an ugly duckling (i.e., it’s never used, even though the user is forced to enter it).

Have fun using this approach to help perfect your projects.

Looking for more ways to test? Read some of the other posts in this series:

 
Phil Kirkham
Phil Kirkham Quality Analyst at Atomic Object, helping teams by finding issues before the customer does. Ex-pat from England finding a common culture in creating high-quality software. Taker of chipmunk pictures.
All Posts →

Related Posts