How the Web Works for Testers

For seven chapters you've tested Fernway through its screens. But between the screen and the answer there's a whole relay — browser, network, server, database — and every leg of that relay is a place where a bug can actually live. A tester who can name the legs can locate bugs, not just witness them — and "locates, not just witnesses" is the single biggest credibility jump available to a junior. This chapter makes that jump; this page builds the map it needs.

Client and Server

Two words carry everything. The client is the program asking — your browser, or the Fernway mobile app. The server is a program answering — built up gently, because this book promised no assumed background: a server is just a program running on an always-on computer in a data center, whose whole job is to wait for requests and answer them. When you open Fernway, your browser (client) asks a Fernway server for the page; the server figures out the answer — consulting the database, the organized storage where all the bookings and travelers live — and sends it back. Ask, compute, answer. That's the web, and everything else is detail on that skeleton.

The Request/Response Cycle

Now the same story in the vocabulary you'll use daily. You type a destination and click Search. The browser composes a request — a structured message saying, in effect, "give me stays in Lisbon, Nov 10–13, 2 guests" — and sends it across the network to Fernway's server. The server does the work: checks the database, applies the rules, assembles an answer. Back comes the response: a status code (a three-digit summary of how it went — one minute, they get their own section) plus the data — the matching stays. The browser takes that data and renders it: turns it into the pixels you see. One full round trip, repeated dozens of times per page, hundreds of times per session. Every leg — compose, send, compute, respond, render — can be the leg that breaks.

The restaurant, one last time, now end-to-end: you (the browser) give your order to the waiter (the network), the kitchen (the server) checks the pantry (the database) and cooks, and the dish comes back — or a "sorry, we're out of that," or, on a truly bad night, a fire alarm. Where exactly the evening went wrong determines who you talk to. Hold that thought; it's about to become your triage skill.

Browser → requestis the right question being asked?

→

Networkdid the question arrive?

→

Server + databaseis the answer computed right?

→

Response → renderis the right answer shown right?

Status Codes: the Server's Tone of Voice

Every response carries a three-digit status code, and you need the families, not a memorized list. 2xx — fine: 200 is the everyday "here's your answer." 4xx — your request was the problem: 404 means no-such-thing (the URL points nowhere), 400 means the request itself was malformed, 403 means you're not allowed. 5xx — the server itself broke: 500 is the kitchen fire alarm — the request was fine; the server choked on it. Here's why the families matter more than the numbers: 4xx-versus-5xx is the first clue about whose bug you're looking at. A 4xx says the client sent something wrong — look at what the frontend composed. A 5xx says the server failed at its own job — the backend has a problem, whatever the screen looks like. One glance at a code, and your investigation already has a direction.

Frontend Bug or Backend Bug?

Now the triage instinct this page exists to build. Three patterns cover most cases. Wrong data, rendered nicely — the page looks perfect and the numbers are wrong: the server computed a wrong answer; backend. Right data, rendered wrongly — the server sent Nov 13 and the screen shows Nov 14 (hello, FW-312): the rendering leg broke; frontend. The request never went out, or went out wrong — the server never got a fair question: frontend again, at the compose leg. You can't always see which pattern you're in from the screen alone — which is exactly what the next topic's tools are for — but knowing the three patterns turns "it's broken" into "I know which half to suspect," and that sentence changes how developers hear you.

One honest flag before the tour continues: this page skipped real machinery — DNS, caching layers, content delivery networks all live between browser and server, and each can host its own bugs. The full relay is the Networking Deep Dive course's whole book; this simplified map is honest as far as it goes, and it goes as far as a junior web tester needs.

The First Bug You Locate

The payoff, immediately. A traveler-facing search for Saltwater Lodge shows no results — "search is broken," says the ticket. Old you would have re-filed that sentence with better formatting. New you asks: which leg? The page renders fine (render leg OK). The server answers other searches (server leg probably OK). So — what did the request actually ask? Next topic gives you the X-ray to see it, and the answer will turn out to be a frontend bug with a stale date, FW-380 — located, not witnessed. That's the chapter's arc: this page gave you the map; the next four give you the instruments.