180+ Web Application Testing Example Test Cases (Sample Checklist)

Web Application Testing Example Test Cases: This is a complete Testing Checklist for both web-based and desktop applications.

This is a very comprehensive list of Web Application Testing Example Test Cases/scenarios. Our goal is to share one of the most comprehensive testing checklists ever written and this is not yet done. We’ll keep updating this post in the future as well with more test cases and scenarios. If you don’t have time to read it now, please feel free to share this with your friends and bookmark it for later. 

Make testing checklist as an integral part of your test case writing process. Using this checklist, you can easily create hundreds of test cases for testing web or desktop applications.

Sample web application test cases and scenarios

These are all general test cases and should be applicable for almost all kind of applications. Refer these tests while writing test cases for your project and I’m sure you will cover most of the testing types

except the application specific business rules provided in your SRS documents.

Though this is a common checklist, I recommend preparing a standard testing checklist tailored to your specific needs using below test cases in addition to application-specific tests.

Importance of Using Checklist for Testing

#1) Maintaining a standard repository of reusable test cases for your application will ensure that most common bugs will be caught more quickly.
#2) A checklist helps to complete writing test cases quickly for new versions of the application.
#3) Reusing the test cases help to save money on resources to write repetitive tests.
#4) Important test cases will be covered always, thereby making it almost impossible to forget.
#5) The testing checklist can be referred by developers to ensure if the most common issues are fixed in the development phase itself.

Notes:

– Execute these scenarios with different user roles e.g. admin user, guest user etc.
– For web applications, these scenarios should be tested on multiple browsers like IE, FF, Chrome, and Safari with versions approved by the client.
– Test with different screen resolutions like 1024 x 768, 1280 x 1024, etc.
– An application should be tested on a variety of displays like LCD, CRT, Notebooks, Tablets, and Mobile phones.
– Test application on different platforms like Windows, Mac, Linux operating systems etc.

Software Testing Checklist

180+ Web Application Testing Example Test Cases

Assumptions: Assume that your application supports the following functionalities
– Forms with various fields
– Child windows
–  The application interacts with the 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 color)
4. General confirmation messages should be displayed using CSS style other than error messages style (e.g. using green color)
5. Tooltips 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 labeled 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 behavior 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 the 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 color 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 a 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.

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 the 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

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 sort icon.
7. Result grids should include all the specified columns with correct values.
8. Ascending and descending sorting functionality should work for columns supported by 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 the 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.

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 the first input field of the screen).
4. Check if child windows are getting closed on closing parent/opener window.
5. If the child window is opened, the 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.

Database Testing Test Scenarios

1. Check if correct data is getting saved in the database upon successful page submit.
2. Check values for columns which are not accepting null values.
3. Check for data integrity. Data should be stored in single or multiple tables based on the design.
4. Index names should be given as per the standards e.g. IND_<Tablename>_<ColumnName>
5. Tables should have a primary key column.
6. Table columns should have description information available (except for audit columns like created date, created by etc.)
7. For every database add/update operation log should be added.
8. Required table indexes should be created.
9. Check if data is committed to the database only when the operation is successfully completed.
10. Data should be rolled back in case of failed transactions.
11. Database name should be given as per the application type i.e. test, UAT, sandbox, live (though this is not a standard it is helpful for database maintenance)
12. Database logical names should be given according to the database name (again this is not standard but helpful for DB maintenance).
13. Stored procedures should not be named with a prefix “sp_”
14. Check if values for table audit columns (like created date, created by, updated, updated by, is deleted, deleted data, deleted by etc.) are populated properly.
15. Check if input data is not truncated while saving. Field length shown to the user on the page and in database schema should be the same.
16. Check numeric fields with minimum, maximum, and float values.
17. Check numeric fields with negative values (for both acceptance and non-acceptance).
18. Check if radio button and drop-down list options are saved correctly in the database.
19. Check if the database fields are designed with the correct data type and data length.
20. Check if all the table constraints like a Primary key, Foreign key etc. are implemented correctly.
21. Test stored procedures and triggers with sample input data.
22. Input field leading and trailing spaces should be truncated before committing data to the database.
23. Null values should not be allowed for the Primary key column.

Test Scenarios for Image Upload Functionality

