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

By Vijay

By Vijay

I'm Vijay, and I've been working on this blog for the past 20+ years! I’ve been in the IT industry for more than 20 years now. I completed my graduation in B.E. Computer Science from a reputed Pune university and then started my career in…

Learn about our editorial policies.
Updated November 6, 2024

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 this post updated 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.

Sample web application test cases and scenarios

Make a 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.

These are all general test cases and should be applicable to almost all kinds of applications. Refer to 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.

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


Importance of Using a Checklist for Testing

#1) Maintaining a standard repository of reusable test cases for your application will ensure that the 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 helps 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 users, guest users, 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 applications 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 and in the correct position.
3. All error messages should be displayed in the same CSS style (For Example, using red color)
4. General confirmation messages should be displayed using CSS style other than error message style (For Example, 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 the 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 the 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 the 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., the field accepting the 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 the operation timeout.
18. Check the cookies used in the application.
19. Check if the downloadable files are pointing to the correct file path.
20. All resource keys should be configurable in config files or databases instead of hard coding.
21. Standard conventions should be followed throughout for naming resource keys.
22. Validate markups for all web pages (validate HTML and CSS for syntax errors) to make sure they are compliant with the standards.
23. Application crashes or unavailable pages should be redirected to the error page.
24. Check the text on all pages for spelling and grammatical errors.
25. Check numeric input fields with character input values. A proper validation message should appear.
26. Check for negative numbers if allowed for numeric fields.
27. Check the number of fields with decimal number values.
28. Check the functionality of buttons available on all pages.
29. The user should not be able to submit a page twice by pressing the 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 the page (For Example, 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. The 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 clicking on the input text field, the mouse arrow pointer should get changed to the cursor.
9. The user should not be able to type in the drop-down select list.
10. Information filled out by users should remain intact when there is an error message on the page submitted. The user should be able to submit the form again by correcting the errors.
11. Check if proper field labels are being 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 limits.
18. All buttons on the page should be accessible with 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 updates or deleting operations.
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, then make sure that the 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 be used to query results.
5. Proper validation messages should be displayed for all invalid values for filter criteria.

Test Scenarios for Result Grid

1. The page loading symbol should be displayed when it’s taking longer than the default time to load the results 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 the default column.
6. Sorted columns should be displayed with a sort icon.
7. Result grids should include all the specified columns with the 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 results grid.
13. Check if all the columns are visible and a 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 the ‘Totals’ row and verify the total for every column.
16. For result grids showing reports, check the ‘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 see if the date range is enabled.

Test Scenarios for a Window

1. Check if the default window size is correct.
2. Check if the 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 upon closing the 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 the window to minimize, maximize, and close functionality.
7. Check if the window is re-sizable.
8. Check the scroll bar functionality for parent and child windows.
9. Check the cancel button functionality for the child window.

Database Testing Test Scenarios

1. Check if the correct data is getting saved in the database upon a successful page submit.
2. Check values for columns that 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 logs 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. The field length shown to the user on the page and in the 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 the 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 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 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 the uploaded image path.
2. Check image upload and change functionality.
3. Check image upload functionality with image files of different extensions (For Example, JPEG, PNG, BMP, etc.)
4. Check image upload functionality with images that have space or any other allowed special character in the file name.
5. Check for duplicate name image upload.
6. Check the image upload with an image size greater than the max allowed size. Proper error messages should be displayed.
7. Check image upload functionality with file types other than images (For Example, 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 or otherwise rejected.
9. The image upload progress bar should appear for large size images.
10. Check if the cancel button functionality is working in between the upload process.
11. Check if the file selection dialog only shows the supported files listed.
12. Check the 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. The 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 (For Example, Russian, Chinese or German language characters) should be handled properly in the email body template.
5. The 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 an individual’s first and last name properly for all recipients.
7. If reports with dynamic values are included in the email body, report data should be calculated correctly.
8. The email sender’s name should not be blank.
9. Emails should be checked by 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 the email header and footer for the 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 the reply to the 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 with the proper file extension.
2. The file name for the exported Excel file should be as per the standards, For Example, 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 the exported Excel file contains the date columns.
4. Check the 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 out 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 the page and exported Excel file is the same.
9. Check export functionality when pagination is enabled.
10. Check if the export button is showing the proper icon according to the exported file type, For Example, 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 the Excel file.

Performance Testing Test Scenarios

1. Check if the page load time is within the acceptable range.
2. Check if the page loads on slow connections.
3. Check the response time for any action under light, normal, moderate, and heavy load conditions.
4. Check the 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 conditions.

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. The 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 to an encrypted channel.
7. Test password security and password policy enforcement.
8. Check the 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 handling so that exe files are not uploaded or executed on the server.
18. Sensitive fields like passwords and credit card information should not have to be 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. Passwords 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 questions are 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. I still 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 do you test the most common components of your AUT effectively, every single time?

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

Each 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 the most common validations for Web or Desktop application pages/forms.

Note: The actual results, expected results, 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, and 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.

A Complete Checklist (Test Cases) For Most Common Components Of AUT

Note: You can use these checklists as they are 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 results 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 to make it an 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

CheckBox:

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 the same deleted details again

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

After Savings/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 needs, 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 of including field-level validations for your test suites, all you have to do is pick 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 it if you’d share this with your friends!

PREV Tutorial | NEXT Tutorial

Was this helpful?

Thanks for your feedback!

Recommended Reading

  • How to Write Test Cases: The Ultimate Guide with Examples

    Writing effective test cases is a skill and that can be achieved by some experience and in-depth study of the application on which test cases are being written. Here I will share some tips on how to write test cases, test case procedures and some basic test case definitions.

  • Sample Test Case Template

    Every day I keep on getting several requests for a Test Case Template. I'm surprised that many testers are still documenting test cases with Word docs or Excel files. Most of them prefer excel spreadsheets because they can easily group test cases by test types and most importantly they can…

  • WEBSITE COOKIE TESTING

    Introduction to Cookies Primarily we will focus on what exactly HTTP cookies or Internet cookies are and how they work. It would be easy for you to understand the test cases for testing website cookies when you have a clear understanding of how cookies work, how cookies get stored on…

  • ISTQB Testing Certification Sample Question Papers With Answers

    If you are preparing for the ISTQB Foundation Level certification exam then here are some sample question papers to make your preparation a little easier. Each ISTQB mock test contains 40 questions and answers are provided at the end of the page. Mark all the answers on a separate paper…

  • Compliance Testing

    Definition - What is Compliance Testing? "Compliance testing" also known as Conformance testing is non-functional. testing technique which is done to validate, whether the system developed meets the organization’s prescribed standards or not. There is a separate category of testing known as “Non-Functional Testing”. Nonfunctional testing, as the name suggests,…

  • Testing from Eclipse

    Upload and install your mobile application on any device to kick off your Appium testing directly from Eclipse: Your mobile applications can be managed within the Eclipse through a dedicated Application Pane in Appium Studio for Eclipse. Your application can quickly and easily be uploaded and launched on any device. This…

  • Application Testing

    Introduction to Application Testing Application Testing is an activity that is performed frequently by almost every software tester in his career. These two words are extremely broad in practical aspects. However, only the core and most important areas will be discussed here. The purpose of this tutorial is to touch…

  • TDD-BDD

    This Tutorial Explains The Differences Between TDD vs BDD With Examples: TDD or Test Driven Development and BDD or Behavior Driven Development are the two software development techniques. Before we dive deeper into the difference between these two, let us first understand what do they mean individually and how are…


402 thoughts on “180+ Web Application Testing Example Test Cases (Sample Checklist)”

  1. sir, it is very knowlegable with easy language, it is so easy to understand all the test cases functionalities.it will definetly help me in making my project with gud n effective test cases..thanku so much sir..keep going ..all d best.

    Reply
    • There are two types of forms for adding and updating the products or others. When adding new data Add form will show up and to update existing data Edit Form will show up.

      Reply
  2. 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.

    Reply
  3. Great article, well done. But someting I just wonder:
    1) How to test memory leaks
    2) Please tell me how I create a file with virus to test file attachment without spreading virus to my PC
    3) Tester can not tell developer that they have to create audit tables in the databse. Audit requires in audit_log.
    4) Tester can not require that table indexes are created.

    Reply
  4. In General Test Scenarios:
    While testing filed for special character also test for reserved keywords like:
    ‘Create’, ‘Update’… etc

    Reply
  5. This is really helpful article for every tester. It reminds me the mistakes I made in the past. Thanks to the authors of the article.
    I will keep this checklist handy while working on each project hereafter.

    Reply
  6. thank you everyone for your help!

    it takes anywhere between 10 and 20 hours to complete these kind of articles. but this wouldn’t have been possible without your support, which inspires me to put in these efforts.

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

    Reply
  8. Great Stuff – It’s a pretty good overview although not everything will work for every project. Nevertheless it’s a good start and a brilliant checklist.

    Reply
  9. please giude me, how can i write testcases for non-functional testing like performance testing,load testing stress testing??

    Reply
  10. Great checklist. We have developed a website testing tool and are now in the process of adding support for testing checklists. Ill make sure your checklists can be used within our Webseam tool.

    Reply
  11. Can any1 help me writing a negative testcase for a desktop application for scenario:
    server fumctionality is to send notification to manager system when ever a desktop application is opened but in my test case server should not send notifications if other than that particular desktop application is opened

    Reply
  12. 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

    Reply
  13. VERY USEFUL INFORMATION FOR FRESHERS TO FACE INTERVIEW QUESTIONS ON TEST CASES..
    GOOD WORK…
    THANKS ALOT..

    Reply
  14. Hi a very good article helped me alot.Can u also kindly tell us with an example how do we write test cases based on document

    Reply
  15. Thank you for sharing the information with us. All the scenarios are compiled well and are very informative. I would also like to suggest the mobile app testing tools provided by pCloudy. Their tools are comprehensive and are effective. I tested my apps, could identify bugs easily with their tools and even fix it in minutes. This is helpful for all the mobile app developers to test their apps .

    Reply
  16. Hi,
    These articles are very informative & useul. Thanks a lot. Can you please give more idea how to test live chat application.

    Thanks

    Reply
  17. very useful.. and helpful… a ery good effort done by u…
    thanks…
    kindly post a article on negative testing test case….

    Reply
  18. Can anyone suggest a demo site to practice manual testing which has the test scenarios and cases mentioned.
    Thanks

    Reply
  19. 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.

    Reply
  20. This is very very informative and knowledgable…
    Thanks for sharing this with us…
    This is a nobel task for many testers… you will get blessings from those testres…

    I had few doubts that, can you please send the same kind of list for ETL and Database testing???
    rest is fine…

    thanks once again…

    Reply
  21. hi vijay sir,
    great artical to learn and am manual tester i want to learn automation selenium webdriver tool using java language please drop an a dummy project of the Automation testing please vijay sir if send dummy project it would be more useful for me and my career.

    Thanks

    Reply
  22. I want to know what are the SIT test cases for e commerce website. My managers say these are unit testing test cases and not SIT test cases.

    Reply
  23. Hi Vijay,

    Your article is very helpful and easily understandable..

    I have a doubt. What is the difference b/w Integration Testing, System Integration Testing? or both r same?
    Kindly revert back to my mail.. I am totally confused with these terms…

    Reply
  24. for the first time im learning s/w testing…and this article is really a gud start for me…thanks a lot…hope u make many more articles…

    Reply
  25. Great list of scenarios, however I believe they wont work for all applications. But this can be a good basis for everybody to create their own check lists

    Reply
  26. Hi. Example I have Group Setup, Company Setup and Department Setup which is in different window (have their own set of add/update/delete button), and all this have few field is mandatory field. How should I create the test cases? Should I create three set for each Setup? Or I just create one test cases?

    Reply
  27. Thanks, this is a very useful list, especially for projects that dont have a dedicated test team. I found a few I have missed so very useful.

    Reply
  28. Thanks, this is a very useful list, especially for projects that dont have a dedicated test team. I found a few I have missed so very useful.

    many thanks

    Reply
  29. Test Scenario 1: Check windows maximize, minimize and close functionality
     
    Test Scenario 2: Check if the window is re-sizeable
     
    Test Scenario 3: Check for image upload functionality
     
    Test Scenario 4: Check for uploaded image path
     
    Test Scenario 5: Check image upload with image size greater than the max allowed size. The Proper error message should be displayed.
     
    Test Scenario 6: Check image upload functionality with file types other than images (e.g. txt, doc, pdf, exe etc.). A Proper error message should be displayed.
     
    Test Scenario 7: Email addresses should be validated before sending emails.
     
    Test Scenario 8:  Check emails with attachments.
     
    Test Scenario 9: Email subject should not be blank.

    PLEASE solve it
    – test case id
    – test case
    -test case name
    -input data
    -expected output

    Reply
  30. Can you point me to any test plan for web content filtering solutions. We are trying to decide between a couple off shelf web content filters and I wish to avoid skipping a common Use-Case. We are a K12 school but corp test plans would be good too?

    Reply
  31. HI , ITS GREAT SITE , I DID SOME QA MANUAL TESTING COURSE , . NOW WANT SOME PROJECTS FOR PRACTICE – HOW TO WRITE TEST CASES ETC

    Reply
  32. hai friends iam new to this group i completed my coaching in manual and qtp testing , but i have fear what are the question may asked by the interviewer in manual and qtp it’s easy are hard to face and an interview plz send related questions asked by interview in manual and qtp

    Reply
  33. Test Cases:

    1. Text entry possible in Menu Item(corresponding item is searched in drop down list), Hours, Minutes, AM/PM. Correctness checked when focus shifts to other field.

    2. Menu item has a drop down and Hours, Minutes have increment and decrement controls

    Reply
  34. Very usefull thanks very much it helped me a lot for writting the test cases.

    If you have any document related to it can you please send mail.

    Thanks.

    Reply
  35. 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.

    Reply
  36. @Boris – General, security, performance, GUI, DB tests should be applicable for almost all applications.
    As mentioned in the assumptions, other tests are applicable for applications containing forms to save data in DB, file upload functionality, having popup windows, search and result pages, data export functionality etc.

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

    Reply
  38. Hi Ajeeth,

    These points are very good. Thank you so much.
    Could you please send me testing checklist regarding e-commerce website. I really need it.
    Thanks again!

    Reply
  39. Thanks a lot for such awesome check list… I have learnt a lot from your website.
    There is a bug which i found on this page under “Few notes to remember:” u have used numbering ‘4 ‘ twice.

    Reply
  40. very good sample test case template. Anyone wanting to take Software Testing to another level can buy exam papers @ ISEB-sofwaretesting.weebly.com

    Reply
  41. Hi Techies, Please anyone share or send me the system test cases for any of the web application.. Please even share any testing related documents.. I am new to testing .. Please..

    Reply
  42. Check if application loads Schedule screen successfully and default required data is shown on screen, Please tell me how to write test cases for above.

    Reply
  43. This Information is Very useful for QA or Non-QA Professional.they can easily understand all these points.Developer’s can also Read these Point and aware regarding such kind of issues.

    Reply
  44. Thank you !! I just want to notify that I have more than 2 years of experience in Software testing and all of these because of you Software Testing help!! Great work and nice article !!!

    Reply
  45. Hello,
    i’m in testing team now, i konw about testing and why its needs but i don’t know how to write and differences to understand. so it very new for me but after reading it’s really helpful for me. Thank you for everthing.

    Reply
  46. Its a very fantastic stuff for testing team. These test checklist will help to improve the better quality in websites.
    Could you please send me testing checklist regarding e-commerce websites.
    Thanks Again!

    Reply
  47. Hi Tejeshwar Jaiswal,

    I don’t have any written check list with me I just read the above check list I found that these are missed so i written missed points here..If i get any check list I will definitely forward to you drop your email id here…

    Thanks.

    Reply
  48. Hi, i need to know how to write a test case for admiral insurance multi cover.. test case on how to navigate through the pages.

    Reply
  49. Hi,
    All the test cases that you posted are very helpful. Could you please post test cases for Clinical Trials in Pharmaceutical domain. I need it please.

    Thanks,
    Sripadma

    Reply
  50. I need test scenarios/ test cases for subscription manager for a product,which contains active/inactive status and renewal status with some specific time and date

    Please help if anyone know

    Reply
  51. Hi Vijay,

    Here are the few points you can add to the above check list

    1.Upon placing mouse on button or Link, Mouse arrow should get changed to hand icon.
    2.Links should have underline or should differentiate with normal text, the user easily identify the link on webpage.
    3.Website copyright year should updated with current year.
    4.Buttons and links should get highlight when placing cursor on it.
    5.Date pickers should be displayed for Date fields.
    6.User should only able to select valid dates (ex: Feb 31st cant be selected)
    7.If Date of birth must be 18, then user should not be able to select date less than 18 years from the current date.
    8.If something is not available which is requested by user, it should display proper confirmation text.
    9.If main window closed all it’s child tables should get closed.
    10.User should be able to navigate directly home page from any page through Home link

    Regards,
    Ajeeth.A

    Reply
  52. I have started following this site and I believe it is really wonderful for beginner like me..very very comprehensive and very well explained Vijay !!

    Reply
  53. Hi
    really this is very helpfull for me. I have some query about the security testing. Can you describe alittle bit about
    a) Deniel of service attack
    b) Brute Force Attacks
    c) Memory Leakage

    Reply
  54. hi vijay
    First of all thanks for this post .this is very useful for learner as well as fresher student this is a out standing post posted by your side

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

    Reply
  56. HI Mr. Vijay,
    I really appreciate ur effort. Your website and the content is unparallel. Is there any way for me to reach you over phone for now.
    Gautam
    001-864-643-8782

    Reply
  57. This Check list is very useful these is one of the test case sample models. i would like to extra check list our added.
    ………really very nice……….

    Reply
  58. Hi

    i am going to work on e commerce website can you send me data which will help me to test e commerce website plz.

    you are doing good job keep it going on.

    Reply
  59. This is a good basic checklist but no where do you mention testing the functional purpose of the page. For example in Amazon, it could be to search for, select and buy a product, in people soft, it would be to import a contact from email, edit their details and save the entry. Checking the layout and the uniform behaviour of text fields is all very well and good but of you cannot carry out the functional purpose of the web page / app then it is of no use to no-one.

    Reply
  60. These scenario’s are really too good. I have recently been interviewed for few companies where i was asked to provide some scenario’s for basic application model. By reading this article, it opened a thought for me to answer those questions. These are the very best scenario’s that i ever read in any portal.

    Thanks Vijay, for posting them all together.

    Reply
  61. 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.

    Reply
  62. 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.

    Reply
  63. if u have any test case templates then mail me and pls let me know what r the tools available in market as track versions i need to be install for automation testing
    thank u **********

    Reply
  64. hi, can you please help me with test scenarios for Directory of healthcare provider application(searching for providers)
    thanks.

    Reply
  65. how should we write test case in a template while we r clicking on menus the image at the top should not be change

    Reply
  66. Thank you.. I’ve been writing test cases for new web site development for a few years.. started searching today for new, more comprehensive information on cases. This will be helpful.

    Reply
  67. The developers in my office use to dismiss my test cases. But after reading this document, I feel empowered to face them

    Reply
  68. Vijay, this is by far the most comprehensive test cases list I ever seen in any other online articles.
    Thanks for compiling and sharing with us.

    Reply
  69. Hi, I am new in software testing . Can you clear me the difference between front end and back end testing?
    Thanks in advance

    Reply
  70. It’s nice explanation to learn more about test cases preparation and more helpful for software testing freshers like me . thank you so much.

    Reply
  71. Hi admin,

    Iam a new tester. This document is so great to understand how to do the testing for web page.

    Could you please help to send full check list to me via mail?

    Thanks so much 🙂

    Reply
  72. Awesome Article. Very very important for Manual Testers .
    Please don’t miss even a single point in this Article…. Thanks for this…

    Reply
  73. Hi,

    We can consider the below point as well in the section of “Test Scenarios for Excel Export Functionality”

    Check whether there is any sheet has been hidden in the exported excel sheet

    Reply
  74. Thank u so much boss,….it helped me alot to write scenarios for my application,..n i vl b looking forward for ur next articles.

    Reply
  75. Dear Vijay ji,

    your artical is very helpful for the beginners, but you know what i didn’t do any course of testing but still i utilize all the test cases which is mention by you in the manual or performance testing by my own.

    But my company never ever appreciate my efforts of testing his software. they are telling that the testers are the useless fellow of the company.

    Actually i make a standard product for him, but still they give less value to a experience tester in comparison to the fresher programmer.

    sorry for writing this but it release my anger & frustration on that kind of fellows.

    thanks

    Reply
  76. Awesome help..i am fresher and was asked to prepare the test cases…yours came handy..dont know if it would be approved but still my personal opinion ..its real good.

    Reply
  77. This data was really helpful for my testing, thanks for that and I am in need of data privacy (GDPR) related test cases both web and mobile application. Can you guys provide any sample test scenarios ?

    Reply
  78. Thanks for Sharing such a wonderful article. The contains are very good and scenarios are good described. Keep posting such articles. This is really helpful for the people related to Software Testing industry.

    Reply
  79. great work , you posted a nice article for all the people who wants enter into the testing field thank you allot for sharing this information with us waiting for the upcoming articals…….

    Reply
  80. Vijay, this is by far the most comprehensive test cases list I ever seen in any other online articles.
    Thanks for compiling and sharing with us.

    Reply
  81. Thank u Vijay for giving such a good senarios on desktop and web app testing which usefull more for who are working under these testings.

    Reply
  82. What kind of testing is there which can be done for Desktop applications but not for web based applications?please give me in details

    Reply
  83. Thanks a lot Vijayji, These scenarios are very useful while Testing application for software testing professional as well as a fresher while facing testing interview questions..

    Reply
  84. its an excellent checklist for beginners.i have recently joined as tester wanted some tips to create efficient test cases for desktop application its an financial software. looking for help pls revert back 🙂

    jamuna.avera@gmail.com

    Reply
  85. Hi Vijay,

    Am really thankful for providing detailed info.. as i joined small s/w company.. and am being so confused, what to do first, and how to test…

    Thank u once again

    Reply
  86. i cant able to understand this line..? could you help me plz to understand..?

    “All resource keys should be configurable in config files or database instead of hard coding”

    Reply
  87. I have a question about upload functionality of xls files to android specifically. Are there any limitations that android cannot handle xls files uploads/downloads and what test cases on top of typical functionality (size, format, gui, and the other ones listed in this thread) can anyone recommend

    Reply
  88. Very informative Article.
    Above list is very useful for all Web Testing Scenarios.

    Thanks for sharing ,Such a great effort.

    Please add some test cases for client Server Apps.

    Reply
  89. This is excellent Vijay. You have made work a bit easier for us. I dont know, how much and when it will be possible, but would be excellent to have such detailed explanation for other areas like QTP, QC, etc.

    Thanks again!!

    Reply
  90. Does anyone have an idea of what a resource key is? I’ve looked all over and can’t seem to find a clear definition of it. Trying to understand this statement: “All resource keys should be configurable in config files or database instead of hard coding.”

    Reply
  91. 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.

    Reply
  92. I need test cases for a testing website and the test cases to cover only UI testing, Functionality testing and Usability testing.

    Thanks!!!

    Reply
  93. Greate and helpful article

    Thank you vijay for post this article for testing desktop application. Thanks for your efforts. Its very useful for me.

    Reply
  94. Hi All,

    I am student could any help me in my below question. This is my project… Please help me in solving this.

    Saving a file and opening a previously saved file are two of the most common operations in software applications. Write down a list of things you would like to verify in your test case design if you are in charge of testing these two operations. You should be able to come up with at least five distinct items to verify for each operation.
    1. Saving a file
    -First four distinct items to verify
    -All additional items to verify beyond the first four to make it a sound and complete test design
    2. Opening a previously saved file
    -First four distinct items to verify
    – All additional items to verify beyond the first four to make it a sound and complete test design

    Reply
    • Test Scenario 1: Check windows maximize, minimize and close functionality

      Test Scenario 2: Check if the window is re-sizeable

      Test Scenario 3: Check for image upload functionality

      Test Scenario 4: Check for uploaded image path

      Test Scenario 5: Check image upload with image size greater than the max allowed size. The Proper error message should be displayed.

      Test Scenario 6: Check image upload functionality with file types other than images (e.g. txt, doc, pdf, exe etc.). A Proper error message should be displayed.

      Test Scenario 7: Email addresses should be validated before sending emails.

      Test Scenario 8: Check emails with attachments.

      Test Scenario 9: Email subject should not be blank.

      PLEASE solve it
      – test case id
      – test case
      -test case name
      -input data
      -expected output

      Reply
  95. Hi Vijay your work is Much appreciated , the amount of knowledge you are spreading through these Posts is really Terrific , Accept our sincere & Heartful Thanks .

    Reply
  96. 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.

    Reply
  97. Hi there, this is very helpful. Are you able to provide some sample of test cases based on healthcare IT. Thank you.

    Reply
  98. 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.
    fgfgfgrgfgftrvfgrt

    Reply
  99. Hi,

    We can consider the below point as well in the section of “Test Scenarios for Excel Export Functionality”

    Check whether there is any sheet has been hidden in the exported excel sheet

    Reply
  100. Thanks for this helpfull article.Alot of usefull information and knowledge development. You serve as a mentor to most us…Great Effort!

    Reply
  101. This 1 superb , really its applicable on each and evry application . Thanks for making this type of comprehensive scenarios. Keep updating us by this new -new ideas , realy i like this website …

    Reply
  102. R/s VIJAY sir,
    The site and post is very very very nice. I would like to praise your parents for keeping your name VIJAY because your knowledge and this site is acting as visa for getting VIJAY or success in the software testing industry

    Your friend,
    NILESH

    Reply

Leave a Comment