Best Examples Of Web Applications Test Cases

Best Examples Of Web Applications Test Cases

“More than the act of testing, the act of designing tests is one of the best bug preventers known.”— Boris Beizer

You must have found this eye-catching statement very promising. In most areas of our life, we all desire the best. Best quality, best price, best practices, best time, best service, and this & that, so why not the best test cases for web application? Right? 

But please, pause, and I would like you to pay attention to the word ‘Best.’ 

Before and during writing the article, I researched and tried to understand who that single person or organization in the software testing world is, talking about best test cases, best practices for writing test cases, etc. 

Many are writing something on the theme of ‘Best,’ but no surprise, none of them are credible and trustworthy subject matter experts or organizations! Almost 99% of them focus on ‘step-by-step verifications of specified requirements’ and have no discussions around risk, context, ideas, different situations, users, use cases, what a web application looks like, etc. Seeing those articles caused me a headache. Why are these people and content publishing businesses not carefully studying the craft of software testing? 

But keep hope, friends, and let’s move our attention from myths to the world’s reality. Although this means that best test cases for a web application are myths and instead of aimlessly chasing the best, it is good for our health if we understand first that an attempt to declare a test case or suite of test cases as ‘Best’ is heavily context driven.

Context-driven? Yes, because information objectives of the testing effort play an essential role in the thinking, designing, and selection of a handful of test cases. Does that make sense? It may not now, but it will soon as you progress reading this post.

Now, while you will soon come to know what a Test Case looks like and what makes it good or bad, if not best, you must recall that ‘Best’ is contextual, and it is the right time to explore this further as an adult and learning software tester. Ready for the learning journey?

What do you Test with Web Applications? 

To answer this question reasonably, let’s build a shared understanding that a web application is a solution, a convenient way to solve a user’s problem, or an attempt to satisfy the user’s requirements. For example – Look at how reserving a plane ticket or a hotel room has become so easy as you can reasonably quickly, safely, and anytime do it using a dedicated web application that is online almost 24*7 and allows you to accomplish your work without you having to go outside home.

Web application as a solution to a user’s problem (alternatively, a means to satisfying a user’s needs)

As a software tester, be proactive and curious to know, as accurately as possible, what is the problem a web application under test is solving, and for whom? In simple words, know who the users are, their use cases, and in what situations and environments they use the application. 

Also, learn reasonably as much as you can about their desires of web application quality.


Now, users want to accomplish something useful using the web application and  feel happy. 

For example, in the case of a food delivery web application, a hungry user will feel accomplished in at least two ways. 

  1. When their overall user experience with the web application is outstanding, they can order food quickly, get discounts, pay safely by choosing one from multiple methods offered, track the order, and get it in the promised time as the app suggests.
  2. They ultimately get the food warm, fresh, non-contaminated, reasonably priced, and with minimal communication with restaurant and delivery personnel.

As web application testers, we have more control over testing the overall user experience (point 1 above) and significantly less control over the other(point 2 above). Isn’t it? 

A solid understanding of two types of typical and time-tested requirements drives web application testing.

  1. Functional/behavioral requirements: Requirements that help build different core features/functions/workflow in the web application.
  2. Function enabler requirements: Requirements that make this functional/behavioral accomplishment experience a safe, fast, Inclusive, synced, and deeply satisfying experience for targeted users.

What to test: 

Now, typically, you can start testing whatever you prioritize; provided your information objectives, timelines, and testing budgets are reasonably defined, and you have a test strategy in place. 

First, however, it would be best to learn what tests to design to reach that readiness state.

Hence, I strongly recommend some lovely and handy (not easy!) guides available: HTSM by James Bach and ‘The Little Black Book On Test Design‘ by Rikard Edgren. 

HTSM beautifully shows you the product elements and quality criteria dimensions of the strategy model. Here is a non-adulterated glimpse.

Product Elements are aspects of the product that you consider testing. 

Quality Criteria Categories are dimensions in which people determine the value of the product.

Take 60-90 seconds. Please save these guides and later print them, put them on your desk, and spend the best of your time with them to guide your testing and generate valuable test ideas (and test cases, maybe).

How do you Write a Test Case for a Web Application?

So if you quickly browse the internet and ask Google, ‘What is a test case?’ On page 1, you may get responses like (the snippets shown below, and there were many such examples, but I picked two of them)

How to write test cases
how to write test cases- step by step

So, is the Test Case an advocate of verifications? Seriously? Who said so? I am 99% sure it was not from these testing experts Cem Kaner, Glenford J. Myers, Jorgensen, or Jerry Weinberg. 

To-Do for you: Find out who said so about test cases and put them in the comments, and this is an opportunity to do some good to the testing world.

Imagine you are testing a web application with a typical GUI login component to allow a legitimate user to get into the application using valid credentials and access their data in secure and trusted ways.

Assume that your task is to write a test case for this. Would you want to refrain from demonstrating your good test ideas (cases, for now) thinking and writing skills? Of course, you do not wish to, but the challenge is knowing what a good test case is.

So, what IS a good test case?

  1. It should have a high probability of catching an error
  2. It shouldn’t be redundant
  3. It’s the best of its breed
  4. It is neither too simple nor too complex


  1. What IS a good test case? by Cem Kaner, JD, PhD
  2. Characteristics of a good test (Testing Computer Software by Cem Kaner, Jack Falk, Hung Q. Nguyen)

Also, refer to some good analytical posts by one of the most inquisitive test leaders Shrinivas Kulkarni.

To-Do for you: When you write test cases, please pay attention to your habit of ‘Verifying’ instead of ‘Questioning’ the software! Observing what is going on in your brain is critical when you say to yourself, ‘Let me verify…’. Do you know what it means, or are you following a dangerous pattern?

The Components of a Test Case for Web Applications

Referring to a classical definition of a Test Case (from the seminal book Software Testing: A Craftsman’s Approach by Paul C. Jorgensen)…

“A test case has an identity and is associated with a program behaviour. It also has a set of inputs and expected outputs.”

Wikipedia defines a Test Case as…

test case

So referring to Wikipedia’s definition of a test case, the following could be the components.

  1. Application / Module / User behavior under Test
  2. Testing objective
  3. Precondition(s) for Test
  4. Execution Steps
  5. Expected Results
  6. Actual Results

But let’s take an alternative view, and if you have referred to HTSM and / or The Little Black Book On Test Design, you might already be thinking about generating test ideas around various themes. 

Pick Structure from Product Elements from HTSM and consider analyzing some of the building blocks of a simple and business domain agnostic web application. When I use Structure to guide my test design, I also include web application architecture. From there, I further decompose the system to GUI, API, DB, and other layers as applicable.

Note: I find it valuable to have access to the application’s architecture diagrams because those further allow you to find out the different layers in the web application. Something like the ones I created using Lucidchart and xMind and shown below.

web application architecture

Referring, studying, questioning this model, you might devise a list of possible test ideas around the following web application components. 

web application tests

Those test ideas across different themes like Testability, Function, Usability, Security, Performance, and so on will further help in generating test possibilities (cases in conventional language)

To-Do for you: Think about it from a Time, Cost, value, and Depth/Breadth of testing standpoint, and then you can choose to generate mind maps (using xMind, for example) for test ideas and cases (the possibilities generated from that idea), whatever you might want to call it.

Test Cases Example For Web Application

Now after you have seen all this and probably understood some fundamentals around Tests, Test Cases, and Good Test Cases, let’s talk about what looks like a set of tests regarding web application testing. As a web app tester, among many other themes, I would go for test design on the following to start with

  • Testability
  • Usability
  • Functional
  • Compatibility 
  • Database
  • Security
  • Performance

Each of these testing areas is like the ocean, and in the coming sections, I will share some fundamentals and leave scope for further reading.

Example: Testability Test Cases for Web Application

I must confess that I have made many mistakes in the early years of my testing career, w.r.t. Not asking enough and on time to build testability into web applications under test. Yet, thinking of and building good testability is one of the most underestimated aspects of software development. So, why not start by talking about Testability Tests?

Testability Tests: One of the early tests to conduct as web application development and test planning begin is asking questions on the following, at least to start with. 

  • Observability: In most straightforward words, observability is about the ‘ability to see the effects of a test on the AUT closely.’ Some outcomes/effects of a test are easily visible, and some are not. Some observability is meant for end users, and some are not. A good question about observability could be asking about logging and different logging levels.
  • Controllability: Find out how easily and accurately the variables in different product elements can be altered or put in a desired state. Putting critical variables in a desired state helps the tester gain confidence in the ‘Reproducibility of behaviors’. 
  • Isolability: If you have ever reported a bug, you must have known what isolation means. Isolability allows minimizing (or probably optimizing) a product element’s variable’s mutual dependencies and still enable a tester to test a meaningful transaction. 
  • Deployability:  How easy, controlled, and well-managed is it to deploy the AUT 
  • in different test environments where the ultimate test environment is production? 

All above are amongst some of the key aspects of overall testability and help put the AUT in a desired state (configured), act upon (operated), and allow testers to observe the outcomes.

To guide your test ideas and possibilities (cases) writing efforts, refer to Heuristics of Software Testability

Example: Usability Test Cases for Web Application

“Dollars flow where friction is low.” quoted by Brian Halligan at INBOUND 2019 hosted by Hubspot. 

Referring to HTSM, Usability testing helps answer the question or probe, “How easy is it for a real user to use the product?” Per HTSM, there are three main criteria to test for when it comes to Usability Testing.

  • Learnability: the operation of the product can be rapidly mastered by the intended user.

Test Ideas for learnability: From a test user standpoint, Imagine yourself in the target user’s shoes while starting to use the product, and if 

  • You are not frustrated.
  • You, spending very little time, and that too in a single session, can still learn the product.
  • You are not in the mood to utter the words like ‘I am not sure what to do next.’

Then it is a good indicator that learnability is built by design into the product.

  • Operability: the product can be operated with minimum effort and fuss.

Test Ideas for Operability:

  • Minimal physical effort and minimal cognitive load, e.g., you feel comfortable and at home while operating the product for its intended use.
  • You think of making an error, but you come out of the situation and say w/o spending too much time and feeling frustrated, ‘Ah, now I get it. Makes sense
  • Accessibility: the product meets relevant accessibility standards and works with O/S accessibility features.

Test ideas for Accessibility, abbreviated as a11y: For web applications, WCAG (Web Content Accessibility Act) and ADA (Americans With Disability Act) are highly credible sources for generating tests. Some of the test ideas to assess Accessibility (inclusive usability irrespective of physical, visual, motor, and other impairments)  

Some key test ideas when starting a11y testing (basically tools assisted)

  • Is your web application working with screen readers?
  • Is the web application working with speech recognition software?
  • How about font size, content placement, visibility, colors, contrast, and so on

To guide your test ideas and possibilities (cases) writing efforts, refer to

Planning a user test? Follow these 9 steps to make sure you are prepared

Why You Only Need to Test with 5 Users

Example: Functional Test Scenarios:

These are the tests you will run to uncover bugs and learn about the web application’s functions. E.g., If there is a function in a simple EMI calculation application that calculates EMIs based on user-entered values via a GUI, then,

  • Can the calculation function be invoked using the desired action/location/method? E.g., click on a button
  • Is it performing the desired calculations accurately and quickly?
  • Are the calculation results consistently correct?
  • On data change and re-calculate, is the calculation still correct and quick?
  • And so on..

Functional test cases for web applications should be designed and run not only for/from GUI but also API endpoints to judge consistency and find opportunities for bug identification. 

To guide your test ideas and possibilities (cases) writing efforts, refer to Functional Testing Heuristics: A Systems Perspective by Joris Meert.

Should these test cases be automated?

The straightforward one-liner answer is ‘Automate what should be automated.’ 

As far as I have observed, there is a common perception that there is something called manual testing. Have you heard about it? 

Those who buy this idea of Manual testing believe that once you execute the manual functional test cases, you can automate those and run those tests from Automation. Unfortunately, this belief system often results in Manual and Automation testing. What a sad state!

I think this is a narrow view of looking at Automation and the capabilities of automation tools as a skilled tester’s efficient assistant. A professional tester uses Automation to help her in day-to-day testing activities especially executing checks and assertions on some key and algorithmic functional behaviors. 

A skilled tester finds out what she should not repeatedly check on her own and avoids wasting precious time. It is better to delegate the task(s) of fact-checking, data recording, measuring, and reporting to another program written with testability, usability, maintainability, scalability, and performance in mind.

In a nutshell, find out what tests have essentially turned into good checks after initial exploration. In any case, periodically evaluate those automated checks so that they help find valuable information and save time and cost.

Let’s take an example of API testing and assume you are using a tool to automate it, then…

  • Automate assertions w.r.t. status codes, response times, response bodies, work flows, schema validations can be good candidates to become part of the automation suite.
  • Automate the checks assessing if critical API endpoints are available and running and such checks must be scheduled via a well-defined collection that runs at a predefined time and sends required E-mail and SMS notifications. 

Functional (especially heavily and iteratively data-driven) and Calculation related assertions (checks) are also good candidates for automation. It is helpful not to go beyond a certain level of check automation when simulating GUI. 

However, there is value in asserting that all web elements are present, interactable, available on time, and syncing appropriately as the environmental factors allow.

Accessibility and Security vulnerability assessment checks are often tools assisted and help automate the scanning of a large portion of the AUT and provide assessment results quickly. Be skeptical and use those results to start your testing journey.

As a word of caution, avoid thinking in terms of manual tests (if they exist) conversion into automated tests.

Alan Page has written a seminal book called The A Word. Please refer to that for building an excellent foundational understanding of Automation.

Sample Compatibility Test Scenarios:

Referring to HTSM, Compatibility tests help answer the question or probe, ‘How well does it work with external components & configurations? There are the following criteria to test for when it comes to Compatibility Testing.

  • Application Compatibility: the product works in conjunction with other software products. 
  • Operating System Compatibility: the product works with a particular operating system.
  • Hardware Compatibility: the product works with particular hardware components and configurations.
  • Backward Compatibility: the product works with earlier versions of itself.
  • Product Footprint: the product doesn’t unnecessarily hog memory, storage, or other system resources

Should these test cases be automated?

Web applications, in general, and by nature, are developed with a desire for utmost compatibility with different OS, Hardware, Browsers, and platforms keeping in mind. As a result, the technology stack often greatly supports compatibility.

As far as compatibility test automation in web application testing is concerned, there are tools like Testsigma. Testers should use these tools to automate selected user behaviors simulation across many devices, platforms, and screen resolutions to find out compatibility-related bugs.

Example Test Cases for Database Testing:

Database testing is an integral part of data-driven web applications. Hardly any applications we use today are untouched, especially when it comes to users, their transactions, and their reporting data. As a web application tester, once a transaction is made through GUI or API, I would be checking, for example

  • Where is all this test data being stored? A file, a relational database, a  non-relational database?
  • Once data is submitted from GUI or API, has it changed, and to what extent? 
  • When I go to sleep, what happens to the stored data? Does it change again?
  • How does a different module get this data, and how do those modules further process the data?
  • How does it look when other integrated/connected applications use it?
  • How does data look on the reporting and data warehouse sides?
  • Data migration badly impacted some or all data? Fully or partially?

Some checks which are fundamental to run are…

  • Check if business rules are defined and implemented at the proper layers.
  • From Source (GUI, API. CSVs) to Target (including intermediate/temporary destinations) if columns (fields) are correctly (directly or indirectly) mapped?
  • How data is related across multiple relations (represented as tabular structures, a.k.a Tables)
  • How is data inside the relation normalized or denormalized?
  • How is data redundancy maintained across relations?
  • One-to-many, many-to-one, many-to-many relationships?
  • Is there an issue with data integrity?

