← back to the section

A web application tester works with pages in a browser every day. To understand what you're actually checking, it helps to know what a page is made of — not at a developer's level, but enough that words like "layout," "element," and "script" don't feel scary, and so you can use developer tools with confidence.

Every web page rests on three technologies: HTML defines the structure, CSS defines the appearance, JavaScript defines the behavior. And what actually lives in the browser and changes in real time is the DOM.

address entered — the browser assembles the page page source: from the server DOM — tree in the browser data server <table id="orders"><tr>Order 41</tr></table> parsehtmlbodytableOrder 41 markup, no stylesLog in Log instyles.css:look, not structure scriptGET /api/orders200 · order 42 dataOrder 42"Order 42" not in source where the tester sees itElementsrow "Order 42" is thereConsolescript errorsNetworkGET /api/orders · 200

The browser received the markup and assembles the rest itself: HTML is parsed into the DOM tree, styles change how the button looks but not the structure, the script goes for data and draws a second row. That row is not in the page source — it lives only in the DOM. At the bottom, three developer tools tabs: one per step.

HTML — the structure of a page

HTML (HyperText Markup Language) is the markup that tells the browser what a page is made of: where the heading is, where the paragraph is, where the button is, where the image is. It describes content and structure, but not the visual appearance.

HTML is made up of tags — commands inside angle brackets. For example:

<h1>Heading</h1>
<p>A paragraph of text.</p>
<button>Log in</button>
<input type="email" placeholder="Your email">

Here <h1> is a heading, <p> is a paragraph, <button> is a button, <input> is an input field: every visible piece of the page is some kind of tag. Tags can have attributes (type="email", placeholder="...") — additional properties.

Why a tester needs this: in the Elements tab you see exactly the HTML structure and check what's actually there — whether a field is marked as required, whether the text matches the design mockup.

CSS — the styling

CSS (Cascading Style Sheets) is responsible for appearance: colors, fonts, spacing, sizes, layout. The same HTML with different CSS looks completely different.

CSS rules look like this:

button {
  background: green;
  color: white;
  padding: 10px 20px;
}

"Buttons are green, text is white, with these padding values." It's because of CSS that a button can slide off the edge on a phone, or text can overlap an image — these are classic layout bugs.

JavaScript — the behavior

JavaScript (JS) adds behavior to a page: what happens when you click a button, type text, or scroll. Without JS a page is static; with it the page reacts to actions — it shows hints, validates forms, loads data without refreshing.

A tester doesn't need to write JavaScript, but it helps to know that it owns the "dynamic" side: if a button doesn't fire, a form silently freezes, or data doesn't appear — the cause is often a JavaScript error. These errors show up in red in the console, and a screenshot of them is gold for a bug report.

DOM — the live tree of a page

When a browser loads HTML, it builds from it a DOM (Document Object Model) — a "live" tree of page elements in memory. The key distinction: HTML is what came from the server, and the DOM is what is actually on the page right now.

This difference matters because JavaScript modifies the DOM: it adds rows to a table, shows an error, hides a block. Here is the same swap in code: the server sent one table row, the script drew the second one.

live example

const source = '<table id="orders"><tr><td>Order 41</td></tr></table>';
const rows = ['Order 41'];
rows.push('Order 42');
const dom = '<table id="orders">' + rows.map(r => `<tr><td>${r}</td></tr>`).join('') + '</table>';
console.log('page source:', source);
console.log('DOM right now:', dom);
Run

Running examples is part of paid access. There the same code runs inside the article: editor, run and check next to the paragraph. Three free days →

The first printed line is what "View page source" shows, the second is what the Elements tab shows. So "it's not in the page source" proves nothing: if something appeared without a reload, a script added it — look in the DOM.

Where this applies

A button drifted out of place — you think about CSS. A form isn't responding — you check the console for a JavaScript error. You need to see what's actually on the page — you open Elements. And when you describe the bug, you name the part: "the field isn't marked as required in the markup," "there's a JS error in the console on submit."

Where beginners stumble:

  • Confusing the page source HTML with the DOM. "It's not in the page source" — because the element was added by JavaScript; look in the Elements tab.
  • Being afraid of layout and writing bugs like "everything is broken." More useful: "on a 375px screen the button goes past the edge" — that's about CSS and responsiveness.
  • Thinking they need to know how to program. No — it's enough to understand the roles: structure, appearance, behavior, live state.

In short

  • HTML owns the structure, CSS the appearance, JS the behavior; the symptom usually tells you whose part it is.
  • A tag is a visible piece of the page, an attribute is its property: "the field is required" is visible in the markup, not by eye.
  • "It displays wrong" is almost always CSS rather than logic, and on another screen the same CSS behaves differently.
  • The page source is what came from the server; the DOM is what is on the page now. They diverge exactly where a script worked.
  • The current state is read in the Elements tab, script errors in the console, data requests in the Network tab.