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…





Comments (7)

  1. Ferris Beuller says:

    When automating a UI always add a random control selector or click every control in reverse order 😀

  2. Alex says:

    It doesn’t not look like testing for me. It looks like usability questions. Is it?

  3. jledgard says:

    It is usability questions. But one of the key jobs of testers, at least at Microsoft, is to be the voice of the customer. Also, I’ve found that poorly designed UI also tends to be hard to test properly and leads to poorly designed testing in some strange vicious cycle.

  4. jledgard says:

    Also, the testing I mentioned here is the type of testing that should be done before there is any code written or you are in the prototype stage.

  5. Alex says:

    Can I ask you a question?

    What kind of software you are using for testing?

    If you are using different tools to test Win and Web applications, can you mention them all?

  6. josh ledgard says:

    We write a lot of custom software for testing to be honest. It’s part of our dogfooding efforts. I’ve mentioned other tools we use. I’ll also soon start having testing tools show up on the powertoys blog!

  7. passionatedetachment says:

    It seems to me that the programming community needs to shift gears and move into a "portable – GUI" environment, such as found at gogui.com. I have used this portable desktop to bring presentations, favorites and webpages on the road with me. It will be nice to do this with applications as well.