Software Testing: The GUI Part 1

I've been asked to talk a bit about UI testing. Keep in mind that none of my testing posts are meant to be a complete comprehensive guide on the subject at hand. My goal is simply that everyone reading walks away with a useful idea.

You want to test your GUI early because it could take weeks of dev time to actually build something that you’ll just scrap and start over with. There are a few pieces of UI in Whidbey that have been re-built several times at the expense of more bug fixing and potentially useful features. Please create mock ups and put them in front of as many people as you can. Photoshop them, create prototypes, slides, etc so that you can walk through your ideal user experience. When doing so, you should be asking at least the following questions:

  1. Is it obvious to the user who has never seen this before what has to be done to complete the intended task?

This question was either never asked or answered properly when we were designing the tool window docking in VS.NET 2002 or 2003. If you drag a tool window from its docked position there is no real indication that there are 5 ways to dock it to each of the other windows you might have open. We’ve made this much more obvious in Whidbey. :-)

  1. Does the UI make sense for the task?

Are you using a textbox when you are asking the user for a date? Do you have a dropdown where there will ever be only two intended true/false type options? Are you cluttering the UI with helper text that would be more appropriate in a help topic?

  1. Does the UI appropriately restrict the user input?

Lets pretend there is an autosave feature in your product and you want the user to set the interval time between autosaves. You should think about restricting the interval input to numbers that would make sense. If it could take up to 2 minutes per save you might not want to allow the user to get into a state where they are stuck in an autosave loop. The max should also be a reasonable number that doesn’t defeat the intent of the feature. No point in letting people pick an interval as large as 9999 minutes since that would be only once per week. Negative numbers, symbols, or characters might also not be advisable to allow.

Properly restricting the inputs in the UI will also help to ensure data consistency on your back end and help prevent crashes due to buffer overruns or other issues that could be hidden below the surface due to how the input is manipulated. Plus, the more restrictions you put on user input the more you can reduce the testing required to test the feature.

  1. What will happen if I do X?

For this question it’s best to sit the UI in front of people who have not seen it yet. You should ask them to guess what will happen if they click the button that says “Start”. If the UI is intuitive they should be able to get pretty close. You should ask them what limits they would expect, what paths should be defaulted to, and if the default values make sense, etc in order to help determine how effective the design gets the intent across.

As discussed this list is not comprehensive, but should get you started as you attempt to determine if you are actually close to what your final UI should look like. Again, the more dogfooders of these prototypes you have the better.

Speaking of dogfood… my wife and I picked Spot, the smart one. His new name is Duncan and you can check out his dogster profile. :-)

Enjoy...