1. Draw up a testplan
Many testers would like to skip this step, but it is essential for structured testing. It depends of course on the size of the application (changes) you need to test, but in most cases there is no need for a large or complex document. Start with listing the changes that have been applied to the application, next detail where these changes impact and finally describe what checks are required to test all aspects of the impact.
2. Prepare test data
Make sure you use a set of data that is a good representation of real live data. For example use recently captured data for the same application or paper based data if the application is developed to move a process online.
3. Test for browser compatibility
Test the web application in all browsers/versions your application is meant to support. If the application is only used internally you can limit your testing to the standard(s) set for browsers by the company. However, when your application is meant for public access all commonly used browsers must be supported. If the application exists for considerable time backwards compatibility might be required to support browser versions that were common at the time the application was launched.
4. Screen texts
A web application, for example a form can contain a considerable amounts of text, which must be checked for:
• readability i.e. is it clear to user what is being said
• spelling and grammar errors
• legal and style requirements
5. Check mandatory fields
Test if all fields which are mandatory
• are marked with an asterisk behind the field name/label
• generate an appropriate error message when left blank
6. Check field sizes
Most fields will have a limitation for the number of characters that are allowed, for example a field that captures an Australian post code may only have up to 4 numeric positions. Check for each field if size validation is applied properly.
7. Check formatting
Sometimes values can be entered in different ways. For example some users might want to enter an ABN/ACN number or a phone number with spaces. Either your application needs to cater for this or warn users to omit spaces.
A field validation can behave differently when values are pasted in instead of entered manually. Make sure you check fields for both methods of data entry in particular memo fields for notes.
8. Check date fields
When testing date fields make sure
• no invalid dates are allowed, i.e. 30/02/2010 or 32/12/2010
• only dates that are within a valid period can be selected. For example if an applicant must enter a date of birth and must be at least 18 years old to apply, a date that is 17 years back from the current date should not be allowed.
• a date picker, if used delivers the same result as manual entry
9. Check data storage
Check for every field entered/selected if the correct value (no truncation) is stored in the appropriate field in the database table.
10. Check time-outs
Often end-users do not realise that applications accessed over the internet act differently from applications run from their local machine. For example a user might start filling in a web form, but leave it for hours before completing and submitting it. Be aware how your application behaves under these circumstances and make sure adverse effects are addressed.
Related posts:
