15 Useful Test Cases for ensuring Consistent User Interfaces

When testing user interfaces, it is easy to overlook test cases that ensure that your user interface is user-friendly and consistent. This newsletter identifies 20 test cases that might be considered when testing user interfaces for consistency.

15 Useful Test Cases for ensuring Consistent User Interfaces

1. Screen Font Type - Ensure that the screen font family matches from screen to screen. Mismatching fonts within the same sentence and overuse of different fonts can detract from the professionalism of your software user interface.
2. Screen Font Sizes - Ensure that the screen font sizes match from screen to screen. A good user interface will have an accompanying style guide that explicitly defines the font type and size for headers, body text, footers, etc.
3. Colors - Ensure that screens do not use different color sets as to cause an inconsistent and poorly thought-out user interface design. Your style guide should define header colors, body background colors, footer colors, etc.
4. Icons - Ensure that icons are consistent throughout your application by using a common icon set. For example, a BACK link that contains an icon next to it should not have a different icon on one screen versus another. Avoid free clip-art icons, opt for professionally designed icons that complement the overall look and feel of your screen design.
5. Narrative Text - Having narrative text (screen instructions) is a great way to communicate how to use a specific screen. Ensure that narrative text appears at the same location on the screen on all screens.
6. Brevity - Ensure that narrative text, error messages and other instructions are presented in laymen's terms but are brief and to-the-point.
7. Dialog Box Consistency - Use a style guide to document what choices are available for dialog boxes. You should have not have Save/Cancel dialog on one screen and an OK/Cancel on another, this is inconsistent.
8. Links - If your application has links on the screen (e.g. Save as Spreadsheet, Export, Print, Email, etc.), ensure that the links have consistent spacing between them and other links, that the links appear in the same order from screen to screen, and that the color of the links are consistent.
9. Menus - If your application has menu items, ensure that menu items that are not applicable for the specific screen are disabled and the order in which each menu item appears is consistent from screen to screen.
10. Buttons - If your application has buttons (e.g. Submit, OK, Cancel, etc), ensure that the buttons appear in a consistent order from screen to screen (e.g. Submit then Cancel).
11. Abbreviation Inconsistencies - If your screens contain abbreviations (e.g. Nbr for number, Amt for amount, etc), the abbreviations should be consistent for all screens in your application. Again, the style guide is key for ensuring this.
12. Delete Confirmations - It is a good practice to ask the user to confirm before deleting an item. Create test cases to ensure that all delete operations require the confirmation. Taking this a step further, it would also be great to allow clients to turn off specific confirmations if they decide to do this.
13. Save Confirmations - It is good practice to ask the user to confirm an update if updates are made and they navigate to another item before explicitly saving. Create test cases to ensure that all record movement operations require the confirmation when updates are made. Taking this a step further, it would also be great to allow clients to turn off specific confirmations if they decide to do this.
14. Grammar and Spelling - Ensure that you have test cases that look for grammar or spelling errors.
15. Shortcuts - If your application allows short cut keys (like CTRL+S to save), ensure that all screens allow using of the consistent shortcuts.

By the way, did you notice any inconsistency above? We intentionally showed 15 useful test cases above but the narrative before the listing shows 20 test cases. Inconsistencies are easy to spot, right?

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

• Software Planner - http://www.SoftwarePlanner.com
• TestComplete (Automated Testing Tool) - http://www.TestComplete.com
• STAR QA (Automated Testing Resources) - http://www.star-qa.com
• Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
• Test Case Training - http://www.PragmaticSW.com/Services.asp Pragmatic
• Agile Development - http://www.pragmaticsw.com/PADOverview.pdf

20 Useful Test Cases for testing User Interfaces

When testing user interfaces, it is easy to overlook test cases that would be helpful for a more thoroughly tested solution. This newsletter identifies 20 test cases that might be considered when testing user interfaces.

20 Useful Test Cases for testing User Interfaces

1. Required Fields - If the screen requires data entry on a specific field, it is good practice to identify the required fields with a red asterisk and to give a friendly warning if the data is left blank.
2. Data Type Errors - If the screen contains dates, numeric, currency or other specific data types, ensure that only valid data can be entered.
3. Field Widths - If the screen contains text boxes that allow data entry, ensure that the width of data entered does not exceed the width of the table field (e.g. a title that allows 100 characters in the database should not allow more than 100 characters to be entered from the user interface).
4. Onscreen Instructions - Any screen that is not self-explanatory to the casual user should contain onscreen instructions that aid the user.
5. Keep Onscreen Instructions Brief - While onscreen instructions are great, keep the wording informative, in layman's terms, but concise.
6. Progress Bars - If the screen takes more than 5 seconds to render results, it should contain a progress bar so that the user understands the processing is continuing.
7. Same Document Opened Multiple Times - If your application opens the same document multiple times, it should append a unique number to the open document to keep one document from overwriting another. For example, if your application opens a document named Minutes.txt, if it opens the same document for the same user again, consider having it append the time to the document or sequentially number it (Minutes2.txt or Minutes_032321.txt).
8. Cosmetic Inconsistencies - The screen look, feel and design should match the other screens in your application. Creating and using a style guide is a great way to ensure consistency throughout your application.
9. Abbreviation Inconsistencies - If your screens contain abbreviations (e.g. Nbr for number, Amt for amount, etc), the abbreviations should be consistent for all screens in your application. Again, the style guide is key for ensuring this.
10. Save Confirmations - If your screen allows changing of data without saving, it should prompt you to save if you move to another record or screen.
11. Delete Confirmations - If a person deletes an item, it is a good idea to confirm the delete. However, if your user interface allows deleting several records in a row, in some cases you might consider allowing them to ignore the confirmation as it might get frustrating to click the confirmation over and over again.
12. Type ahead - If your user interface uses combo boxes (drop down lists), be sure to include type ahead (if you have hundreds of items in a list, if you type in the first letter it will skip to the first item that begins with that letter).
13. Grammar and Spelling - Ensure that you have test cases that look for grammar or spelling errors.
14. Table Scrolling - If your application lists information in table format, if the data in the table extends past one page, the scrolling should scroll the data but leave the table headers in tact.
15. Error Logging - If fatal errors occur as users use your application, ensure that your applications writes those errors to a log file, event viewer or a database table for later review. Log the routine the error was in, the person logged on, and the date/time of the error.
16. Error Messages - Ensure that error messages are informative, grammatically correct, and not condescending.
17. Shortcuts - If your application allows short cut keys (like CTRL+S to save), test each shortcut to ensure it works in all different browsers (if the application is web based).
18. Invalid Choices - Do not include instructions for choices not available at the time. For example, if a screen cannot be printed due to the state of the data, the screen should not have a Print button.
19. Invalid Menu Items - Do not show menu items that are not available for the context you are currently in.
20. Dialog Box Consistency - Use a style guide to document what choices are available for dialog boxes. You should have not have Save/Cancel dialog on one screen and an OK/Cancel on another, this is inconsistent.

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

• Software Planner -

http://www.SoftwarePlanner.com

TestComplete (Automated Testing Tool) - http://www.TestComplete.comSoftware Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

Test Case Training - http://www.PragmaticSW.com/Services.asp

Pragmatic Agile Development - http://www.pragmaticsw.com/PADOverview.pdf

Benefits of Keyword Driven Testing for Test Automation

Most software companies have considered automated testing and many have fully automated their regression test cases in an effort to reduce manual effort needed to test new builds of their software. Many companies that have been successful with automation attribute it to keyword driven testing techniques that reduce the time spent creating test cases.

This newsletter addresses why companies consider automation and best practices for ensuring that time spent automating test cases provide a return on investment.

Why Automate Your Test Cases?
Many companies run their regression test cases manually, so when does it make sense to begin automating your regression test cases? It makes sense to automate your test cases when you can no longer run the regression test cases on each build created. For example, if you are doing daily or weekly builds of your code to quality assurance and you cannot quickly run your regression test cases with each build, it is time to consider automating them. Automating your test cases provide these benefits:

• Quicker Releases – By having your regression test cases run automatically, your software quality team can concentrate on testing new features of your software and less time regressing existing features.
• Higher quality releases – Your software releases will have fewer bugs and require less customer support because they will be of higher quality.
• Happier Customers – Your customers will be happier and more willing to serve as testimonials for future prospects.

Why Does Automation Fail?
Many companies are thinking about test case automation or have experimented with it in the past. Some companies that experimented with it eventually abandoned it because of these reasons:

• Poor Understanding of Test Automation – Many companies see automation as a silver bullet that will allow them to quickly automate every test scenario quickly and allow them to abandon manual testing and reduce staff. In reality, automated testing is designed to quicken the running of regression test cases but it is not a substitute for manual testing. A quality-oriented software team will see the value of utilizing both automated and manual test cases to ensure great test coverage and higher quality releases.
• Improper Tester Education – Automation requires a tester to learn the testing tool. Companies that purchase the tool but not any training will eventually abandon the tool because the testers are not equipped to use the tool.
• Lure of Record / Playback – Many companies think that they can quickly get up and running with automation by simply recording their screen actions and playing them back. While record and playback will create scripts that they can use as a starting point for your automation, it does take time to update the scripts to be more re-usable and it takes scripting language knowledge to do this.

What is Keyword Driven Testing?
Most automated tools require the test engineer to understand a scripting language (VB Script, Java Script, etc.) to write their automated test cases. Most tools have the ability to create the scripts using record and playback, but this does not always write the most efficient scripting code and is not as re-usable and maintainable.

Since many testers do not have deep scripting skills, it is imperative that your automated testing tool has a way to create Keyword Driven Tests. Keyword Driven Testing is a way to define automated test cases without the need for scripting skills. It allows a tester (or even a subject matter expert) to create automated tests by describing each step of the automation.

For example, if you are automating the login process of your application, your user will access your application, type in their user-id and password and press a button to login. Traditionally, testers would do this by writing VB Script that will navigate to your application, identify each object on the screen (user-id, password and login button), then write script to enter in the user-id, password and to press the login button.

With keyword driven testing, the tester does not need to understand the scripting language to make this happen, they can simply describe the event (navigate to your application, enter in "abc" for the user-id, enter in "xxx" for the password, press the Login button when done). As you can imagine, this is a much simpler approach to automated testing than scripting.

How have Successful Companies Implemented Automation?
Successful companies understand the enormous benefits of automated testing and have implemented strategies to ensure that they receive the maximum return on investment with their test efforts. Below are the secrets to becoming successful with test automation:

• Start Smart – Automation efforts are similar to software development efforts -- it takes upfront thought and a good test design architecture to ensure that your automated test cases will be re-usable and easy to maintain. Before jumping into automation, ensure that your automated tool has the ability to maximize your efforts with keyword driven testing -- as this will ensure that you can easily re-use your automated test cases.
• Start Small – Start your automation efforts on an established project that already has a good set of manual regression test cases written. Take those manual regression test cases and develop your automated test cases that will replace them. Once this is done, you will find that you can automatically run those automated test cases each day of builds and with minimal efforts, freeing your team up to do more manual exploratory test cases. Once you have this established for a single project, move on to other projects and expand your effort.
• Blend Automated and Manual Tests – Not all test cases should be automated. Some test cases require a human eye to ensure that screen cosmetics are appropriate, that data is reasonable, etc. Spend time automating test cases that do not require this type of human contact and continue to use manual test cases when appropriate. A good application lifecycle tool should allow you to track both automated and manual test cases.
• Keep track of Metrics – Keep track of how many automated and manual test cases are run for each build, how many pass, how many fail, etc. Track how many additional automated test cases your team can write with each release so that you can determine average time needed to develop automated test cases in the future. Track how many defects are found post-production to determine if your automation efforts are paying dividends. A good application lifecycle tool should allow you to track metrics for both automated and manual test cases.
• Build on your Successes – Once you have successfully implemented automated testing on a single project, roll it out to more projects. Help other teams in your organization learn the benefits of automation and help them do it right.
• Schedule Your Automation Efforts - A good application lifecycle tool will allow you to organize your automated test cases into "test sets" that allow you to run test cases in a specific order. It should also allow you to schedule those test sets to run at specific intervals (nightly, weekly, monthly, etc.).

How can I learn more about Test Automation?
There are a number of automated and manual test management solutions on the market, as long as your selected solution allows you to follow the best practices of this newsletter, you can easily begin making the transition to automation and begin receiving a return on investment from your efforts.

If you don't have a solution for both automated and manual testing, Software Planner (http://www.SoftwarePlanner.com) and TestComplete (http://www.testcomplete.com) offer an integrated solution that offers both automated and manual test cases and has a keyword driven testing engine that ensures re-usability and maintainability.

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

• Software Planner - http://www.SoftwarePlanner.com
• AutomatedQA TestComplete (Automated Testing Tool) - http://www.TestComplete.com
• Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
• Test Case Training - http://www.PragmaticSW.com/Services.asp
• Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf