What is different about testing a web app

A great deal of the software a QA tests is a web app — an operational dashboard, an admin console, an internal tool, a customer portal — running in a browser rather than on a phone. Web apps have their own character, their own ways of breaking, and their own testing concerns, distinct from mobile. This lesson is what makes testing a web app different, and the shape of web QA — the foundation for the browser-specific lessons that follow, and for a huge amount of the real testing work you will do.

The web app, and why it differs from mobile

A web app runs inside a browser, is delivered as HTML/CSS/JavaScript over HTTP, and the user navigates pages and URLs. Compared with a mobile app, this changes what you test:

The browser is the runtime, and there are several. The app runs in Chrome, Firefox, Safari, Edge — each a slightly different engine that can render and behave differently (the cross-browser lesson). There is no single "the app"; there is the app in each browser.
The screen is arbitrary and resizable. Unlike a fixed set of phone sizes, a browser window can be any size, on any monitor, at any zoom — the layout must cope (the responsive lesson).
URLs, navigation, and browser controls exist. The back button, forward, refresh, bookmarks, multiple tabs, deep links — all things a mobile app does not have, and all sources of bugs (the browser-behaviours lesson).
It is often data-heavy and operational. Many web apps are dashboards and admin tools — tables of records, filters, sorting, pagination, forms, reports, role-based views — where the testing is about data correctness and manipulation at scale, not a single screen (the dashboards lesson).

So web QA is not "mobile QA on a bigger screen" — it is its own discipline, with cross-browser, responsive, navigation, and data-heavy concerns that mobile does not have (just as mobile has device, connectivity, and lifecycle concerns web does not). A QA needs both, applied appropriately to each.

Operational dashboards: the common web-app shape

A large share of web apps a QA meets are operational dashboards / admin consoles — the internal tools a business runs on. Their character shapes the testing:

Lots of data — tables and lists of records (transactions, users, orders), often thousands of rows.
Manipulating that data — filtering, searching, sorting, paginating, exporting; creating, editing, approving records via forms.
Reports and aggregates — totals, charts, summaries that must be correct (a wrong total on an operational dashboard leads to wrong decisions).
Roles and permissions — different users (operator, manager, admin) see and can do different things — and enforcing that correctly is both a functional and a security concern.

Testing a dashboard is therefore heavily about data correctness (does the table show the right rows, the filter filter correctly, the total add up, the export match?) and access (does each role see and do only what it should?) — a different emphasis from testing a mobile app's flows. The dashboards-and-forms lesson goes deep on this, because it is exactly the kind of web app (an operational console) that QAs spend much of their time on.

What the manual techniques bring, unchanged

The good news: everything from the manual-testing module applies directly to web apps. Deriving test cases, equivalence partitioning and boundary values, exploratory testing, bug reports, severity/priority — these are universal testing skills, and you use them on web apps exactly as on anything else. A web form's amount field gets the same boundary analysis as a mobile one; a web flow gets the same positive/negative/ edge test cases; a web app gets the same charter-driven exploratory sessions. The web-specific lessons (cross-browser, responsive, browser behaviours, dashboards) add the concerns unique to the browser environment on top of that universal foundation — they do not replace it.

The QA's web toolkit

Web apps come with a QA superpower mobile largely lacks: the browser's developer tools, built into every browser (F12 / right-click → Inspect), which let you see and probe what the app is actually doing:

The Network tab — every request the app makes and the response it gets (the API behind the page — the API-testing module). You can see a call fail, a slow response, a wrong payload — often the real cause of a UI bug.
The Console — JavaScript errors and warnings. A red error in the console often explains a broken UI, and spotting it turns "the page is weird" into a precise bug report.
The Elements/Inspector — the actual HTML/CSS, to see why something is laid out wrong or missing.
Device/responsive mode — simulate different screen sizes and even mobile devices (the responsive lesson).
Throttling — simulate a slow network (the connectivity concern, for web too).

A web QA who uses dev tools reports far better bugs — "the page shows an error because the /transactions API returned a 500, here is the response" instead of "the page is broken". Learning to open the Network tab and Console and read them is one of the highest-leverage web-testing skills, and the browser-behaviours lesson returns to it.

Check your work

What differs. A web app runs in a browser (several, each different — cross-browser), on an arbitrary resizable screen (responsive), with URLs and browser controls (back/refresh/tabs/deep links), and is often data-heavy and operational (dashboards). Web QA is its own discipline, not "mobile on a bigger screen" — as mobile has its own (devices, connectivity, lifecycle).

Operational dashboards. A common web-app shape — lots of data, manipulation (filter/sort/paginate/ export), forms, reports/aggregates (must be correct), and roles/permissions. Testing emphasises data correctness and access.

Manual techniques carry over. Test-case derivation, equivalence/boundary, exploratory, bug reports, severity/priority are universal — used on web unchanged; the web-specific lessons add browser-environment concerns on top.

The web toolkit. The browser dev tools (Network, Console, Elements, device mode, throttling) let a QA see what the app actually does — report "the /transactions API returned 500" not "the page is broken". Reading Network and Console is a top web-testing skill.

Practice

Take a web app you use and list what makes testing it different from a mobile app (browsers, resizable screen, navigation controls, data-heavy screens).
For an operational dashboard you know, list the data-correctness and access things a QA would check (table rows, filters, totals, role visibility).
Apply a manual technique from module 2 (say, boundary values) to a web form field, unchanged.
Open a web app's dev tools: watch the Network tab as you do an action, read the Console for errors, and inspect an element — note what each reveals.
Use the dev tools to turn a vague "the page is broken" into a precise bug ("the X request returned a 500, here is the response").
List the browser-specific concerns (cross-browser, responsive, navigation, dashboards) this module will add on top of your manual foundation.

Official documentation

MDN — Web app testing / cross-browser overview — What web testing involves.
Chrome DevTools documentation — The Network, Console, Elements and device tools a web QA lives in.
Ministry of Testing — Web testing — Practitioner guidance on testing web apps.

Next: cross-browser testing, and why browsers differ.