Web Applications Testing: March 2011

Monday, March 28, 2011

Top 20 practical software testing tips you should read before testing any application.

01. Learn to analyze your test results thoroughly. Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions.

02. Learn to maximize the test coverage every time you test any application. Though 100 percent test coverage might not be possible still you can always try to reach near it.

03. To ensure maximum test coverage break your application under test (AUT) into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.
E.g: Let’s assume you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the ‘User information’ form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.

04. While writing test cases, write test cases for intended functionality first i.e. for valid conditions according to requirements. Then write test cases for invalid conditions. This will cover expected as well unexpected behavior of application under test.

05. Think positive. Start testing the application by intend of finding bugs/errors. Don’t think beforehand that there will not be any bugs in the application. If you test the application by intention of finding bugs you will definitely succeed to find those subtle bugs also.

06. Write your test cases in requirement analysis and design phase itself. This way you can ensure all the requirements are testable.

07. Make your test cases available to developers prior to coding. Don’t keep your test cases with you waiting to get final application release for testing, thinking that you can log more bugs. Let developers analyze your test cases thoroughly to develop quality application. This will also save the re-work time.

08. If possible identify and group your test cases for regression testing. This will ensure quick and effective manual regression testing.

09. Applications requiring critical response time should be thoroughly tested for performance. Performance testing is the critical part of many applications. In manual testing this is mostly ignored part by testers due to lack of required performance testing large data volume. Find out ways to test your application for performance. If not possible to create test data manually then write some basic scripts to create test data for performance test or ask developers to write one for you.

10. Programmers should not test their own code. As discussed in our previous post, basic unit testing of developed application should be enough for developers to release the application for testers. But you (testers) should not force developers to release the product for testing. Let them take their own time. Everyone from lead to manger know when the module/update is released for testing and they can estimate the testing time accordingly. This is a typical situation in agile project environment.

11. Go beyond requirement testing. Test application for what it is not supposed to do.

12. While doing regression testing use previous bug graph (Bug graph – number of bugs found against time for different modules). This module-wise bug graph can be useful to predict the most probable bug part of the application.

13. Note down the new terms, concepts you learn while testing. Keep a text file open while testing an application. Note down the testing progress, observations in it. Use these notepad observations while preparing final test release report. This good habit will help you to provide the complete unambiguous test report and release details.

14. Many times testers or developers make changes in code base for application under test. This is required step in development or testing environment to avoid execution of live transaction processing like in banking projects. Note down all such code changes done for testing purpose and at the time of final release make sure you have removed all these changes from final client side deployment file resources.

15. Keep developers away from test environment. This is required step to detect any configuration changes missing in release or deployment document. Sometimes developers do some system or application configuration changes but forget to mention those in deployment steps. If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.

16. It’s a good practice to involve testers right from software requirement and design phase. These way testers can get knowledge of application dependability resulting in detailed test coverage. If you are not being asked to be part of this development cycle then make request to your lead or manager to involve your testing team in all decision making processes or meetings.

17. Testing teams should share best testing practices, experience with other teams in their organization.

18. Increase your conversation with developers to know more about the product. Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings. But also when you understand the requirement or resolve any dispute – make sure to communicate the same over written communication ways like emails. Do not keep anything verbal.

19. Don’t run out of time to do high priority testing tasks. Prioritize your testing work from high to low priority and plan your work accordingly. Analyze all associated risks to prioritize your work.

20. Write clear, descriptive, unambiguous bug report. Do not only provide the bug symptoms but also provide the effect of the bug and all possible solutions.

Reference -
http://ezinearticles.com/?The-Top-20-Practical-Software-Testing-Tips&id=5888971

Sunday, March 27, 2011

Top 10 Negative Test Cases

01. Embedded Single Quote –
Most SQL based database systems have issues when users store information that contain a single quote (e.g. John's car). For each screen that accepts alphanumeric data entry, try entering text that contains one or more single quotes.

02. Required Data Entry –
Your functional specification should clearly indicate fields that require data entry on screens. Test each field on the screen that has been indicated as being required to ensure it forces you to enter data in the field.

03. Field Type Test –
Your functional specification should clearly indicate fields that require specific data entry requirements (date fields, numeric fields, phone numbers, zip codes, etc). Test each field on the screen that has been indicated as having special types to ensure it forces you to enter data in the correct format based on the field type (numeric fields should not allow alphabetic or special characters, date fields should require a valid date, etc)

04. Field Size Test –
Your functional specification should clearly indicate the number of characters you can enter into a field (for example, the first name must be 50 or less characters). Write test cases to ensure that you can only enter the specified number of characters. Preventing the user from entering more characters than is allowed is more elegant than giving an error message after they have already entered too many characters.

05. Numeric Bounds Test –
For numeric fields, it is important to test for lower and upper bounds. For example, if you are calculating interest charged to an account, you would never have a negative interest amount applied to an account that earns interest, therefore, you should try testing it with a negative number. Likewise, if your functional specification requires that a field be in a specific range (e.g. from 10 to 50), you should try entering 9 or 51, it should fail with a graceful message.

06. Numeric Limits Test –
Most database systems and programming languages allow numeric items to be identified as integers or long integers. Normally, an integer has a range of -32,767 to 32,767 and long integers can range from -2,147,483,648 to 2,147,483,647. For numeric data entry that do not have specified bounds limits, work with these limits to ensure that it does not get an numeric overflow error.

07. Date Bounds Test –
For date fields, it is important to test for lower and upper bounds. For example, if you are checking a birth date field, it is probably a good bet that the person's birth date is no older than 150 years ago. Likewise, their birth date should not be a date in the future.

08. Date Validity –
For date fields, it is important to ensure that invalid dates are not allowed (04/31/2007 is an invalid date). Your test cases should also check for leap years (every 4th and 400th year is a leap year).

09. Web Session Testing –
Many web applications rely on the browser session to keep track of the person logged in, settings for the application, etc. Most screens in a web application are not designed to be launched without first logging in. Create test cases to launch web pages within the application without first logging in. The web application should ensure it has a valid logged in session before rendering pages within the application.

10. Performance Changes –
As you release new versions of your product, you should have a set of performance tests that you run that identify the speed of your screens (screens that list information, screens that add/update/delete data, etc). Your test suite should include test cases that compare the prior release performance statistics to the current release. This can aid in identifying potential performance problems that will be manifested with code changes to the current release.

Reference - http://www.qaguild.com/weekly_archives.php?UID=21

Twenty Essential Firefox Add-ons For Testing

01. Firesizer 1.2
Provides a menu and status bar to resize the window dimensions to a specific size. Unlike other similar extensions, this one sets the size of the *entire window*, not just the HTML area. This add-on is extremely useful if you want to test how your application will look in different size windows.

02. W3C Page Validator 3.0.0
Validates a page using the W3C Markup Validation Service. Adds an option to the right-click context menu and to the Tools menu to allow for easy validation of the current page. Opens the results in a new tab. This is a simple extension that will work only for online pages. Depending on your context, if your organization is committed to create W3C compliant web applications, this might be very handy.

03. SQL Injection 1.2
This is an excellent tool to help developers in identifying SQL injection vulnerabilities. This add-on transform checkboxes, radio buttons and select elements to an input text box. It sets all form fields free to edit their values.

04. QuickRestart 1.1.6
If you need to restart firefox to test your cookies, sessions or because of any other reason, this little button in your toolbar will do it with a mouse click. This simple extension adds a "Restart Firefox" item to the "File" menu. You can also use the Ctrl+Alt+R keyboard shortcut, or the included toolbar button. To use the toolbar button: right click on toolbar -> Customize... then drag the Restart button to the toolbar. This is a very simple utility, but can be extremely useful.

05. Firebug 1.7.0
Firebug integrates with Firefox to put a wealth of web development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page. Your firefox should have firebug if you are working in web application testing domain.

06. Regular Expressions Tester 3.2.11
This small add-on allows you to test your regular expression. The tool includes options like case sensitive, global and multiline search, color highlighting of found expressions and of special characters, a replacement function incl. backreferences, and auto-closing of brackets, testing while writing and saving and managing of expressions.

07. HttpFox 0.8.8
It is a HTTP analyzer addon for Firefox. This add-on is an amazing tool if you want to dig deeper into http request / response and analyze all the traffic. Using this add-on, you can get information about request / response header, sent and received cookies, Querystring parameters, POST parameters and Response body.

08. HackBar 1.6.0
It is a Simple security audit / Penetration test tool. It is useful for SQL injections, XSS holes and site security.

09. Web Developer 1.1.9
The Web Developer extension adds various web developer tools to a browser. This one along with the firebug are must have extensions if you are working in web application domain. These extensions are complete toolset and probably require separate articles to explain their capabilities.

10. Accessibar 0.7.8
It is an amazing add-on to test accessibility of any site. Using this add-on, you can change font size, line spacing, hide all the images / flash and so on. It also integrates text to speech reader and reads string on mouse hover / focus elements.

11. Add N Edit Cookies 0.2.1.3
There are very few applications which does not use cookies these days. This little add-on allows you to add / edit session, saved cookies and test how your application will respond to changes in the cookies setting.

12. LinkChecker 0.6.7
This is a very simple tool to check if there are any broken links on the web page. It highlights all the links in various colors to show if they are broken or not.

13. MeasureIt 0.4.7
If you have a design team which is very particular about the size of every element, than this little add-on can be used to test height and width of all the elements. It draws a ruler around any element and shows height / width of the element.

14. YSlow 2.1.0
YSlow analyzes web pages and gives you information on why they are slow based on the Yahoo's rule for high performance websites.

15. User Agent Switcher 0.7.3
If your application behaves differently based on the user agent or if it records this information than this add-on can be very handy. It simply switch the user agent of the browser. Please note, changing user agent will not make it render like IE.

16. FireShot 0.88
FireShot can be handy in situations where you want to take screen shot of your web application. FireShot is a Firefox extension that creates screenshots of web pages (entirely or just visible part). It even allows you to write comments, highlight specific element of your application and so on.

17. URLParams 2.2.0
This little add-on make it convenient to analyze GET and POST parameters of the current website in the sidebar. You can ever change their values, add new parameters etc.

18. Tamper Data 11.0.1
Tamper Data allows you to view and modify HTTP/HTTPS headers and post parameters. You can use it to test security of your web applications by modifying POST data and analyzing how your application will respond to those changes.

19. View Dependencies 0.3.3.2
View Dependencies adds a tab to the Page Info window, in which it lists all the files which were loaded to show the current page. This is an extremely useful add-on if you want to figure out what are all the files / images etc. are getting downloaded for every page, how much time they are taking and many such details.

20. Flash Switcher 2.0.2
If you are involved in testing Flash Applications, than this little add-on is extremely useful to test your flash application on various versions of flash players. This extension allows you to easily switch from one flash player plug in version to another, or also to remove or save the currently installed plug in (maybe for testing the express install).

Reference - http://www.testinggeek.com/index.php/testing-articles/176-twenty-essential-firefox-addons-for-testing

Friday, March 25, 2011

Web Standards Checklist

The term web standards can mean different things to different people. For some, it is 'table-free sites', for others it is 'using valid code'. However, web standards are much broader than that. A site built to web standards should adhere to standards (HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG etc) and pursue best practices (valid code, accessible code, semantically correct code, user-friendly URLs etc).

In other words, a site built to web standards should ideally be lean, clean, CSS-based, accessible, and usable and search engine friendly.

About the checklist-

This is not an uber-checklist. There are probably many items that could be added. More importantly, it should not be seen as a list of items that must be addressed on every site that you develop. It is simply a guide that can be used:

• To show the breadth of web standards
• As a handy tool for developers during the production phase of websites
• As an aid for developers who are interested in moving towards web standards

The checklist:

* Quality of code :
01. Does the site use a correct Doctype?
02. Does the site use a Character set?
03. Does the site use Valid (X)HTML?
04. Does the site use Valid CSS?
05. Does the site use any CSS hacks?
06. Does the site use unnecessary classes or ids?
07. Is the code well structured?
08. Does the site have any broken links?
09. How does the site perform in terms of speed/page size?
10. Does the site have JavaScript errors?

* Degree of separation between content and presentation :
01. Does the site use CSS for all presentation aspects (fonts, colour, padding, borders etc)?
02. Are all decorative images in the CSS, or do they appear in the (X)HTML?

* Accessibility for users :
01. Are "alt" attributes used for all descriptive images?
02. Does the site use relative units rather than absolute units for text size?
03. Do any aspects of the layout break if font size is increased?
04. Does the site use visible skip menus?
05. Does the site use accessible forms?
06. Does the site use accessible tables?
07. Is there sufficient colour brightness/contrasts?
08. Is colour alone used for critical information?
09. Is there delayed responsiveness for dropdown menus (for users with reduced motor skills)?
10. Are all links descriptive (for blind users)?

* Accessibility for devices :
01. Does the site work acceptably across modern and older browsers?
02. Is the content accessible with CSS switched off or not supported?
03. Is the content accessible with images switched off or not supported?
04. Does the site work in text browsers such as Lynx?
05. Does the site work well when printed?
06. Does the site work well in Hand Held devices?
07. Does the site include detailed metadata?
08. Does the site work well in a range of browser window sizes?

* Basic Usability :
01. Is there a clear visual hierarchy?
02. Are heading levels easy to distinguish?
03. Does the site have easy to understand navigation?
04. Does the site use consistent navigation?
05. Are links underlined?
06. Does the site use consistent and appropriate language?
07. Do you have a sitemap page and contact page? Are they easy to find?
08. For large sites, is there a search tool?
09. Is there a link to the home page on every page in the site?
10. Are visited links clearly defined with a unique color?

* Site management :
01. Does the site have a meaningful and helpful 404 error page that works from any depth in the site?
02. Does the site use friendly URLs?
03. Do your URLs work without "www"?
04. Does the site have a favicon?

01. Quality of code

1.1 Does the site use a correct Doctype? :
A doctype (short for 'document type declaration') informs the validator which version of (X)HTML you're using, and must appear at the very top of every web page. Doctypes are a key component of compliant web pages: your markup and CSS won't validate without them.

1.2 Does the site use a Character set? :
If a user agent (eg. a browser) is unable to detect the character encoding used in a Web document, the user may be presented with unreadable text. This information is particularly important for those maintaining and extending a multilingual site, but declaring the character encoding of the document is important for anyone producing XHTML/HTML or CSS.

1.3 Does the site use Valid (X)HTML? :
Valid code will render faster than code with errors. Valid code will render better than invalid code. Browsers are becoming more standards compliant, and it is becoming increasingly necessary to write valid and standards compliant HTML.

1.4 Does the site use Valid CSS? :
You need to make sure that there aren't any errors in either your HTML or your CSS, since mistakes in either place can result in botched document appearance.

1.5 Does the site use any CSS hacks? :
Basically, hacks come down to personal choice, the amount of knowledge you have of workarounds, the specific design you are trying to achieve.

1.6 Does the site use unnecessary classes or ids? :
I've noticed that developers learning new skills often end up with good CSS but poor XHTML. Specifically, the HTML code tends to be full of unnecessary divs and ids. This results in fairly meaningless HTML and bloated style sheets.

1.7 Is the code well structured? :
Semantically correct markup uses html elements for their given purpose. Well structured HTML has semantic meaning for a wide range of user agents (browsers without style sheets, text browsers, PDAs, search engines etc.)

1.8 Does the site have any broken links? :
Broken links can frustrate users and potentially drive customers away. Broken links can also keep search engines from properly indexing your site.

1.9 How does the site perform in terms of speed/page size? :
Don't make me wait... That's the message users give us in survey after survey. Even broadband users can suffer the slow-loading blues.

1.10 Does the site have JavaScript errors? :
Internet Explore for Windows allows you to turn on a debugger that will pop up a new window and let you know there are javascript errors on your site. This is available under 'Internet Options' on the Advanced tab. Uncheck 'Disable script debugging'.

02. Degree of separation between content and presentation

2.1 Does the site use CSS for all presentation aspects (fonts, colour, padding, borders etc)?
Use style sheets to control layout and presentation.

2.2 Are all decorative images in the CSS, or do they appear in the (X)HTML?
The aim for web developers is to remove all presentation from the html code, leaving it clean and semantically correct.

03. Accessibility for users

3.1 Are "alt" attributes used for all descriptive images?
Provide a text equivalent for every non-text element

3.2 Does the site use relative units rather than absolute units for text size?
Use relative rather than absolute units in markup language attribute values and style sheet property values'.

3.3 Do any aspects of the layout break if font size is increased?
Try this simple test. Look at your website in a browser that supports easy incrementation of font size. Now increase your browser's font size. And again. And again... Look at your site. Does the page layout still hold together? It is dangerous for developers to assume that everyone browses using default font sizes.

3.4 Does the site use visible skip menus?
A method shall be provided that permits users to skip repetitive navigation links.
Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group....blind visitors are not the only ones inconvenienced by too many links in a navigation area. Recall that a mobility-impaired person with poor adaptive technology might be stuck tabbing through that morass.

3.5 Does the site use accessible forms?
Forms aren't the easiest of things to use for people with disabilities. Navigating around a page with written content is one thing, hopping between form fields and inputting information is another.

3.6 Does the site use accessible tables?
For data tables, identify row and column headers... For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

3.7 Is there sufficient colour brightness/contrasts?
Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits.

3.8 Is colour alone used for critical information?
Ensure that all information conveyed with colour is also available without colour, for example from context or markup.
There are basically three types of colour deficiency; Deuteranope (a form of red/green colour deficit), Protanope (another form of red/green colour deficit) and Tritanope (a blue/yellow deficit- very rare).

3.9 Is there delayed responsiveness for dropdown menus?
Users with reduced motor skills may find dropdown menus hard to use if responsiveness is set too fast.

3.10 Are all links descriptive?
Link text should be meaningful enough to make sense when read out of context - either on its own or as part of a sequence of links. Link text should also be terse.

4. Accessibility for devices.

4.1 Does the site work acceptably across modern and older browsers?
Before starting to build a CSS-based layout, you should decide which browsers to support and to what level you intend to support them.

4.2 Is the content accessible with CSS switched off or not supported?
Some people may visit your site with either a browser that does not support CSS or a browser with CSS switched off. In content is structured well, this will not be an issue.

4.3 Is the content accessible with images switched off or not supported?
Some people browse websites with images switched off - especially people on very slow connections. Content should still be accessible for these people.

4.4 Does the site work in text browsers such as Lynx?
This is like a combination of images and CSS switched off. A text-based browser will rely on well structured content to provide meaning.

4.5 Does the site work well when printed?
You can take any (X)HTML document and simply style it for print, without having to touch the markup.

4.6 Does the site work well in Hand Held devices?
This is a hard one to deal with until hand held devices consistently support their correct media type. However, some layouts work better in current hand-held devices. The importance of supporting hand held devices will depend on target audiences.

4.7 Does the site include detailed metadata?
Metadata is machine understandable information for the web
Metadata is structured information that is created specifically to describe another resource. In other words, metadata is 'data about data'.

4.8 Does the site work well in a range of browser window sizes?
It is a common assumption amongst developers that average screen sizes are increasing. Some developers assume that the average screen size is now 1024px wide. But what about users with smaller screens and users with hand held devices? Are they part of your target audience and are they being disadvantaged?

05. Basic Usability

5.1 Is there a clear visual hierarchy?
Organise and prioritise the contents of a page by using size, prominence and content relationships.

5.2 Are heading levels easy to distinguish?
Use header elements to convey document structure and use them according to specification.

5.3 Is the site's navigation easy to understand?
Your navigation system should give your visitor a clue as to what page of the site they are currently on and where they can go next.

5.4 Is the site's navigation consistent?
If each page on your site has a consistent style of presentation, visitors will find it easier to navigate between pages and find information

5.5 Does the site use consistent and appropriate language?
The use of clear and simple language promotes effective communication. Trying to come across as articulate can be as difficult to read as poorly written grammar, especially if the language used isn't the visitor's primary language.

5.6 Does the site have a sitemap page and contact page? Are they easy to find?
Most site maps fail to convey multiple levels of the site's information architecture. In usability tests, users often overlook site maps or can't find them. Complexity is also a problem: a map should be a map, not a navigational challenge of its own.

5.7 For large sites, is there a search tool?
While search tools are not needed on smaller sites, and some people will not ever use them, site-specific search tools allow users a choice of navigation options.

5.8 Is there a link to the home page on every page in the site?
Some users like to go back to a site's home page after navigating to content within a site. The home page becomes a base camp for these users, allowing them to regroup before exploring new content.

5.9 Are links underlined?
To maximise the perceived affordance of clickability, colour and underline the link text. Users shouldn't have to guess or scrub the page to find out where they can click.

5.10 Are visited links clearly defined?
Most important, knowing which pages they've already visited frees users from unintentionally revisiting the same pages over and over again.

06. Site management

6.1 Does the site have a meaningful and helpful 404 error page that works from any depth in the site?
You've requested a page - either by typing a URL directly into the address bar or clicking on an out-of-date link and you've found yourself in the middle of cyberspace nowhere. A user-friendly website will give you a helping hand while many others will simply do nothing, relying on the browser's built-in ability to explain what the problem is.

6.2 Does the site use friendly URLs?
Most search engines (with a few exceptions - namely Google) will not index any pages that have a question mark or other character (like an ampersand or equals sign) in the URL... what good is a site if no one can find it?
One of the worst elements of the web from a user interface standpoint is the URL. However, if they're short, logical, and self-correcting, URLs can be acceptably usable.

6.3 Does the site's URL work without "www"?
While this is not critical, and in some cases is not even possible, it is always good to give people the choice of both options. If a user types your domain name without the www and gets no site, this could disadvantage both the user and you.

6.4 Does the site have a favicon?
A Favicon is a multi-resolution image included on nearly all professionally developed sites. The Favicon allows the webmaster to further promote their site, and to create a more customized appearance within a visitor's browser.

Favicons are definitely not critical. However, if they are not present, they can cause 404 errors in your logs (site statistics). Browsers like IE will request them from the server when a site is bookmarked. If a favicon isn't available, a 404 error may be generated. Therefore, having a favicon could cut down on favicon specific 404 errors. The same is true of a 'robots.txt' file.

Reference -http://www.maxdesign.com.au/articles/checklist/

Sunday, March 6, 2011

Top 5 Web Browsers

Friday, March 4, 2011

35 Useful Test Cases for Testing User Interfaces

1. Required Fields
If the screen requires data entry on a specific field, designers should identify the required fields with a red asterisk and generate 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 is limited to 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 the 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 the application opens a document named Minutes.txt and 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 the 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 the screen allows changing of data without saving, it should prompt users to save if they 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 the user interface allows deleting several records in a row, in some cases developers should consider allowing them to ignore the confirmation as it might get frustrating to click the confirmation over and over again.

12. Type Ahead
If the user interface uses combo boxes (drop down lists), be sure to include type ahead (if there are hundreds of items in a list, users should be able to skip to the first item that begins with that letter when they type in the first letter).

13. Grammar and Spelling
Ensure the test cases look for grammar or spelling errors.

14. Table Scrolling
If the application lists information in table format and the data in the table extends past one page, the scrolling should scroll the data but leave the table headers intact.

15. Error Logging
If fatal errors occur as users use your application, ensure that the 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 the 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 users are currently in.

20. Dialog Box Consistency
Use a style guide to document what choices are available for dialog boxes. Designers should not have Save/Cancel dialog on one screen and an OK/Cancel on another. This is inconsistent.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. Brevity
Ensure that narrative text, error messages and other instructions are presented in laymen’s terms but are brief and to-the-point.

27. 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.

28. 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.

29. 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.

30. 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).

