Usability is the ease of use and learn-ability of a human-made object such as a tool or device. In software engineering, usability is the degree to which a software can be used by specified consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use.
This is a list of questions we need to be asking ourselves around those usability and accessibility issues so that we can move forward with continuous improvements.
Comprehensive Testing Checklist for Testing Web and Desktop Applications:
Assumptions: Assume that your application supports the following functionalities:
– Forms with various fields
– Child windows
– Application interacts with database
– Various search filter criteria and display results
– Image upload
– Send email functionality
– Data export functionality
General Test Scenarios
1. All mandatory fields should be validated and indicated by an asterisk (*) symbol.
2. Validation error messages should be displayed properly at a correct position.
3. All error messages should be displayed in the same CSS style (e.g. using red colour)
4. General confirmation messages should be displayed using CSS style other than error messages style (e.g. using green colour)
5. Tool tips text should be meaningful.
6. Drop-down fields should have the first entry as blank or text like ‘Select’.
7. ‘Delete functionality’ for any record on a page should ask for a confirmation.
8. Select/deselect all records option should be provided if page supports record add/delete/update functionality
9. Amount values should be displayed with correct currency symbols.
10. Default page sorting should be provided.
11. Reset button functionality should set default values for all fields.
12. All numeric values should be formatted properly.
13. Input fields should be checked for the max field value. Input values greater than specified max limit should not be accepted or stored in the database.
14. Check all input fields for special characters.
15. Field labels should be standard e.g. field accepting user’s first name should be labelled properly as ‘First Name’.
16. Check page sorting functionality after add/edit/delete operations on any record.
17. Check for timeout functionality. Timeout values should be configurable. Check application behaviour after operation timeout.
18. Check cookies used in an application.
19. Check if downloadable files are pointing to the correct file paths.
20. All resource keys should be configurable in config files or database instead of hard coding.
21. Standard conventions should be followed throughout for naming resource keys.
22. Validate markup for all web pages (validate HTML and CSS for syntax errors) to make sure it is compliant with the standards.
23. Application crash or unavailable pages should be redirected to the error page.
24. Check text on all pages for spelling and grammatical errors.
25. Check numeric input fields with character input values. Proper validation message should appear.
26. Check for negative numbers if allowed for numeric fields.
27. Check amount fields with decimal number values.
28. Check functionality of buttons available on all pages.
29. The user should not be able to submit page twice by pressing submit button in quick succession.
30. Divide by zero errors should be handled for any calculations.
31. Input data with first and last position blank should be handled correctly.
GUI and Usability Test Scenarios
1. All fields on a page (e.g. text box, radio options, drop-down lists) should be aligned properly.
2. Numeric values should be justified correctly unless specified otherwise.
3. Enough space should be provided between field labels, columns, rows, error messages etc.
4. The scrollbar should be enabled only when necessary.
5. Font size, style, and colour for headline, description text, labels, infield data, and grid info should be standard as specified in SRS.
6. Description text box should be multi-lined.
7. Disabled fields should be greyed out and users should not be able to set focus on these fields.
8. Upon click of an input text field, mouse arrow pointer should get changed to the cursor.
9. The user should not be able to type in drop down select lists.
10. Information filled by users should remain intact when there is an error message on page submit. The user should be able to submit the form again by correcting the errors.
11. Check if proper field labels are used in error messages.
12. Drop-down field values should be displayed in defined sort order.
13. Tab and Shift+Tab order should work properly.
14. Default radio options should be pre-selected on the page load.
15. Field-specific and page level help messages should be available.
16. Check if the correct fields are highlighted in case of errors.
17. Check if the drop-down list options are readable and not truncated due to field size limit.
18. All buttons on a page should be accessible by keyboard shortcuts and the user should be able to perform all operations using a keyboard.
19. Check all pages for broken images.
20. Check all pages for broken links.
21. All pages should have a title.
22. Confirmation messages should be displayed before performing any update or delete operation.
23. Hourglass should be displayed when the application is busy.
24. Page text should be left justified.
25. The user should be able to select only one radio option and any combination for checkboxes.
Performance Testing Test Scenarios
1. Check if the page load time is within the acceptable range.
2. Check the page load on slow connections.
3. Check the response time for any action under a light, normal, moderate, and heavy load conditions.
4. Check performance of database stored procedures and triggers.
5. Check the database query execution time.
6. Check for load testing of the application.
7. Check for stress testing of the application.
8. Check CPU and memory usage under peak load condition.
Penetration testing:
Remember this is not functional testing. In Pentest your goal is to find security holes in the system. Below are some generic test cases and not necessarily applicable for all applications.
1) Check if the web application is able to identify spam attacks on contact forms used on the website.
2) Proxy server – Check if network traffic is monitored by proxy appliances. Proxy server makes it difficult for hackers to get internal details of the network thus protecting the system from external attacks.
3) Spam email filters – Verify if incoming and outgoing email traffic is filtered and unsolicited emails are blocked. Many email clients come with inbuilt spam filters which need to be configured as per your needs. These configuration rules can be applied to email headers, subject or body.
4) Firewall – Make sure entire network or computers are protected with Firewall. A Firewall can be a software or hardware to block unauthorized access to a system. A Firewall can prevent sending data outside the network without your permission.
5) Try to exploit all servers, desktop systems, printers and network devices.
6) Verify that all usernames and passwords are encrypted and transferred over secured connection like https.
7) Verify information stored in website cookies. It should not be in readable format.
8) Verify previously found vulnerabilities to check if the fix is working.
9) Verify if there is no open port in the network.
11) Verify all telephone devices.
12) Verify WIFI network security.
13) Verify all HTTP methods. PUT and Delete methods should not be enabled on a web server.
14) Verify if the password meets the required standards. The password should be at least 8 characters long containing at least one number and one special character.
15) Username should not be like “admin” or “administrator”.
16) Application login page should be locked upon few unsuccessful login attempts.
17) Error messages should be generic and should not mention specific error details like “Invalid username” or “Invalid password”.
19) Verify if special characters, HTML tags and scripts are handled properly as an input value.
20) Internal system details should not be revealed in any of the error or alert messages.
21) Custom error messages should be displayed to end user in case of web page crash.
22) Verify use of registry entries. Sensitive information should not be kept in the registry.
23) All files must be scanned before uploading to the server.
24) Sensitive data should not be passed in URLs while communicating with different internal modules of the web application.
25) There should not be any hardcoded username or password in the system.
26) Verify all input fields with long input string with and without spaces.
27) Verify if reset password functionality is secure.
28) Verify application for SQL Injection.
29) Verify application for Cross Site Scripting.
31) Important input validations should be done at server side instead of JavaScript checks at the client side.
32) Critical resources in the system should be available to authorized persons and services only.
33) All access logs should be maintained with proper access permissions.
34) Verify user session ends upon log off.
35) Verify that directory browsing is disabled on the server.
36) Verify that all applications and database versions are up to date.
37) Verify URL manipulation to check if a web application is not showing any unwanted information.
38) Verify memory leak and buffer overflow.
39) Verify if incoming network traffic is scanned to find Trojan attacks.
40) Verify if the system is safe from Brute Force Attacks – a trial and error method to find sensitive information like passwords.
41) Verify if system or network is secured from DoS (denial-of-service) attacks. Hacker can target network or a single computer with continuous requests due to which resources on target system gets overloaded resulting in the denial of service for legit requests.
42) Verify application for HTML script injection attacks.
43) Verify against COM & ActiveX attacks.
44) Verify against spoofing attacks. Spoofing can be of multiple types – IP address spoofing, Email ID spoofing, ARP spoofing, Referrer spoofing, Caller ID spoofing, Poisoning of file-sharing networks, GPS spoofing.
45) Check for uncontrolled format string attack – a security attack that can cause the application to crash or execute the harmful script on it.
46) Verify XML injection attack – used to alter the intended logic of the application.
47) Verify against canonicalization attacks.
48) Verify if the error pages are displaying any information that can be helpful for a hacker to enter into the system.
49) Verify if any critical data like the password is stored in secret files on the system.
50) Verify if the application is returning more data than it is required.
Security Testing Test Scenarios
1. Check for SQL injection attacks.
2. Secure pages should use HTTPS protocol.
3. Page crash should not reveal application or server info. Error page should be displayed for this.
4. Escape special characters in the input.
5. Error messages should not reveal any sensitive information.
6. All credentials should be transferred over an encrypted channel.
7. Test password security and password policy enforcement.
8. Check application logout functionality.
9. Check for Brute Force Attacks.
10. Cookie information should be stored in encrypted format only.
11. Check session cookie duration and session termination after timeout or logout.
11. Session tokens should be transmitted over a secured channel.
13. The password should not be stored in cookies.
14. Test for Denial of Service attacks.
15. Test for memory leakage.
16. Test unauthorized application access by manipulating variable values in the browser address bar.
17. Test file extension handing so that exe files are not uploaded and executed on the server.
18. Sensitive fields like passwords and credit card information should not have to autocomplete enabled.
19. File upload functionality should use file type restrictions and also anti-virus for scanning uploaded files.
20. Check if directory listing is prohibited.
21. Password and other sensitive fields should be masked while typing.
22. Check if forgot password functionality is secured with features like temporary password expiry after specified hours and security question is asked before changing or requesting a new password.
23. Verify CAPTCHA functionality.
24. Check if important events are logged in log files.
25. Check if access privileges are implemented correctly.
Test Scenarios for Sending Emails
(Test cases for composing or validating emails are not included here)
(Make sure to use dummy email addresses before executing email related tests)
1. Email template should use standard CSS for all emails.
2. Email addresses should be validated before sending emails.
3. Special characters in the email body template should be handled properly.
4. Language specific characters (e.g. Russian, Chinese or German language characters) should be handled properly in the email body template.
5. Email subject should not be blank.
6. Placeholder fields used in the email template should be replaced with actual values e.g. {Firstname} {Lastname} should be replaced with individuals first and last name properly for all the recipients.
7. If reports with dynamic values are included in the email body and report data should be calculated correctly.
8. Email sender name should not be blank.
9. Emails should be checked in different email clients like Outlook, Gmail, Hotmail, Yahoo! mail etc.
10. Check send email functionality using TO, CC and BCC fields.
11. Check plain text emails.
12. Check HTML format emails.
13. Check email header and footer for company logo, privacy policy and other links.
14. Check emails with attachments.
15. Check send email functionality to single, multiple or distribution list recipients.
16. Check if a reply to email address is correct.
17. Check sending the high volume of emails.
Test Scenarios for a Window
1. Check if default window size is correct.
2. Check if child window size is correct.
3. Check if there is any field on the page with default focus (in general, the focus should be set on first input field of the screen).
4. Check if child windows are getting closed on closing parent/opener window.
5. If child window is opened, user should not be able to use or update any field in the background or parent window
6. Check window minimize, maximize, and close functionality.
7. Check if the window is re-sizable.
8. Check scroll bar functionality for parent and child windows.
9. Check cancel button functionality for the child window.
Test Scenarios for Filter Criteria
1. The user should be able to filter results using all parameters on the page.
2. Refine search functionality should load search page with all user-selected search parameters.
3. When there are at least one filter criteria required to perform the search operation, make sure proper error message is displayed when the user submits the page without selecting any filter criteria.
4. When at least one filter criteria selection is not compulsory, the user should be able to submit the page and the default search criteria should get used to query results.
5. Proper validation messages should be displayed for all invalid values for filter criteria.
Test Scenarios for Result Grid/Tables
1. Page loading symbol should be displayed when it’s taking more than default time to load the result page.
2. Check if all the search parameters are used to fetch data shown on the result grid.
3. The total number of results should be displayed in the result grid.
4. Search criteria used for searching should be displayed in the result grid.
5. Result grid values should be sorted by default column.
6. Sorted columns should be displayed with a sorting icon.
7. Result grids should include all the specified columns with correct values.
8. Ascending and descending sorting functionality should work for columns supported with data sorting.
9. Result grids should be displayed with proper column and row spacing.
10. Pagination should be enabled when there are more results than the default result count per page.
11. Check for Next, Previous, First and Last page pagination functionality.
12. Duplicate records should not be displayed in the result grid.
13. Check if all the columns are visible and horizontal scrollbar is enabled if necessary.
14. Check the data for dynamic columns (columns whose values are calculated dynamically based on the other column values).
15. For result grids showing reports check ‘Totals’ row and verify total for every column.
16. For result grids showing reports check ‘Totals’ row data when pagination is enabled and the user gets navigated to the next page.
17. Check if proper symbols are used for displaying column values e.g. % symbol should be displayed for percentage calculation.
18. Check result grid data to know if the date range is enabled.
Comments