What Is Web Application Testing? What to Test and How

What is web application testing?

Web application testing (also called web app testing or website testing) is a set of checks that confirms a web application meets its requirements. Teams test functionality, usability, compatibility, performance, security, and accessibility, using a mix of manual testing and automated tests.

It isn't a single step at the end of a project. Most teams test continuously: during development, before each release, and after updates, because a change in one part of a web app can break a flow somewhere else.

Example of web application testing

Take Tripadvisor, a travel review site with tens of millions of visitors a month. A bug on its homepage reaches a lot of people quickly.

A short list of test cases for this one page could include:

1. Check that search returns relevant results for a destination.
2. Check that the Hotels, Things to Do, and Restaurants tabs change the search scope and the on-screen text.
3. Check the AI trip-planning feature on the homepage.
4. Check that destination suggestions match the user's activity on the site.

That's the homepage alone. A web app with connected features can have hundreds of scenarios to test, which is why QA teams use automation testing for the repetitive ones.

What to test in a web application

Functionality

Functional testing checks that every feature behaves as intended. A web tester typically checks that:

• Forms submit correctly and validate their inputs
• Links and navigation work
• Buttons trigger the right actions
• APIs return correct responses
• Business logic works, for example checkout, login, and user roles

Functional bugs are the most visible to users, so these checks form the core of most test suites. See functional testing for more.

Security

Web apps are exposed to the public internet, so testers also check that they're secure:

• Look for vulnerabilities such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF)
• Verify authentication and authorization controls
• Check how sensitive data is stored and sent
• Confirm sessions are handled securely
• Validate protection against brute-force attacks

A security flaw can do far more damage than a layout bug, to users and to the business.

Performance and reliability

Performance testing checks how the app behaves under real-world conditions:

• Load testing: does the app behave normally with many users at once?
• Stress testing: how does it behave during extreme spikes?
• Response times for key pages and APIs
• Server behavior at peak demand

The goal is to find slowdowns and crashes before users do.

Compatibility, usability, and accessibility

The same app has to work for every user, on every supported browser and device:

For a deeper look, see cross-browser testing, accessibility testing, and regression testing.

Manual vs automated web application testing

Teams test web apps in two main ways, and most use both.

Manual web testing

In manual testing, testers use the app directly, without scripts, to check its functionality, interface, and overall experience.

• Good for: visual, usability, and exploratory checks, where human judgment catches issues a script would miss. No framework or coding needed.
• Limits: slow for large or repetitive suites, hard to scale as the app grows, and open to human error.

Automated web testing

Automation testing uses scripts and tools to run test cases with little manual effort, so the same checks run the same way every time.

• Good for: repetitive and large suites, regression checks, and teams that release often.
• Limits: it takes setup time, tools, and skills up front, and tests need maintenance as the app changes. It's also weaker at judging subjective UX.

A common split: automate stable, repeated flows such as login, search, and checkout, and keep exploratory and usability testing manual.

The web application testing process

1. Requirement analysis

Testers work with stakeholders to understand the product's requirements: functional, non-functional, business, and technical. That includes:

• Expected workflows
• User roles and permissions
• System interactions
• Performance expectations
• Acceptance criteria

Many teams record each requirement in a requirement traceability matrix (RTM) that maps it to the test cases that cover it, so nothing is missed. Three roles usually take part:

• Product owner: explains the business goals and the problem the product solves.
• Developer: turns requirements into technical solutions and flags constraints.
• Tester: checks that each requirement is testable, finds gaps, and plans how to validate it.

If a requirement is incomplete or unrealistic, testers work with the business side to refine it or adjust the scope. For test case ideas, see these examples: test cases for a login page, test cases for a registration page, and test cases for search functionality.

2. Test planning

The team then sets the strategy for the whole testing effort:

• Test objectives: what to validate, such as functionality, usability, security, and performance.
• Deliverables: test cases, test scripts, test data, and defect logs.
• Scope: which features are in scope and which are out.
• Resources: team size, skills, environments, and budget.
• Timeline: dates for preparation, execution, reporting, and closure.
• Approach: manual or automated, test levels (unit, integration, system), and test types (regression, smoke, performance).