(Also applicable for other file upload functionality)
1. Check for uploaded image path.
2. Check image upload and change functionality.
3. Check image upload functionality with image files of different extensions (e.g. JPEG, PNG, BMP etc.)
4. Check image upload functionality with images having space or any other allowed special character in the file name.
5. Check duplicate name image upload.
6. Check image upload with image size greater than the max allowed size. The Proper error message should be displayed.
7. Check image upload functionality with file types other than images (e.g. txt, doc, pdf, exe etc.). A proper error message should be displayed.
8. Check if images of specified height and width (if defined) are accepted otherwise rejected.
9. The image upload progress bar should appear for large size images.
10. Check if cancel button functionality is working in between upload process.
11. Check if file selection dialog shows only supported files listed.
12. Check multiple images upload functionality.
13. Check image quality after upload. Image quality should not be changed after upload.
14. Check if the user is able to use/view the uploaded images.

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 to 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 to send email functionality to single, multiple or distribution list recipients.
16. Check if a reply to email address is correct.
17. Check to send the high volume of emails.

Test Scenarios for Excel Export Functionality

1. The file should get exported in the proper file extension.
2. The file name for the exported Excel file should be as per the standards e.g. if the file name is using the timestamp, it should get replaced properly with an actual timestamp at the time of exporting the file.
3. Check for date format if exported Excel file contains the date columns.
4. Check number formatting for numeric or currency values. Formatting should be the same as shown on the page.
5. The exported file should have columns with proper column names.
6. Default page sorting should be carried in the exported file as well.
7. Excel file data should be formatted properly with header and footer text, date, page numbers etc. values for all pages.
8. Check if the data displayed on a page and exported Excel file is the same.
9. Check export functionality when pagination is enabled.
10. Check if the export button is showing proper icon according to the exported file type E.g. Excel file icon for xls files
11. Check export functionality for files with a very large size.
12. Check export functionality for pages containing special characters. Check if these special characters are exported properly in the Excel file.

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.

Security Testing Test Scenarios

1. Check for SQL injection attacks.
2. Secure pages should use the 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.

Penetration testing test cases – I’ve listed around 41 test cases for penetration testing on this page.

I ‘d really like to thank Devanshu Lavaniya (Sr. QA Engineer working for I-link Infosoft) for helping me to prepare this comprehensive testing checklist.

I’ve tried to cover almost all standard test scenarios for web and desktop application functionality. But still, I know that this is not a complete checklist. Testers on different projects have their own testing checklist based on their experience.

*************************************************

Updated:

100+ Ready-to-Execute Test Cases (Checklists)

You Can Use this list to test the most common components of AUT

How to test the most common components of your AUT effectively, every single time

This article is a list of common validations on most widely found elements of AUT – that is put together for the convenience of testers (especially in the agile environment where frequent short-term releases happen).

Every AUT (Application Under Test) is unique and has a very specific business purpose. The individual aspects (modules) of the AUT cater to different operations/actions that are crucial to the success of the business that the AUT supports. Though each AUT is designed differently, individual components/fields that we encounter on most pages/screens/applications are the same with more or less similar behavior.

ready test cases

Some Common Components of AUT:

  • Save, Update, Delete, Reset, Cancel, OK – links/buttons- whose functionality is the label of the object indicates.
  • Text box, dropdowns, checkboxes, radio buttons, date control fields – that work the same way every time.
  • Data grids, impacted areas, etc. to facilitate reports.

The way these individual elements contribute to the overall functionality of the application might be different but the steps to validate them are always the same.

Let’s continue with the list of most common validations for web or desktop application pages/forms.

Note: The actual result, expected result, test data and other parameters that are typically a part of a test case are omitted for the sake of simplicity – A general checklist approach is employed.

Purpose of this comprehensive checklist:

The primary purpose of these checklists (or test cases) is to ensure maximum test coverage on field level validations without spending too much time, at the same time not compromise the quality of testing them.

After all, confidence in a product can only be attained by testing every single element to the best extent possible.

The Complete Checklist (Test Cases) for Most Common Components of AUT

Note: You can use these checklists as it is in Microsoft Excel format (download provided at the end of the article). You can even track the test execution in the same file with pass/fail result and status.

This could be an all-in-one resource for QA teams to test and track the most common components of AUT.  You can add or update test cases specific to your application and make it even more comprehensive list.

