Table of Content
What should you test in a web application before release?
Test the money paths first (sign-up, login, search, checkout or the main form), then the browsers and devices your visitors really use, then performance, accessibility and security basics. Run unit and API checks on every commit, a fuller regression pass on a staging build, and a short smoke test right after release. Depth should follow risk, not habit.
TL;DR
- Web application testing (often called web app testing) is not one activity. It is a set of checks that belong at different stages: while building, before merge, on staging, on release day and after release.
- This guide gives a checklist for each stage, plus the types of testing it covers and the free or common tools people use for each.
- In our worked example, scoring areas by change and impact turns an 8-hour test budget into a clear plan, with most of the time on the checkout and login changes.
- Browser coverage should come from your own analytics. In the example, seven browser and device combinations cover 91% of sessions; the rest is a long tail you handle by exception.
- Use published thresholds where they exist: Google’s Core Web Vitals “good” values and WCAG 2.2 level AA for accessibility.
- Examples and shares in the worked sections are illustrations built for this guide, not measured results.
- CommercePundit runs web and mobile QA for product teams. See the last section.
What types of web application testing are there?
| Type | What it checks | When it runs | Common tools |
|---|---|---|---|
| Unit and component | One function or UI component behaves correctly | Every commit | Jest, pytest, JUnit |
| API and integration | Endpoints return the right data and errors; services work together | Every commit and on staging | Postman, REST Assured, Playwright API tests |
| Functional (end to end) | A user journey works from browser to database | Pre-merge for key paths, full on staging | Playwright, Cypress, Selenium |
| Cross-browser and responsive | Layout and behavior across browsers, devices and screen sizes | Staging, before release | Playwright, BrowserStack-style device clouds, real devices |
| Performance testing | Pages load quickly and the system holds under traffic | Staging, and after big changes | Lighthouse, k6, JMeter |
| Accessibility | People using keyboards and screen readers can complete tasks | Design review and staging | axe-core, Lighthouse, manual keyboard and screen reader checks |
| Security testing | Common weaknesses such as broken access control and injection | Pipeline scans plus a periodic deeper test | OWASP ZAP, dependency scanners, manual review |
| Usability and exploratory | Whether real people understand and finish the task | Before big launches | Moderated sessions, session recordings |
| Regression | Old features still work after a change | Every release | Automated suite plus a short manual pass |
If you are new to the term, a web application (web app) is software that runs in a browser and keeps state on a server, such as a customer portal, booking system or store. Our guides to what a web application is and how businesses build web applications give the background.
Web application testing checklist by release stage
Stage 1: While building
- Unit tests cover new logic, including the error paths and boundary values (empty, maximum length, zero, negative).
- Each new API endpoint has a test for success, validation failure, unauthorized access and a missing record.
- Forms validate on the server as well as in the browser, and show a clear message in each failure case.
- Secrets, API keys and test credentials are not in the repository or in front-end code.
- New dependencies are checked for known vulnerabilities before they are merged.
Stage 2: Before merge
- The build is green and the automated tests for the touched areas pass.
- A reviewer has run the change locally or on a preview environment, not only read the code.
- Database migrations run forward on a copy of production-like data, and you know how to roll them back.
- Any change to login, payment, permissions or personal data has a second reviewer.
- New or changed behavior has a test, or a written reason why not.
Stage 3: On staging, before release
| Area | Check |
|---|---|
| Core journeys | Sign up, log in, log out, reset password, search, add to cart or submit the main form, pay, receive the confirmation email |
| Permissions | A normal user cannot open an admin URL or another user’s record by editing the address or an ID |
| Cross-browser | The key journeys pass on the browsers in your coverage matrix (see below) |
| Responsive layout | No horizontal scroll at phone width, tap targets are usable, the menu and forms work on a touch screen |
| Performance | Largest content on the main pages appears within the budget; pages stay usable on a throttled mobile connection |
| Accessibility | Every key journey works with a keyboard only, focus is visible, images and form fields have labels, color contrast passes |
| Error handling | A 404 page, a server error page and an expired session each show a helpful message, not a stack trace |
| Data | Imports, exports, file uploads and emails work with realistic data, including accented characters and long values |
| Integrations | Payment, email, analytics and any third-party script behave in the sandbox or test mode |
| Regression | The automated regression suite passes and a person has spot-checked the riskiest old features |
Stage 4: Release day
- A smoke test of five to ten critical journeys runs on production right after deployment (log in, search, buy or submit, and one admin action).
- Monitoring and error tracking are live, and someone is watching them for the first hour.
- Analytics events and conversion tracking fire on the new pages.
- The rollback plan is written down and the person who can execute it is available.
- Caches and CDN settings are checked so visitors do not see a mix of old and new files.
Stage 5: First 48 hours after release
- Compare error rate, page speed and conversion to the previous week.
- Read support tickets and chat transcripts for new complaints.
- Check server logs for unusual 4xx and 5xx patterns.
- Add a regression test for every bug found in production so it cannot come back.
For product teams building a first version, our guide to MVP development shows how much of this checklist to apply at each stage of a young product.
How do you decide how much to test? A worked example
You rarely have time to test everything. A simple way to size testing is to score each area of the release by how much it changed (1 low, 3 high) and how much damage a bug would do (1 low, 3 high), multiply the two, and split your test time in proportion. The release below and its scores are an illustration.
| Area in this release | Change (1 to 3) | Impact (1 to 3) | Score | Hours of an 8-hour test budget |
|---|---|---|---|---|
| Checkout and payment | 3 | 3 | 9 | 3.0 |
| Login and permissions | 2 | 3 | 6 | 2.0 |
| Search filters | 3 | 2 | 6 | 2.0 |
| Product page layout | 2 | 1 | 2 | 0.7 |
| Footer links | 1 | 1 | 1 | 0.3 |
| Total | 24 | 8.0 |
Checkout and payment gets 3.0 hours because it changed a lot and a bug costs real money. Footer links get 0.3 hours, which is a quick look. Anything with a score of 6 or more gets a full journey test on every browser in the matrix; scores of 3 or 4 get the main path plus error cases; scores of 1 or 2 get a visual check. Adjust the tiers to your team, but write them down so the same logic applies every release.
Which browsers and devices should you test?
Do not guess from a vendor chart. Open your own analytics, list sessions by browser and device, and cover the combinations that add up to roughly 90% of sessions. The shares below are made up for illustration. With them, 7 combinations reach 91%.
| Browser and device | Share of sessions | Cumulative share |
|---|---|---|
| Chrome on Windows | 31% | 31% |
| Chrome on Android | 18% | 49% |
| Safari on iPhone | 17% | 66% |
| Chrome on macOS | 8% | 74% |
| Safari on macOS | 7% | 81% |
| Edge on Windows | 6% | 87% |
| Samsung Internet on Android | 4% | 91% |
Add exceptions on top: any combination that your support tickets mention, and any where a payment or login widget is known to behave differently. Re-check the list each quarter. On iPhones, browsers have long been required to use the Apple rendering engine (rules differ in some regions), so Chrome on iPhone usually behaves like Safari on iPhone for layout; keep one real iPhone in the lab rather than relying on emulators alone. For native apps and phone-specific behavior see our mobile testing services.
What performance and accessibility thresholds should you use?
| Measure | What it means | Published “good” value |
|---|---|---|
| Largest Contentful Paint (LCP) | Time until the main content appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page responds to taps and clicks | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading | 0.1 or less |
| WCAG 2.2 level AA | The accessibility standard most legal and procurement requirements reference | All level A and AA criteria met for your key journeys |
The three Core Web Vitals values are the thresholds Google publishes for a “good” experience, assessed at the 75th percentile of real visits. Measure with lab tools during testing and with real-user data after release, because lab results on a fast laptop flatter the experience of a phone on mobile data. Automated accessibility tools catch only a share of problems, so always add a keyboard-only run through each key journey.
What are the security basics to check?
| Check | What to try | Why |
|---|---|---|
| Broken access control | Change an ID in the URL or request to another user’s record; open an admin page as a normal user | The most common serious flaw in web applications |
| Authentication | Weak password rules, no lockout, reset links that never expire, sessions that survive logout | Accounts are the main target |
| Input handling | Send quotes, angle brackets, SQL fragments and very long strings into every field | Finds injection and cross-site scripting |
| File upload | Upload an oversized file, a wrong type and a renamed script | Prevents stored attacks and storage abuse |
| Transport and headers | HTTPS everywhere, secure cookies, standard security headers | Cheap protection against common attacks |
| Dependencies | Run a dependency scan in the pipeline | Known vulnerabilities in libraries are a frequent entry point |
| Rate limits | Hammer login and search endpoints | Stops credential stuffing and scraping |
The OWASP Top 10 is the standard reference list for web application risks, and OWASP ZAP is a widely used free scanner. A scanner is a baseline, not a penetration test. For store platforms see our guides to Shopify security and Magento security best practices.
What should you automate, and what should stay manual?
| Automate | Keep manual |
|---|---|
| Repeated journeys that must pass every release (login, checkout, core forms) | Exploratory testing of new features |
| API checks and data validation | Visual polish and “does this feel right” judgment |
| Cross-browser runs of the key journeys | Accessibility checks with a screen reader |
| Performance budgets in the pipeline | Usability sessions with real users |
| Dependency and basic security scans | Business-logic security review |
Automate what is stable and repeated; leave new, changing or subjective checks to people. Our automation testing services build and maintain these suites, and our overview of the challenges of test automation in retail covers why suites rot when nobody owns them. If you are choosing a QA partner, see the top software testing companies in the US.
What mistakes make web testing fail?
| Mistake | What happens | Fix |
|---|---|---|
| Testing only the happy path | Errors, expired sessions and bad input reach customers | Write a failure case for every journey |
| Testing only in Chrome on a fast laptop | Phone and Safari users hit bugs first | Build the matrix from your own analytics |
| Treating staging as a different world | Bugs appear only in production data or settings | Keep staging config and data shape close to production |
| Everything is a priority | Nothing is tested deeply | Score by change and impact, as in the worked example |
| No owner for the automated suite | Flaky tests are ignored until nobody trusts them | Assign an owner and fix or delete flaky tests within a sprint |
| No smoke test after deploy | You learn about the outage from a customer | Run a ten-minute production smoke test every time |
Frequently Asked Questions
What is web application testing?
Web application testing is the set of checks that confirm a browser-based application works correctly, performs well, is accessible and is secure. It covers functionality, compatibility across browsers and devices, performance, accessibility and security.
What are the main types of web application testing?
The main types are unit, API and integration, functional end-to-end, cross-browser and responsive, performance, accessibility, security, usability and regression testing. Each belongs at a different point in the release process.
How do you test a web application step by step?
Test logic and APIs while building, run automated checks before merging, do a fuller pass on staging that covers journeys, browsers, performance, accessibility and security, smoke test right after release, and monitor for two days. Add a test for every production bug.
Which browsers should I test my web application on?
Use your own analytics to list sessions by browser and device, then cover the combinations that add up to about 90% of sessions. Add any combination your support tickets mention and re-check quarterly.
What tools are used for web application testing?
Common choices are Playwright, Cypress and Selenium for browser automation, Postman for APIs, Lighthouse and k6 for performance, axe-core for accessibility and OWASP ZAP for basic security scanning. Pick tools your team will maintain.
Should web application testing be manual or automated?
Both. Automate stable, repeated journeys, API checks and scans. Keep exploratory testing, usability and screen reader checks manual, because they depend on human judgment.
How long does web application testing take?
It depends on the size and risk of the release. A useful method is to set a fixed test budget and split it by change and impact, so high-risk areas get most of the time. A production smoke test should take about ten minutes.
What is the difference between functional and non-functional testing for a web application?
Functional testing checks that features do what they should. Non-functional testing checks qualities such as speed, accessibility, security and compatibility. A feature can pass the first and fail the second.
What is the difference between smoke testing and regression testing?
A smoke test is a short check that the most critical functions work after a build or deployment. Regression testing is a broader pass that confirms old features still work after a change.
Bottom Line
Good web application testing is a schedule of checks matched to risk: unit and API tests as you build, a fuller pass on staging, a smoke test on release day and a short watch afterward. Size effort by change and impact, build the browser matrix from your own analytics, and use published thresholds for speed and accessibility. If you want a team to set up the suites and run the passes for you, talk to us about our software testing services.
