Users change their minds. They save new items in your app, then want to delete those saved items and try again. Does your AUT support this behavior? Did you test for it?
My devs recently added a dropdown control with two values (i.e., DVS or ESP). Soon after being able to save or change the values, I stopped testing. Later, a user pointed out there is no way to remove the values from that (optional) field if you change your mind. Now, many of our dropdowns look like this:
While testing, I often look for data saving triggers (e.g., a button that says “Save”). Then I ask myself, "Okay, I saved it by mistake, now what?".
Devs and BAs are good at designing the positive paths through your AUTs. But they often overlook the paths needed to support users who change their minds or make mistakes. Your AUT should allow users to correct their mistakes. If not, your team will get stuck writing DB scripts to correct production data for scenarios users could not fix on their own. It’s your job to show your team where these weaknesses are.
7 comments:
Subscribe to:
Post Comments (Atom)
RSS
I completely agree. This is indeed a role for testers, and it's something that should be brought up when the feature is first devised, not after the feature finds its way into production code.
Standard CRUD!
Good point, Alex. Testers should be asking the what-if-user-makes-mistake questions in the requirement walkthroughs. It's possible someone may even listen. Or you may get the usual answer..."Too bad!".
CRUD? Create, Read, Undo, Delete?
Thats why...i suggested my Dev's that use "Select from List" for all drop-downs( Mandatory and Optional).
Problem simply solved.......
Is it right eric??
Yep. Nice post.
This is something I test for every time I see anything like this. There's a common assumption also that the customer knows what they are doing. The happy path often does work. The unhappy/forgotten/got something wrong path often doesn't.
Rob..
CRUD:
Create
Read
Update
Delete
Stuff a basic web app does. If you've ever played with Rails, this is the functionality it automatically creates.
Update, but yeah, it's a pretty standard way of looking at data in applications. If you don't want to include one of those operations, then you better have a good reason that everyone agrees with.
Undo is a special case and generally avoided, I think, because of complexities (how many levels? some operations and not others? when are changes committed? etc.).
And "Too bad!" cuts both ways as you're realizing! It's fine if ideas and warnings about user interaction are overruled, but if those ideas and warnings constantly come back to haunt, then something needs to change to incorporate future warnings and ideas.
Kish252,
There are so many flavors of dropdown menus it's hard to understand your statement.
Selecting a value from a dropdown may be optional, allowing the user to type items not in the dropdown. In that case, they may be able to delete their values without having to select a value like "empty".