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:
- 9 Situations to Test the Strength of Your Mobile App
- Learning from Fairy Tales
- Bugs Don’t Take Vacations
- Adding Software Tools to My Toolbelt
- Travel Bugs
- Testing Error Conditions
- Using Tea/Coffee Breaks in your Mobile Testing
- Alternating Phone Models Per Test Cycle
- Peripherals? I’d Forgotten about Those…
- A Tester’s Consistency Checklist
- “Alarming” Problems You Should be Preventing
- Quick Tests for Your Web App
- Testing for App Consistency
- Is it a Good Story?
- Quick Attacks on CRUD Apps
- Lights, Camera, Action, Bugs!
- Follow the Data