31. 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.

32. 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.

33. 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.

34. Grammar and Spelling
Ensure that you have test cases that look for grammar or spelling errors.

35. Shortcuts
If your application allows short cut keys (like CTRL+S to save), ensure that all screens allow using of the consistent shortcuts.

Reference -http://www.vietnamesetestingboard.org/zbxe/?document_srl=194413

50 Tips To A User Friendly Website

1. Clicking on the logo should take you to the home page;

2. Your logo/site title should be positioned in the top left of the page;

3. Duplicate your main navigational links in the page footer with links to additional, but less prominent pages;

4. Keep your navigation positioning consistent from page to page;

5. Don’t open links in a new tab/window, except PDF’s and embedded documents;

6. Highlight your current location in your navigation bar;

7. Use reasonable sized fonts (12px or larger);

8. Make sure font sizes are flexible (Use em’s or %, not px);

9. Sans-serif fonts are easier to read at small sizes;

10. Serif fonts are easier to read at large sizes;

11. Center your layout on the screen;

12. Use a page width appropriate for your audience (Older people use lower resolutions, tech savvy people use higher resolutions);

13. Use whitespace to logically group related items on the page;

14. Use font sizes, colors and styles to prioritize content;

15. Use 1.4 or 1.5em line height;

16. Use line lengths of 45 – 60 characters, the same as a paperback book;