3. Test case development

Testers write test cases that define how each feature is validated, step by step. A good test case has an ID, a description, preconditions, steps, test data, an expected result, the actual result, and pass or fail criteria. Here's one for a login feature:

This is one case of many. Add edge cases (special characters, very long inputs), negative cases (wrong passwords, empty fields), and cases that try to break the system.

4. Test environment setup

Before running tests, set up an environment that matches production as closely as you can: the browsers and versions you support, test data, accounts for each user role, and access to the APIs and services the app depends on. Tests that pass in a different environment from production can hide real bugs.

5. Test execution

Testers run the test cases and compare actual results with expected ones. Each test ends in a status such as passed, failed, blocked (a dependency such as a critical bug stops it), skipped, or untested.

Bugs follow the bug life cycle and are logged in a defect management tool with steps to reproduce, screenshots or logs, severity and priority, and environment details. Here's how to write a test report.

6. Test cycle closure

The last phase sums up results and lessons learned. A closure report usually covers:

• Execution environment: devices, operating systems, browser versions, and tools used.
• Test log: what was run and when.
• Results: pass and fail rates, defect counts, and execution time.
• Comparison: how quality changed since the last release.
• Recommendations: how to improve coverage, process, or product quality.

The QA team then reviews the cycle with stakeholders and records what to change next time.

Web application testing frameworks

To automate web tests, most teams use a framework or a tool built on one. The three most common open-source frameworks:

• Selenium: sends commands to real browsers through WebDriver and supports Java, Python, C#, JavaScript, and more. It runs on every major browser and scales out with Selenium Grid. Our Selenium testing tutorial walks through setup and a first test.
• Cypress: runs tests inside the browser alongside the app, with JavaScript and TypeScript, and gives fast feedback while you develop.
• Playwright: controls Chromium, Firefox, and WebKit through one API, with support for multiple tabs and browser contexts.

All three need coding skills, and scripts need updating as the app changes. That maintenance is where many teams look for tooling that records tests and helps keep them working.

Automate web application testing with Katalon Studio

Katalon Studio lets you build web tests without writing every line by hand, then run them on your machine or in your CI pipeline:

1. Record the flow. Open Web Recorder Plus, click through the scenario in your browser, and Studio saves the steps and the page elements as a test case you can edit.
2. Or describe it. With a Katalon Studio Enterprise (KSE) license, you can describe the scenario in natural language and let Studio run and record the steps for you, using the AI Recording Agent (Beta) in Web Recorder Plus. Review the steps it writes before you save them.
3. Run it across browsers. Run the test locally in Chrome, Firefox, Edge, or Safari (on macOS), and add checks with built-in keywords or your own code.
4. Run it in CI. Run the same test from the command line with Katalon Runtime Engine (KRE) in Jenkins, GitHub Actions, Azure DevOps, or GitLab. CI execution needs a KRE license.

See how this works end to end on our AI web testing page.

Challenges of web application testing

A fragmented browser and device landscape

Web apps have to work across many combinations of browsers, devices, operating systems, and rendering engines. The differences between them cause bugs that are hard to predict and reproduce.

Fast-changing web technology

Modern apps use single-page frameworks, asynchronous calls, and microservices. As the technology changes, tests and test strategies have to keep up.

Test maintenance

Automated tests can be fragile: a small UI change can break many scripts. Common symptoms are flaky tests, unreliable CI results, frequent rewrites, and tests that pass locally but fail in shared environments. Keeping automation stable can take as much work as writing it.

Web application testing best practices

1. Test across the browsers and devices your users actually use.
2. Define clear criteria for usability tests before you run them.
3. Run performance tests under a range of conditions, and increase load in steps.
4. Test every element, including third-party integrations.
5. Make exploratory testing part of every release, not only the end of a project.
6. Involve developers throughout testing, not only when bugs are found.
7. Automate stable, repeated flows first, and review automated tests when the UI changes.

For more, read our automated web testing best practices.