Test Cases Example for Web Application (Checklist)

By : Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Smart Summary

Complete web application testing checklist coverage spans usability, functional, compatibility, database, API, security, performance, and accessibility checks. Each section below supplies ready-to-use test scenarios that quality assurance teams can copy straight into a test management tool.

  • ⚙️ Functional first: Validate mandatory fields, boundary lengths, leap years, division by zero, and timeout behaviour before any cosmetic review begins.
  • 🧭 Usability signals: Check alignment, tooltips, keyboard access, scroll bars, and error-message recovery so a first-time user never gets stuck.
  • 🌐 Compatibility matrix: Repeat critical flows on Chrome, Firefox, Edge, Safari, and mobile browsers to expose layout and script differences.
  • 🗄️ Database integrity: Match front-end values against stored records, verify keys, triggers, stored procedures, and field lengths on both layers.
  • 🔌 API layer: Assert status codes, schemas, authentication, rate limits, and downstream failure handling separately from the browser.
  • 🔐 Security baseline: Force HTTPS, encrypt stored secrets, lock accounts after repeated failures, and probe for SQL injection and brute force.
  • 🚀 Performance and access: Script load profiles with automation instead of manual effort, then confirm WCAG contrast, labels, and keyboard operation.
Read More

While testing the web applications, one should consider the below mentioned template. The below mentioned checklist is almost applicable for all types of web applications depending on the business requirements.

The template above shows how one sheet can carry scenarios for every checklist area. For background, see the web application testing overview.

Now let’s look each checklist in detail:

Functional Testing

What is Functional Testing?

  • Testing the features and operational behavior of a product to ensure they correspond to its specifications.
  • Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.

What is the purpose or Goal of Functional testing?

  • The goal of Functional Testing is to verify whether your product meets the intended functional specifications mentioned in your development documentation.

Example Functional Test Scenarios:

  • Test all the mandatory fields should be validated.
  • Test the asterisk sign should display for all the mandatory fields.
  • Test the system should not display the error message for optional fields.
  • Test that leap years are validated correctly & do not cause errors/miscalculations.
  • Test the numeric fields should not accept the alphabets and proper error message should display.
  • Test for negative numbers if allowed for numeric fields.
  • Test division by zero should be handled properly for calculations.
  • Test the max length of every field to ensure the data is not truncated.
  • Test the pop up message (“This field is limited to 500 characters”) should display if the data reaches the maximum size of the field.
  • Test that a confirmation message should display for update and delete operations.
  • Test the amount values should display in currency format.
  • Test all input fields for special characters.
  • Test the timeout functionality.
  • Test the Sorting functionality.
  • Test the functionality of the buttons available
  • Test the Privacy Policy & FAQ is clearly defined and should be available for users.
  • Test if any functionality fails the user gets redirected to the custom error page.
  • Test all the uploaded documents are opened properly.
  • Test the user should be able to download the uploaded files.
  • Test the email functionality of the system.
  • Test the Java script is properly working in different browsers (IE, Firefox, Chrome, safari and Opera).
  • Test to see what happens if a user deletes cookies while in the site.
  • Test to see what happens if a user deletes cookies after visiting a site.
  • Test all the data inside combo/list box is arranged in chronological order.

Once features behave correctly, the next question is whether real users can operate them without help.

Usability Testing

What is Usability Testing?

  • Usability testing is nothing but the User-friendliness check.
  • In Usability testing, the application flow is tested so that a new user can understand the application easily.
  • Basically, system navigation is checked in Usability testing.

What is the purpose or Goal of Usability testing?

A Usability test establishes the ease of use and effectiveness of a product using a standard Usability test practices.

Example Usability Test Cases

  • Web page content should be correct without any spelling or grammatical errors
  • All fonts should be same as per the requirements.
  • All the text should be properly aligned.
  • All the error messages should be correct without any spelling or grammatical errors and the error message should match with the field label.
  • Tool tip text should be there for every field.
  • All the fields should be properly aligned.
  • Enough space should be provided between field labels, columns, rows, and error messages.
  • All the buttons should be in a standard format and size.
  • Home link should be there on every single page.
  • Disabled fields should be grayed out.
  • Check for broken links and images.
  • Confirmation message should be displayed for any kind of update and delete operation.
  • Check the site on different resolutions (640 x 480, 600×800 etc.?)
  • Check the end user can run the system without frustration.
  • Check the tab should work properly.
  • Scroll bar should appear only if required.
  • If there is an error message on submit, the information filled by the user should be there.
  • Title should display on each web page
  • All fields (Textbox, dropdown, radio button, etc) and buttons should be accessible by keyboard shortcuts and the user should be able to perform all operations by using keyboard.
  • Check if the dropdown data is not truncated due to the field size. Also, check whether the data is hardcoded or managed via administrator.

A layout that reads well in one browser can break in another, so replay the same screens across every supported environment.

RELATED ARTICLES

Compatibility Testing

What is Compatibility testing?

  • Compatibility testing is used to determine if your software is compatible with other elements of a system with which it should operate, e.g. Browsers, Operating Systems, or hardware.

What is the purpose or Goal of Compatibility testing?

  • The purpose of Compatibility testing is to evaluate how well software performs in a particular browser, Operating Systems, hardware or software.

Sample Compatibility Test Scenarios:

  • Test the website in different browsers (IE, Firefox, Chrome, Safari and Opera) and ensure the website is displaying properly.
  • Test the HTML version being used is compatible with appropriate browser versions.
  • Test the images display correctly in different browsers.
  • Test the fonts are usable in different browsers.
  • Test the java script code is usable in different browsers.
  • Test the Animated GIF’s across different browsers.

Consistent rendering proves nothing about the records behind the screen. A cross browser testing matrix keeps this area manageable.

Database Testing

What is Database Testing?

  • In Database testing backend records are tested which have been inserted through the web or desktop applications. The data which is displaying in the web application should match with the data stored in the Database.

To perform the Database testing, the tester should be aware of the below mentioned points:

  • The tester should understand the functional requirements, business logic, application flow and database design thoroughly.
  • The tester should figure out the tables, triggers, store procedures, views and cursors used for the application.
  • The tester should understand the logic of the triggers, store procedures, views and cursors created.
  • The tester should figure out the tables which get affected when insert update and delete (DML) operations are performed through the web or desktop applications.

With the help of the above mentioned points, the tester can easily write the test scenarios for Database testing.

Example Test Cases for Database Testing:

  • Verify the database name: The database name should match with the specifications.
  • Verify the Tables, columns, column types and defaults: All things should match with the specifications.
  • Verify whether the column allows a null or not.
  • Verify the Primary and foreign key of each table.
  • Verify the Stored Procedure:
  • Test whether the Stored procedure is installed or not.
  • Verify the Stored procedure name
  • Verify the parameter names, types and number of parameters.
  • Test the parameters if they are required or not.
  • Test the stored procedure by deleting some parameters
  • Test when the output is zero, the zero records should be affected.
  • Test the stored procedure by writing simple SQL queries.
  • Test whether the stored procedure returns the values
  • Test the stored procedure with sample input data.
  • Verify the behavior of each flag in the table.
  • Verify the data gets properly saved into the database after each page submission.
  • Verify the data if the DML (Update, delete and insert) operations are performed.
  • Check the length of every field: The field length in the back end and front end must be same.
  • Verify the database names of QA, UAT and production. The names should be unique.
  • Verify the encrypted data in the database.
  • Verify the database size. Also test the response time of each query executed.
  • Verify the data displayed on the front end and make sure it is same in the back end.
  • Verify the data validity by inserting the invalid data in the database.
  • Verify the Triggers.

API Testing Checklist

Most business rules now live behind REST or GraphQL endpoints, so browser checks alone cannot prove the system works. Testing endpoints directly exposes contract and authorisation defects far earlier than the user interface can.

Cover the following scenarios before an endpoint is signed off:

Sample Test Scenarios for API Testing:

  • Verify documented status codes for success, validation failure, unauthorised access, and server error.
  • Verify the response payload matches the published schema, including field names and data types.
  • Verify missing or malformed parameters return a readable message rather than a stack trace.
  • Verify authentication tokens expire, refresh correctly, and cannot be replayed after logout.
  • Verify role based authorisation, so a standard account cannot reach administrator endpoints by altering an identifier.
  • Verify boundary values on every parameter, including empty strings and maximum lengths.
  • Verify rate limiting returns the correct throttling response instead of failing silently.
  • Verify the endpoint degrades gracefully when a third party service times out.
  • Verify no passwords, tokens, or internal paths appear in responses or error messages.

Run this list in every environment, since staging and production often expose different permission sets. See the API testing overview and testing a REST API manually.

Several of those checks overlap with security work.

Security Testing

Security Testing involves the test to identify any flaws and gaps from a security point of view.

Sample Test Scenarios for Security Testing:

  • Verify the web page which contains important data like password, credit card numbers, secret answers for security question etc should be submitted via HTTPS (SSL).
  • Verify the important information like password, credit card numbers etc should display in encrypted format.
  • Verify password rules are implemented on all authentication pages like Registration, forgot password, change password.
  • Verify if the password is changed the user should not be able to login with the old password.
  • Verify the error messages should not display any important information.
  • Verify if the user is logged out from the system or user session was expired, the user should not be able to navigate the site.
  • Verify to access the secured and non-secured web pages directly without login.
  • Verify the “View Source code” option is disabled and should not be visible to the user.
  • Verify the user account gets locked out if the user is entering the wrong password several times.
  • Verify the cookies should not store passwords.
  • Verify if, any functionality is not working, the system should not display any application, server, or database information. Instead, it should display the custom error page.
  • Verify the SQL injection attacks.
  • Verify the user roles and their rights. For Example, the requestor should not be able to access the admin page.
  • Verify the important operations are written in log files, and that information should be traceable.
  • Verify the session values are in an encrypted format in the address bar.
  • Verify the cookie information is stored in encrypted format.
  • Verify the application for Brute Force Attacks

A hardened application that buckles under load is still unusable, so the next pass measures scale.

Performance Testing

Performance Testing is conducted to evaluate the compliance of a system or component with specified performance requirements.

General Test scenarios:

  • To determine the performance, stability and scalability of an application under different load conditions.
  • To determine if the current architecture can support the application at peak user levels.
  • To determine which configuration sizing provides the best performance level.
  • To identify application and infrastructure bottlenecks.
  • To determine if the new version of the software adversely had an impact on response time.
  • To evaluate product and/or hardware to determine if it can handle projected load volumes.

How to do Performance testing? By Manual Testing or by Automation

Practically it is not possible to do the Performance Testing manually because of some drawbacks like:

  • More number of resources will be required.
  • Simultaneous actions are not possible.
  • Proper system monitoring is not available.
  • Not easy to perform the repetitive task.

Hence to overcome the above problems we should use Performance Testing tool. Below is the list of some popular testing tools.

One audience is still missing: users who reach these screens through assistive technology.

Accessibility Testing Checklist

Accessibility testing confirms that people using screen readers, keyboard-only navigation, or magnification can complete the same journeys as everyone else. It is also a procurement requirement, since enterprise contracts commonly reference WCAG 2.2 Level AA. These defects are structural and cost far less to fix early.

Sample Test Scenarios for Accessibility Testing:

  • Verify meaningful images carry descriptive alt text and decorative images are hidden from assistive technology.
  • Verify every form control has a programmatically associated label, not just adjacent placeholder text.
  • Verify the page works with the keyboard alone, with a visible focus indicator at each stop.
  • Verify text and interactive elements meet the minimum contrast ratio against their background.
  • Verify headings follow a logical order without skipped levels, so screen reader navigation works.
  • Verify error messages are announced to assistive technology and identify the field at fault.
  • Verify the page remains usable at 200 percent zoom without horizontal scrolling.
  • Verify custom widgets such as modals, tabs, and accordions expose correct roles and states.

Automated scanners catch only part of these issues, so add a manual keyboard and screen reader pass. The accessibility testing reference covers the tooling.

FAQs

A test plan is a formal document covering scope, schedule, resources, risk, and exit criteria for a release. A checklist is a lightweight coverage reminder listing the conditions to verify. The plan governs the project; the checklist governs the individual testing session.

Review it after every major release, new integration, or production incident. Each escaped defect should add one line so the same failure cannot repeat. A checklist that is never revised quickly stops reflecting how the application actually behaves.

Most teams anchor security coverage to the OWASP Web Security Testing Guide, accessibility to WCAG 2.2, and overall process terminology to ISTQB. These references keep a checklist auditable rather than based purely on team habit.

Yes. Feeding requirements, user stories, or API specifications into a large language model produces a solid first draft of scenarios. A tester must still prune duplicates, add business rules the model cannot infer, and confirm each item is genuinely verifiable.

Self-healing locators re-identify elements after markup changes, cutting the flaky failures that dominate maintenance effort. AI also clusters duplicate defects and ranks which suites to run first, so regression cycles stay short as the checklist grows.

Summarize this post with: