Having tested a lot of programs that create, read, and update data, I now have a quick attack toolkit that I can use to test out these apps. As I do these, I’m also learning a lot about the app and generating other test ideas, but these basic quick attacks often come up with a bug or two.
1. Parse out Whitespace at Start and End
If users are entering data, it’s likely they won’t deliberately enter a space at the start or the end of the data they are entering. However, they might be copying and pasting, and if they do so, the likelihood that there is whitespace at the start or end increases.
Why does this matter? Two reasons:
- If you’re doing a comparison to check an entry already exists, the comparison might be thrown off by the presence of a space.
- Sort order: if the leading space is not stripped, the entry will often display as the first entry in an ordered list, which can look strange as the space will not be obvious and the user will wonder why entry “zebra” is showing before “aardvark.”
2. Try Duplicates
Try to create a duplicate entry and see what happens. Does the system allow it? If it does, is this a problem? If it doesn’t allow duplicates, see entry #1 of this post and put spaces before and after to see if this gets through. Try changing the case to see if a duplicate is allowed with a different case.
3. Double Click
If there is a Create button, don’t simply click it. Give it a multiple click and see if several copies of the same item are created. If the UI does not allow duplicates, you might find that a double-click will send 2 copies of the same data, and you’ve found a way to bypass the duplication check.
4. Check Update Usability
Users aren’t perfect, and when creating an item they might misspell it or select the wrong item. This is when you get to test out the ‘U’ of a CRUD app—can the user easily correct their mistake?
You can also use the update function to test out the Duplication check again. The system might not allow you to create a duplicate entry, but is this check consistent and does it stop the user from changing an existing item to be a duplicate of another one?
5. Try Goldilocks Data
Remember the story of Goldilocks and the 3 Bears? Beds and porridge were too soft, too cold, too hard, too hot. Use data that is too small and too large and not just data that is just right.
6. Try Special Characters
Use character such as % and &, enter HTML commands and foreign characters, and see how they affect the system. And remember the update option—if characters are filtered when first input, are the rules used consistently on edit?
A quick overview of the app doing these will also quickly help you build up a map and understanding of the app and help you begin building up more complex scenarios and test ideas.
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