Should these test cases be automated?
Yes, when there are some static checks and when you want to detect changes in relation names, fields addition/omission, and relation consistency checks. 

Automated checks can be implemented using SSIS packages (for example) if you are working on SQL Server and T-SQL.

Sample Test Scenarios for Security Testing:

Referring to HTSM, Security related tests help answer the question or probe, ‘How well is the product protected against unauthorized use or intrusion?’ There are the following criteria to test for when it comes to Compatibility Testing.

  • Authentication: the ways in which the system verifies that a user is who he says he is.
  • Authorization: the rights that are granted to authenticated users at varying privilege levels.
  • Privacy: the ways in which customer or employee data is protected from unauthorized people.
  • Security holes: the ways in which the system cannot enforce security (e.g. social engineering vulnerabilities)

Should these test cases be automated?
Yes, these days, most initial vulnerability scans are automated using tools like Burp Suite. As a result, they might help detect and report vulnerabilities at a high level. But that is just a starting point.

No, Social engineering-related attacks, in my view, can’t be automated and shouldn’t be generalized to push toward automation. Those attacks (tests) are expert security researchers’ knowledge, experience, and subject matter expertise driven. 

General Test Scenarios for Performance Testing:

Performance testing helps a tester assess and find problems in the speed and responsiveness of the overall system and often its different components. In addition, performance testing planning requires a tester to think about other load conditions causing less load, average load, peak load on the system, and sometimes causing stress, spike, and heavy load for consecutive days.

For example, in load testing, test scenarios are designed to simulate (mimic) the real-world concurrent usage of a software system using virtual users or threads and gather data w.r.t overall system health and user experience.  

The simulation is often done using a specialized tool like JMeter, and use cases are defined in terms of Test scenarios. One of the prerequisites of a load test design is that the expected number of users (a reasonable guess) and typical, business-critical, frequent edge-case behaviors are identified and carefully documented.

With the help of data gathered from load testing, we can decide what, when, and how of resources and budget allocation to maintain systems to handle low, average, peak, and harsh loads in a real production environment.

Should these test cases be automated?
Yes, load tests are usually automated using a load injector tool like Apache JMeter and other available tools.

Tools for Automating Your Test Cases for Web Application

Testsigma (Functional test automation and test management): Assists a skilled web application tester in automating checks for web, mobile apps, desktop and APIs with English scripts that self-heal, enabling maintenance-free scripting.

Burpsuite (Security vulnerability scans): Assists a curious and security tests-focused web application tester to perform application vulnerability scans. These scans often provide valuable yet starting-level information regarding security loopholes, exposed threat surfaces, and security design problems.

Apache JMeter (Load testing): Assists in injecting variable loads on web applications through threads (virtual users) and helps evaluate server-side health. This evaluation further helps understand hardware and infrastructure scaling requirements, cost-benefit analysis, and setting user experience-related quality expectations within those constraints.

Browserstack (Cross browser testing): Enables web application testers to test web applications across different browsers, operating systems, and mobile devices. So when it comes to compatibility testing, tools like BrowserStack can be a good friend to a good tester.

SSMS (Database Testing): As a database tester, I would do an injustice if I didn’t discuss this tool. SSMS stands for SQL Server Management Studio, which uses T-SQL as a query language. To test, for example, if the transactional data submitted from the GUI/API is entirely and appropriately stored in the correct set of tables.

PICT (Combinatorics): A web application has features and functionalities governed and driven by several variables. PICT is a command line tool, Pairwise Independent Combinatorial Tool, and can be found here PICT generates test cases and tests variable configurations. With PICT, you can create many combinatorics tests in a fraction of the time required by hands-on test case design.


To conclude, and you must also have observed by now that I have focused on following..

  • Understanding web applications, users, and requirements
  • Revisiting test cases and an alternative view of test cases as test ideas and test possibilities
  • Designing test ideas using the appropriate techniques, guiding principles, and time-tested heuristics
  • How to look at Automation beyond manual test cases conversion to code snippets 

Test automation made easy

Start your smart continuous testing journey today with Testsigma.