Browser behaviours: back, refresh, tabs, sessions and dev tools

A web app lives inside a browser, and the browser gives the user controls a mobile app never has — a back button, forward, refresh, the address bar, multiple tabs, bookmarks, sessions that time out. Users press all of these, in every order, and each one is a source of bugs the developer (who navigates by clicking the app's own buttons) never triggers. This lesson is testing browser behaviours — and the browser dev tools that make a web QA far more effective.

Back, forward and refresh: the buttons the developer forgets

The developer builds a flow by clicking through it — page to page via the app's own links and buttons. Real users instead press the browser's buttons, and that is where things break:

Back button — the classic. Fill a form, submit it, press Back: does the app show a sensible state, or a stale/broken page, or re-submit? Go three pages deep and press Back repeatedly: does each step work? Back after logging out (does it show a cached logged-in page it should not)? Back is the single most under-tested navigation and a rich source of bugs.
Forward — after going Back, press Forward: does the app recover correctly?
Refresh (F5) — refresh in the middle of a flow (halfway through a multi-step form, on a filtered list): does it keep the state or lose it, and either way behave sensibly (not error, not resubmit)? A refresh on a "payment processing" page is a high-stakes case — does it double-charge (the money-flow concern, for web)?
Re-submitting a form — Back then re-submit, or refresh after submit: does it create a duplicate record? The browser even warns "resend form data?" — test what happens on each choice.

These are pure web concerns, invisible to the developer clicking the happy path, and they catch real bugs (stale pages, lost state, double submissions) — so a web QA tests every flow with the browser buttons, not only the app's own.

URLs, deep links and the address bar

The URL is part of a web app's interface, and users edit it, bookmark it, and share it:

Direct URL / deep link — type or paste a URL to an inner page (a specific transaction, a filtered view) without navigating there through the app: does it load correctly, or assume you arrived via the previous page and break?
Bookmark / refresh a deep link — a bookmarked inner page must still work days later (or redirect sensibly to login).
URL as state — many apps put state in the URL (?status=pending&page=2): does editing it work, and does an invalid URL parameter fail gracefully rather than crashing?
Access via URL — can a user reach a page they should not by typing its URL (the role/permission concern — a hidden button is not access control; the URL must be blocked too)?
Invalid / old URLs — a mistyped or deleted-record URL should show a clean "not found", not a raw error.

Deep-linking bugs (an inner page that only works if you came from the previous one) are common and only found by going straight to the URL — so test inner pages by their URL directly, not just by clicking in.

Tabs, sessions and timeouts

Two more browser realities:

Multiple tabs. Users open the app in several tabs. Test: the same record open in two tabs and edited in both (does the second save clobber the first, or warn — the concurrency concern, for web); logging out in one tab (do the others notice); two tabs on different filtered views (do they interfere via shared state?). Multi-tab bugs are subtle and real.
Sessions and timeouts. Web apps log you out after inactivity. Test: leave the app idle past the timeout, then act — does it redirect cleanly to login (not error, not silently fail, not lose your unsaved work without warning)? Log in again — does it return you sensibly? An expired session hit mid-action (submitting a form after the session died) is the case that breaks ugly, so test it.

The dev tools: a web QA's most powerful instrument

The browser's developer tools (F12, or right-click then Inspect) are the single biggest advantage web testing has over mobile, and using them is what separates a vague bug report from a precise one:

Network tab — every request the page makes and every response. When the UI misbehaves, the Network tab usually shows why: a call returned a 500, a 403 (a permission bug), a slow response, or a wrong payload. "The list is empty because GET /transactions returned a 500, here is the response body" is a report a developer can fix immediately.
Console — JavaScript errors and warnings. A red console error frequently explains a broken UI; quoting it turns "the page is weird" into a precise cause.
Elements / Inspector — the live HTML and CSS, to see why a layout is wrong or an element is missing.
Application/Storage — cookies, local storage and session data — useful for session and login bugs.
Network throttling and offline — simulate a slow or dropped connection (the connectivity concern applies to web too): does the app show a spinner, time out cleanly, or hang forever?

A web QA who opens the Network tab and Console on every bug reports causes, not just symptoms — and a bug report with the failing request and status code, or the console error, is the difference between a bug fixed today and one bounced back as "cannot reproduce". Learning to read Network and Console is the highest-leverage web-testing skill there is.

Check your work

Back/forward/refresh. Test flows with the browser buttons, not just the app's own: Back (after submit, after logout, repeatedly), Forward, Refresh mid-flow (keeps or loses state sensibly; no double-charge on a payment page), and form re-submission (Back-then-resubmit / refresh-after-submit creating duplicates). These are invisible to the developer clicking the happy path.

URLs/deep links. Load inner pages directly by URL (deep links that break if you did not arrive via the previous page); bookmark/refresh them; edit URL state params (invalid ones fail gracefully); confirm URL access respects permissions (a hidden button is not access control); invalid/old URLs show clean "not found".

Tabs/sessions. Multiple tabs (same record edited in two — clobber or warn; logout in one; shared state); session timeout (idle then act redirects cleanly; expired session mid-action does not break ugly or lose work silently).

Dev tools. The web QA's key instrument — Network (the failing request/status behind a UI bug: 500, 403, slow, wrong payload), Console (JS errors explaining a broken UI), Elements (why layout/missing), Application/Storage (session/login), throttling/offline. Report causes ("GET /transactions returned 500"), not symptoms.

Practice

Take a multi-step flow and test it with the browser Back button at each step, including Back after submitting; note anything stale, broken, or re-submitted.
Refresh the page in the middle of a form and on a filtered list; check the state is kept or lost sensibly, with no error or duplicate.
Copy the URL of an inner page, open it in a fresh tab directly, and see whether it loads or assumes you came from the previous page.
Edit a URL state parameter to an invalid value and confirm it fails gracefully; try reaching a role-restricted page by its URL.
Open the same record in two tabs, edit both, and see whether the second save warns or clobbers the first.
Leave the app idle past its session timeout, then submit an action; check it redirects cleanly. Then open the dev tools Network tab and Console during a bug and write the report from the failing request/error, not the symptom.

Official documentation

Chrome DevTools — Network features — Reading the requests and responses behind a UI bug.
Chrome DevTools — Console overview — Finding the JavaScript errors that explain broken pages.
MDN — Session and history navigation — How back/forward/history behave, and why apps break on them.

Next: the mobile-testing module — testing apps on real devices, networks and the phone's lifecycle.