How to Test a Web Application: Process, Checklist and Test Cases

To test a web application well, you need a plan before you need a tool: know what's in scope, where the risks are, which environments and data you'll use, and which kinds of testing matter for this product. Then you work through a checklist, write clear test cases, explore, automate the repetitive parts and report what you find.

This guide walks through that process step by step, with a 7-area checklist, a manual-vs-automated split for each area, sample test cases for a login page, a runnable Playwright example in JavaScript, and a bug report template you can copy.

How to Test a Web Application in 7 Steps

1. Plan: define scope, risks, environments and test data.
2. Choose the test areas from the checklist below that matter for this release.
3. Write test cases for the critical flows, positive and negative.
4. Execute the cases manually first, in the agreed browsers and devices.
5. Explore in time-boxed sessions to find what the cases missed.
6. Automate the stable, repeated checks so they run on every change.
7. Report bugs clearly, retest fixes, and summarise what was and wasn't covered.

Step 1: Plan the Testing

A one-page test plan beats a fifty-page one nobody reads. Answer four questions.

Scope

List what's in and out. "Checkout, account settings and the new coupon field are in. The admin panel and the legacy mobile site are out." Being explicit about what you won't test is as useful as the list of what you will.

Risks

Rank features by impact × likelihood. Payment, login and anything that touches personal data are high impact. Newly written or heavily changed code is high likelihood. Spend most time where both are high.

Environments

Test in an environment that mirrors production: same configuration, realistic data volume, the same third-party integrations (in sandbox mode). Agree on the browsers and devices you'll support, based on your real visitor analytics rather than guesses.

Test data

Decide which accounts, products and records you need, and how to reset them. Use dedicated test users with known roles (admin, standard, locked). Never use real customer data in a test environment.

Test Web Application Checklist: 7 Areas

Use this as a coverage map. Not every release needs every row, but you should consciously decide to skip one rather than forget it.

Functional testing

The core of any effort to test a web application. For each feature, test the happy path, invalid input, boundary values (0, 1, maximum length) and what happens when the user does things out of order, such as pressing Back after payment.

Compatibility: cross-browser and mobile

Bugs often hide in one engine only. Run the same flows in Chromium, Firefox and WebKit, and in phone-sized viewports. Check that nothing overflows horizontally and that buttons are large enough to tap. See Playwright cross-browser testing.

Security basics

You don't need to be a penetration tester to catch common problems. Know the categories in the OWASP Top 10 (broken access control, injection, authentication failures and so on) and check the obvious ones: can user A open user B's order by changing an ID in the URL? Does the session end on logout? Do error pages leak stack traces? Only test systems you're authorised to test, ideally with written permission and in a non-production environment. Deeper security testing belongs to specialists.

Accessibility

Try the main flow with only a keyboard. Every interactive element should be reachable with Tab, have a visible focus state and an accessible name. Automated scanners catch some issues; manual checks catch the rest. See Playwright accessibility testing.

Manual vs Automated Testing for Each Area

The pattern: humans find new problems, automation stops old problems coming back.

Sample Test Cases for a Login Page

Good test cases are short, specific and have one clear expected result. Here's a starter set for a login page (based on the practice site saucedemo.com, so you can try them).

TC-01 to TC-05 are perfect automation candidates: same steps, different data, run every release. TC-06 to TC-08 are worth checking manually first, then automating if they've ever broken.

Exploratory Testing Tips

Test cases check what you expected. Exploratory testing finds what you didn't. Run it as a focused session, not random clicking.

• Write a charter: one line such as "Explore the cart with discount codes to find pricing errors." Time-box it to 30–60 minutes.
• Vary the inputs: very long text, emoji, leading spaces, pasted values, negative numbers, past dates.
• Interrupt flows: refresh mid-checkout, press Back, open the same page in two tabs, let the session expire.
• Change the conditions: slow network (DevTools throttling), small screen, zoom to 200%, a different browser.
• Take notes as you go: what you tried, what looked odd, questions for the developer. Odd-but-not-wrong behaviour is still worth asking about.

Automate the Repetitive Parts with Playwright

Once the login cases are stable, there's no reason to type them by hand every release. This Playwright file runs TC-01 to TC-05 from the table above. The negative cases are data-driven: one test body, four rows of data.

const { test, expect } = require('@playwright/test');

const cases = [
  { id: 'TC-02', name: 'locked-out user', user: 'locked_out_user', pass: 'secret_sauce', error: 'Sorry, this user has been locked out.' },
  { id: 'TC-03', name: 'wrong password', user: 'standard_user', pass: 'wrong_password', error: 'Username and password do not match' },
  { id: 'TC-04', name: 'empty username', user: '', pass: 'secret_sauce', error: 'Username is required' },
  { id: 'TC-05', name: 'empty password', user: 'standard_user', pass: '', error: 'Password is required' },
];

test.beforeEach(async ({ page }) => {
  await page.goto('https://www.saucedemo.com/');
});

test('TC-01 valid user logs in', async ({ page }) => {
  await page.getByPlaceholder('Username').fill('standard_user');
  await page.getByPlaceholder('Password').fill('secret_sauce');
  await page.getByRole('button', { name: 'Login' }).click();

  await expect(page).toHaveURL(/inventory\.html/);
  await expect(page.getByText('Products')).toBeVisible();
});

for (const c of cases) {
  test(`${c.id} ${c.name} is rejected`, async ({ page }) => {
    await page.getByPlaceholder('Username').fill(c.user);
    await page.getByPlaceholder('Password').fill(c.pass);
    await page.getByRole('button', { name: 'Login' }).click();

    await expect(page.locator('[data-test="error"]')).toContainText(c.error);
    await expect(page).not.toHaveURL(/inventory/);
  });
}

npx playwright test tests/saucedemo-login.spec.js --project=chromium

Running 5 tests using 5 workers

  ✓  1 [chromium] › tests/saucedemo-login.spec.js:14:1 › TC-01 valid user logs in
  ✓  2 [chromium] › tests/saucedemo-login.spec.js:24:3 › TC-02 locked-out user is rejected
  ✓  3 [chromium] › tests/saucedemo-login.spec.js:24:3 › TC-03 wrong password is rejected
  ✓  4 [chromium] › tests/saucedemo-login.spec.js:24:3 › TC-04 empty username is rejected
  ✓  5 [chromium] › tests/saucedemo-login.spec.js:24:3 › TC-05 empty password is rejected

  5 passed

Remove --project=chromium and the same five cases run in Firefox and WebKit too, which covers part of your compatibility checklist for free. For the full method (choosing what to automate, the test pyramid, API tests and CI), read automated web testing: step by step. For more UI-specific techniques, see web UI testing; for ready-made flows, Playwright script examples.

How to Report Bugs Well

A bug report's job is to let a developer reproduce the problem in minutes without asking you anything. Use the same structure every time:

• One bug per report. Two problems in one ticket means one gets forgotten.
• Describe, don't diagnose. State what happened; let the developer find the cause, unless you're sure.
• Attach a trace when you can. A Playwright trace shows every action, network call and DOM snapshot. See the Trace Viewer tutorial.
• Retest and close the loop. When the fix lands, re-run the steps and, if it's a regression risk, add an automated test for it.

Frequently Asked Questions

Meet Your Instructor

Asim Noaman

Senior QA Automation Engineer & AI Testing Specialist

With years of hands-on experience building test automation frameworks for production applications, Asim specializes in combining traditional QA methodologies with cutting-edge AI tools. He has helped teams adopt Playwright and AI-driven testing workflows to ship faster with fewer bugs.

Udemy Instructor Published course author

Playwright + AI Expert Specialized in AI-powered QA

Production Experience Enterprise-grade frameworks

Connect on LinkedIn