Checklist #1: Mobile Testing Checklist

Module Name:
Module Functionality:
Module Impact over the application:
Module Flow:
Menu & Submenu:
Spellings and Order & Suitability:
Control for each submenu:

Checklist #2: Forms/Screens Testing Checklist

Form Functionality:
Form Impact over the application:
Form Flow:
Designing:
Alignments:
Title:
Field Names:
Spellings:
Mandatory Marks:
Alerts to Mandatory fields:
Buttons:
Default Cursor Position:
Tab Sequence:
The page before entering any data:
Page after entering data:

Checklist #3: Textbox Field Testing Checklist

Text Box:

ADD (In add screen)EDIT (in Edit screen)
Characters
Special Characters
Numbers
Limit
Alert
Spelling & Grammar in Alert message:

BVA (Size) for Text Box:

Min —>—> Pass
Min-1 —> —> Fail
Min+1 —> —> Pass
Max-1 —> —> Pass
Max+1 —> —> Fail
Max —> —> Pass

ECP for Text Box:

Valid In Valid
 – –
 – –

Checklist #4: List-box or Drop-down List Testing Checklist

List Box/Dropdown:

ADD (In add screen)EDIT (in Edit screen)
Header
The correctness of Existed Data
Order of Data
Selection and Deselection
Alert:
Spelling and Grammar of Alert message 
Cursor after alert
Reflection of Selection and Deselection in remaining fields

Checklist #5: Checkbox Field Testing Checklist

Check Box:

ADD (In add screen)EDIT (in Edit screen)
Default Selection
Action after selection
Action after de-selection
Selection and Deselection
Alert:
Spelling and Grammar of Alert message 
Cursor after alert
Reflection of Selection and Deselection in remaining fields

Checklist #6: Radio Button Testing Checklist

Radio button:

ADD (In add screen)EDIT (in Edit screen)
Default Selection
Action after selection
Action after de-selection
Selection and Deselection
Alert:
Spelling and Grammar of Alert message 
Cursor after alert
Reflection of Selection and Deselection in remaining fields

Checklist #7: Date Field Test Scenarios

Date field:

ADD (In add screen)EDIT (in Edit screen)
Default date display
Design of calendar
Navigation for different months and years in date control
Manual Entry in date text box
Date format and uniformity with the overall application
Alert:
Spelling and Grammar of Alert message 
Cursor after alert
Reflection of Selection and Deselection in remaining fields

 

Checklist #8: Save Button Testing Scenarios

Save/update:

ADD (In add screen)EDIT (in Edit screen)
Without giving any data:
With only mandatory fields:
With All fields:
With Max limit:
With min limit
Spelling & Grammar in Confirmation  Alert message:
Cursor
Duplication of Unique fields:
Spelling & Grammar in duplication Alert message:
Cursor

Checklist #9: Cancel Button Test Scenarios

Cancel:

With data in all fields
With only mandatory fields:
With all fields:

Checklist #10: Delete Button Testing Points

Delete:

EDIT (in Edit screen)
Delete the record which is not used anywhere in the application
Delete the record which has a dependency
Add the new record with same deleted details again

Checklist #11: To Verify Impacted Areas after Save or Update

After Saving/updating:

Display in View
Reflection in impacted forms in the application

Checklist #12: Data Grid Testing List

Data Grid:

Grid Title and spelling
Form Before giving any data
Message Before giving any data
Spellings
Alignments
S No
Field Names & Order
The correctness of Existed data
Order of Existed data
Alignment of Existed data
Page navigators
Data when navigating with different pages

Edit Link Functionality

Page after Edit:
Title and spellings
Existed data of the Selected record in each field
Buttons

While this list might not be exhaustive, it is indeed extensive.

DOWNLOAD ==> You can download all these checklists in MS Excel format: Download in Excel format

Points to note:

  1. Depending on your need, additional tests under each category/for each field can be added or existing fields can be removed. In other words, these lists are completely customizable.
  2. When in need to include field level validations to your test suites, all you have to do is pick up the respective list and use it for the screen/page that you would like to test.
  3. Maintain the checklist by updating the pass/fail status to make this a one-stop-shop for listing features, validating them and recording the test results.