17. Link to related content within the context of your page content;

18. Make sure your links change color/style when visited;

19. Always underline links, except some navigational cases;

20. Do not make important parts of the website look like an advertisement;

21. Use pull quotes to highlight important content in a lengthy article;

22. Text should be concise and scannable;

23. Use dark gray text instead of black text on a white background;

24. Break long pages into multiple pages;

25. Do not use all uppercase words, word shape helps word recognition;

26. Divide text into sections and use sub headlines to make content more easily scanned;

27. Keep a consistent layout, colors and typography throughout the whole site;

28. Print friendly automatically with print stylesheets;

29. Use buttons to submit forms (Some images which look like buttons are ok);

30. Don’t disguise or over-style inputs;

31. Don’t redesign standard UI elements, like scrollbars (this means you, flash people!);

32. Use breadcrumb navigation for hierarchical content;

33. Search results page should reiterate the phrase you searched for;

34. Do call your homepage “home” – not “welcome,” “front page,” “your company name” or anything else;

35. Use short and easy to read URL’s;

36. Give links to other content on your site related to their current page;

37. Optimize images for fast downloading;

38. Publish new content regularly, don’t “set it and forget it;”

39. Test in all browsers and OS’s, and different versions – IE, Firefox, Safari, Opera and Chrome;

40. Listen to your users and let them dictate changes (user centered design);

41. Avoid using jargon in page copy unless absolutely necessary;

42. Keep forms short, only ask for what you absolutely need;

43. Encourage conversation around your content. Comments, forums, etc…;

44. Include a text only sitemap;

45. Use the title attribute on links to add more context;

46. Never use “click here” as the text on a link;

47. Write in a inverted pyramid style;

48. Create friendly 404 pages which help people find content;

49. Create incentive to come back later;

50. Connect information via hyperlinks, don’t force navigational channels;

Reference -
http://www.designinginteractive.com/design/50-tips-to-a-user-friendly-website/