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 called the DOM. Let's go through each one in plain words.

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 can check what's actually there — for example, whether a field is marked as required, or 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 that a tester's eye catches.

Why a tester needs this: understanding that "displays incorrectly" is usually a CSS problem, not a logic one. And that CSS may behave differently on different screen sizes.

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's useful to know that it's responsible for 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. So if you look at the page source (right-click → "View page source"), it may not contain what you see on screen — but the Elements tab (which shows the DOM) will.

Why a tester needs this: when something "appeared" or "disappeared" on the page without a reload, the DOM changed. To see the current state, check the Elements tab, not the page source HTML.

Where this applies

These basics come up every time you test the web. 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 the DOM in the Elements tab. Understanding how a page is built, you describe bugs more precisely ("the field isn't marked as required in the markup," "there's a JS error in the console on submit") and use DevTools with more confidence.

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: HTML (structure), CSS (appearance), JS (behavior), DOM (live state).

What to learn next. A page is half the picture. The other half is how it communicates with the server: client-server and HTTP, then practice in DevTools and Postman.