Please feel free to make this a complete checklist by adding more test cases/scenarios or negative test cases in the comments section below.

Also, I’d appreciate if you’d share this with your friends!

PREV Tutorial | NEXT Tutorial

350 Comments on “180+ Web Application Testing Example Test Cases (Sample Checklist)

  1. Can some help me by giving the list of testcases for “Load Balancer” testing.

  2. Good Article

  3. good article

  4. need some more info on security testing

  5. Wow This is called perfection . What an Article, so comprehensive.

  6. It’s an excellent checklist for the developers also.

    Every developer should keep this list in mind and test these cases themselves while developing the project which can also reduce so many QA hours.

    Thanks for sharing.. keep it up.

  7. Very good article…. Thanks.

    Can anyone pls forward me sample test case document of any application.
    lalitpatel75mca@gmail.com
    My mail-id

  8. thnaks you very much very good article

  9. Excellent Help for tester

  10. Great work.. Keep it up. God bless you.

  11. i need a sample website test case plzzzzzz help me friends

  12. 1. Check if correct data is getting saved in database upon successful page submit
    2. Check values for columns which are not accepting null values
    3. Check for data integrity. Data should be stored in single or multiple tables based on design
    4. Index names should be given as per the standards e.g. IND__
    5. Tables should have primary key column
    6. Table columns should have description information available (except for audit columns like created date, created by etc.)
    7. For every database add/update operation log should be added
    8. Required table indexes should be created
    9. Check if data is committed to database only when the operation is successfully completed
    10. Data should be rolled back in case of failed transactions
    11. Database name should be given as per the application type i.e. test, UAT, sandbox, live (though this is not a standard it is helpful for database maintenance)
    12. Database logical names should be given according to database name (again this is not standard but helpful for DB maintenance)
    13. Stored procedures should not be named with prefix “sp_”
    14. Check is values for table audit columns (like createddate, createdby, updatedate, updatedby, isdeleted, deleteddate, deletedby etc.) are populated properly
    15. Check if input data is not truncated while saving. Field length shown to user on page and in database schema should be same
    16. Check numeric fields with minimum, maximum, and float values
    17. Check numeric fields with negative values (for both acceptance and non-acceptance)
    18. Check if radio button and dropdown list options are saved correctly in database
    19. Check if database fields are designed with correct data type and data length
    20. Check if all table constraints like Primary key, Foreign key etc. are implemented correctly
    21. Test stored procedures and triggers with sample input data
    22. Input field leading and trailing spaces should be truncated before committing data to database
    23. Null values should not be allowed for Primary key column

    Test Scenarios for Image Upload Functionality

    (Also applicable for other file upload functionality)
    1. Check for uploaded image path
    2. Check image upload and change functionality
    3. Check image upload functionality with image files of different extensions (e.g. JPEG, PNG, BMP etc.)
    4. Check image upload functionality with images having space or any other allowed special character in file name
    5. Check duplicate name image upload
    6. Check image upload with image size greater than the max allowed size. Proper error message should be displayed.
    7. Check image upload functionality with file types other than images (e.g. txt, doc, pdf, exe etc.). Proper error message should be displayed
    8. Check if images of specified height and width (if defined) are accepted otherwise rejected
    9. Image upload progress bar should appear for large size images
    10. Check if cancel button functionality is working in between upload process
    11. Check if file selection dialog shows only supported files listed
    12. Check multiple images upload functionality
    13. Check image quality after upload. Image quality should not be changed after upload
    14. Check if user is able to use/view the uploaded images

    Test Scenarios for Sending Emails

    (Test cases for composing or validating emails are not included)
    (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 email body template should be handled properly
    4. Language specific characters (e.g. Russian, Chinese or German language characters) should be handled properly in email body template
    5. Email subject should not be blank
    6. Placeholder fields used in email template should be replaced with actual values e.g. {Firstname} {Lastname} should be replaced with individuals first and last name properly for all recipients
    7. If reports with dynamic values are included in email body, 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 reply to email address is correct
    17. Check sending high volume of emails

    Test Scenarios for Excel Export Functionality

    1. File should get exported in proper file extension
    2. File name for the exported Excel file should be as per the standards e.g. if file name is using timestamp, it should get replaced properly with actual timestamp at the time of exporting the file
    3. Check for date format if exported Excel file contains date columns
    4. Check number formatting for numeric or currency values. Formatting should be same as shown on page
    5. Exported file should have columns with proper column names
    6. Default page sorting should be carried in exported file as well
    7. Excel file data should be formatted properly with header and footer text, date, page numbers etc. values for all pages
    8. Check if data displayed on page and exported Excel file is same
    9. Check export functionality when pagination is enabled
    10. Check if export button is showing proper icon according to exported file type e.g. Excel file icon for xls files
    11. Check export functionality for files with very large size
    12. Check export functionality for pages containing special characters. Check if these special characters are exported properly in Excel file

    Performance Testing Test Scenarios

    1. Check if page load time is within acceptable range
    2. Check page load on slow connections
    3. Check response time for any action under light, normal, moderate and heavy load conditions
    4. Check performance of database stored procedures and triggers
    5. Check database query execution time
    6. Check for load testing of application
    7. Check for stress testing of application
    8. Check CPU and memory usage under peak load condition

    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 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 secured channel
    13. 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 browser address bar
    17. Test file extension handing so that exe files are not uploaded and executed on server
    18. Sensitive fields like passwords and credit card information should not have auto complete 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 new password
    23. Verify CAPTCHA functionality
    24. Check if important events are logged in log files
    25. Check if access privileges are implemented correctly
    Penetration testing test cases – I’ve listed around 41 test cases for penetration testing on this page.

    I ‘d really like to thank Devanshu Lavaniya (Sr. QA Engineer working for I-link Infosoft) for helping me to prepare this comprehensive testing checklist.

    I’ve tried to cover all standard test scenarios for web and desktop application functionality. But still I know this is not a compete checklist. Testers on different projects have their own testing checklist based on their experience.

  13. its very useful…
    thank u..

  14. it was really very helpful..

    in this comment section asterisk(*) is missing to display mandatory fields.

  15. ekch no bhava. fkt ans pahij hote. very very useful.

  16. very useful information thanks a lot Vijayji

  17. Thanks for sharing, it’s very helpful :)

  18. Awesome list.

    Some points that could be added based on recent demands from the client could be – Test cases on Social sharing icons, Coupon codes, SMS, Ecommerce websites, Video uploads.

  19. useful informations.Thanks
    But ‘tab index’ testing missing.

  20. very helpfull article..thank you soo much :)

  21. Thanks a lot!

  22. Thanks for your contribution..

  23. Thanks for sharing
    Very useful test cases

  24. good job, bro!
    needed to test my site and decided to turn to professionals at first, but they were a total disaster. Found others (QAwerk), these were much better, but still i wasn’t completely satisfied. hope you don’t mind sending them your list.

  25. sir, send me the test cases for big basket but only for critical functionality

  26. There is a simple program with the following items: Input Box A Input Box B Add button Result Text Box [=A+B] Identify all the test cases for the program. [Example: press the Add button without entering anything in Input Box A and B]

    kindly answer this question plz

  27. Very useful checklist.

    thanks for sharing with us ..

  28. Its very helpful. Lately I’ve found it. Thanks.

  29. Hello sir , can you explain the test cases for the scrolling

  30. Your page is really a good one. It really helps in every way for a tester.Very Nice work.Well done.Keep coming up with new information to help us.
    Thank you.

  31. Thanks for sharing, it’s very helpful

  32. Very well explained and i can say it covers maximum scenarios. thanks for providing really a good information. will help a lot for me.

  33. Can any one provide some basic security testing scenarios with examples where we can execute them directly on web application?

  34. Thanks for sharing, it’s very helpful

  35. Excellent data

  36. Thanks a lot Vijay….you are really doing a great job to help us in a very gud way..Very nice and informative article..covering maximum scenario.

  37. Very useful for freshers , looking forward for the next articles from u

  38. Could anyone help me with Test cases for Algorithm?

  39. Please also write checklist for mobile application test

  40. I have question ZAP Security testing:
    Do we need to run ZAP on admin section also. We normally run ZAP on frontend part of website.

  41. Very Nic Document

  42. Very useful document..Thank you

  43. I need the test cases for Document generator

    example – A group policy is been created and the final bill to be generated in pdf format. how the test cases would be.

  44. Very nice and helpful

  45. very useful. Thank You!!!

Leave a Comment