QA interview questions on DevTools
A junior QA interview almost always includes questions about DevTools: how to find the cause of a defect, what the Network tab shows, how a cookie differs from local storage. The questions below are grouped by the eight topics of the trainer, each with an answer and a link to the material that covers it. Try answering before opening the answer — that is what shows which topics are worth going back to.
Inside every topic the questions are split by level: junior is entry-level knowledge, middle a more advanced one.
On this page
DevTools basics and what they help with
An interview is rarely interested in a list of the DevTools tabs. What is asked is how they are used to investigate a problem. Try answering before opening the answer.
juniorentry-level knowledge
1. What are DevTools and what does a QA engineer need them for?
DevTools are the developer tools built into the browser. They show the markup and styles of a page, JavaScript errors, requests to the server and the data held in the browser. A tester uses them to gather the facts about a defect and to work out which part of the system it comes from.
2. A button does not respond to a click. Where do you start?
Open DevTools before repeating the action. Look at Console first: a JavaScript error may appear there. Then check Network: whether a request was sent and what the server returned.
3. A list of data is missing from the page. What can the Network tab tell you?
Whether a request for the data was made at all, what address it went to, with which method, and what status and response body came back. If no request appears, the problem may be on the client; if the server returned an error or the wrong data, the cause lies before the list is drawn.
4. What does localising a defect mean?
Working out which part of the system the problem occurs in: the interface, JavaScript, the request or the server. The exact cause does not have to be found, but the observations are worth attaching — the error from Console, the request status and the server response.
middlea more advanced level
5. Why do you open DevTools before reproducing the problem?
The Network tab records requests from the moment DevTools is opened. Opened after the page has loaded or after the click, the request you need may already be missing from the list. So DevTools goes first, and the action is repeated afterwards.
6. The site forgets the selected language after a reload. Which tab do you open?
Application: it shows what the site stored in the browser. What to check is whether the selected value was written to a cookie or to storage at all, and whether it survives the reload. The symptom picks the tab in general: data did not load — Network; nothing happens on a click — Console; an element does not look like the design — Elements.
The topic is covered in What DevTools are.
Requests, responses and status codes
What is usually asked for is not a memorised definition but reasoning about a specific request. Try answering before opening the answer.
junior
1. What does an HTTP request consist of?
A method, a URL, headers and, where needed, a body. A POST request, for example, may send JSON in the body while the headers carry the content type and an authorization token.
2. What is the difference between the 401 and 403 response codes?
401 Unauthorized means the user is not authenticated: not signed in, or holding a token that is no longer valid. 403 Forbidden means the user is identified but has no permission for this action.
3. What do 4xx and 5xx statuses usually indicate?
4xx usually points to a problem in the request: wrong data, missing authentication or permissions, an address that does not exist. 5xx means the server failed to process a valid request. It is a direction for localisation, not a final diagnosis.
4. What is the difference between GET and POST?
GET asks for data and must not change it: the parameters travel in the address, the request normally has no body, and the link can be bookmarked or passed on. POST sends data to the server in the request body — usually to create something — and sending it again normally creates another record.
5. What is the difference between PUT and PATCH?
PUT replaces the whole resource: the body carries the complete set of fields, and whatever is missing from it the resource loses. PATCH changes only the fields it carries — a body of {"price": 79.99}, for instance, changes the price of a product and touches nothing else.
middle
6. Is a 200 enough to call a response correct?
No. 200 OK confirms the HTTP request was processed, but Response may still carry empty, stale or someone else's data, or a logical error inside the body. The body has to be compared with the expected result.
7. The page shows no orders although the request returned 200. How do you investigate?
Open the response body. If the correct list of orders is there, the problem is most likely in how the frontend processes or displays the data. If the list is already empty or wrong, the defect occurred earlier — in the data, in the request or on the server.
8. A user clicked “Place order” twice and got two orders. What does the Network tab show?
Two identical POST requests, both with a 2xx status: the server dutifully created two records. A repeated POST is supposed to behave that way — unlike PUT and DELETE, where repeating leaves the system as it was. So the request itself is not the defect: there is no protection against a double submission, neither a disabled button nor a check on the server. Both requests and both responses go into the report.
The topic is covered in Request and response.
The Network tab
These questions check whether the request list can be used to decide which side a defect is on, and whether the data for a report can be collected from it. Try answering before opening the answer.
junior
1. What is Preserve log for?
It keeps the request list across reloads and redirects. Without it, the request that caused the navigation — a form submission that redirects, for example — is cleared along with the previous page, and that is usually the one request worth looking at.
2. What do you attach to a defect report from the Network tab?
The status code, the request body and the response body: the three elements that make a report reproducible. The request itself is easiest to take with a right click → Copy → Copy as cURL, which produces the exact request that was sent and can be replayed from a terminal.
3. What can you look at inside a single request?
A request unfolds on a click, and inside it there are several tabs:
- Headers — the method, the full URL, the status code and the headers: what the browser sent and what the server returned.
- Payload — the request body and the query parameters.
- Response — the raw response; Preview is the same data formatted, which is easier to read for JSON.
- Timing — how the time was spent across the phases of the request, used when a response is slow.
middle
4. How do you tell from the Network tab which side the defect is on?
Compare the response body with what the page displays. If the server returned the correct data and the screen does not show it, the defect is on the frontend. If the data is already wrong in the response, the cause lies earlier: in the request the page sent, or on the server.
5. What does a red row without a status code mean?
That no response was received at all. The reason is in the row itself:
- (failed) — no connection, the host name did not resolve, or the server is not running.
- CORS error — the response arrived, but the browser did not pass it to the page: the permission headers are wrong.
- (blocked:…) — an extension, an ad blocker or the page security policy stopped the request.
- (canceled) — the request was interrupted, usually by navigation. In most cases this is not a defect.
6. How do you make sure you are testing the current version and not the cache?
Turn on Disable cache while DevTools is open, or do a hard reload. In the Size column, a response served from the cache shows from disk cache or from memory cache instead of a size — a sign the file never came from the server.
The topic is covered in The Network tab.
Elements and markup
What is checked here is whether markup can be read and used to verify an interface. Try answering before opening the answer.
junior
1. How do you find an element quickly, on the page and in the markup?
Press ctrl shift c / cmd shift c and click the element on the page: DevTools selects it in Elements. Inside the tree, ctrl f / cmd f opens a search that accepts text, a CSS selector or an XPath.
2. Can you fix text or CSS in the Elements tab?
Yes, but only locally, in your own browser: text, a CSS property or a whole element can be changed or removed to test a hypothesis. The changes never reach the server, no one else sees them, and they disappear on reload.
3. How do you check a responsive layout in DevTools?
Open the device toolbar with ctrl shift m / cmd shift m and walk the page through different widths, especially around the breakpoints. What to confirm: nothing runs off the screen, every control stays reachable, columns rearrange as expected and no horizontal scrollbar appears.
middle
4. How does the DOM in the Elements tab differ from the source HTML?
Elements shows the current DOM tree, after the browser has built the page and JavaScript may have altered it. The source HTML is the document the server returned. If a value is in the DOM but absent from the source HTML, a script put it there.
5. Why can a button built from a div be a defect?
A styled <div> can look like a button while getting none of the standard semantics, focus or keyboard handling. An action needs a <button>, or the developer has to implement every missing property by hand.
The topic is covered in The Elements tab.
Console and JavaScript errors
These check whether an error can be read, and whether a defect of the page can be told apart from noise that belongs to something else. Try answering before opening the answer.
junior
1. What do the red and yellow lines in Console mean?
Red lines are errors: execution stopped, and on the page that usually shows up as a control that does nothing. Yellow lines are warnings, which on their own rarely break anything. The rest are messages the page writes itself through console.log.
2. What do you take from an error for a defect report?
The type and text of the error, for example TypeError: Cannot read properties of undefined, the file and line number shown on the right, and the first line of the call stack, which unfolds when the entry is expanded.
3. How do you leave only errors in Console and keep them across a navigation?
The level selector limits the output to Errors and the field next to it filters by substring. To stop entries disappearing, turn on Preserve log: without it the error is cleared along with the previous page — which is exactly the case when the defect involves a form submission or a redirect.
middle
4. A button does not work and Console shows an error. Is the defect found?
The error is a fact for the report, not yet the cause. First make sure it belongs to this action: clear the console, repeat the action and see what gets written. Then check Network — whether a request went out and what the server returned.
5. Why does not every error in Console belong to the site?
Browser extensions, analytics scripts and ad blockers write their errors into the same console. Before a defect is reported, the case is repeated in a private window with extensions disabled.
6. Console is empty but the screen shows wrong data. What does that tell you?
That the page did not fail: the code ran through. So the problem is most likely in the data, and the investigation moves to the Network tab and the response body.
The topic is covered in The Console tab.
Application: cookies, storage and cache
This group is about the data that stays in the browser between reloads, and the cases where it gets in the way of a check. Try answering before opening the answer.
junior
1. How does a cookie differ from local storage and session storage?
The browser attaches a cookie to every request to the site by itself, which is how the server recognises the session. Local storage and session storage are never sent automatically: the page has to include the value in a request explicitly. Between the two storages the difference is lifetime — local storage survives the browser closing, session storage is cleared when the tab closes.
2. How do you check that the cookie banner appears on a first visit to the page?
Put the browser back into the state of a new visitor: Application → Clear site data, or open the page in a private window. On that first opening the banner has to appear.
The rest of the check is that it appears exactly once: after “Accept” the site stores a cookie — cookie_consent=accepted, for instance, visible in the Cookies table — and on the next opening it reads that value and leaves the banner out. Clear the site data again and the banner has to come back.
3. The fix is deployed but the page still behaves the old way. What do you check before reporting?
The cache. An ordinary reload can return the old script or stylesheet, so what is needed is a hard reload — ctrl shift r / cmd shift r — and a look at Network: if the Size column says from disk cache, the file came from the cache rather than from the server.
middle
4. What do the HttpOnly and Secure flags on a cookie mean?
HttpOnly means the cookie is not readable by scripts on the page, which protects the value from being taken through JavaScript. Secure means it is only transmitted over HTTPS. Both flags are visible in the Cookies table of the Application tab.
5. Users are being signed out earlier than they should be. What do you look at in Application?
The Expires / Max-Age column of the session cookie: it holds the expiry date or lifetime the server set, and it is compared against the required one. A cookie with no expiry is a session cookie and is removed when the browser closes.
The topic is covered in The Application tab.
Lighthouse and automated checks
These are about what an automated audit shows and what is left to manual checking. Try answering before opening the answer.
junior
1. What does Lighthouse show?
An automated audit of the current page in four categories: Performance, Accessibility, Best Practices and SEO. It is a starting point for analysis rather than a verdict on quality: results vary between runs, so a trend says more than a single number.
2. Why is the audit run in a private window with extensions disabled?
Extension scripts run on the same page and end up inside the measurements, which distorts the performance score and some of the checks. In a private window extensions are off by default, so the runs stay comparable.
3. How do you run a Lighthouse audit?
In the Lighthouse tab, pick a mode (Navigation for a page load), a device (Mobile or Desktop) and the categories, then start the analysis. The report covers the current page, so the address being tested is the one that has to be open.
middle
4. Does an Accessibility score of 100 mean the page is accessible?
No. The category automatically checks part of the requirements: colour contrast, alt attributes, names on form fields, heading order, valid ARIA. Keyboard navigation, screen reader behaviour, focus order and whether the alternative text is meaningful are all verified by hand.
5. What standard is behind the accessibility checks?
WCAG, the accessibility guidelines published by the W3C; level AA is the one normally written into requirements. In the European Union the requirements for a range of digital products and services are set by the European Accessibility Act, which has applied since 28 June 2025; the corresponding technical standard is EN 301 549.
The topic is covered in The Lighthouse tab.
Web accessibility
A junior QA interview rarely asks for the details of the standard. What is asked is whether the basic principles are understood and whether the checks can be run by hand. Try answering before opening the answer.
junior
1. What is web accessibility?
Being able to use a site with a range of impairments: a blind user with a screen reader, a user with low vision, someone who cannot use a mouse and works from the keyboard alone.
2. What is WCAG?
Web Content Accessibility Guidelines — the accessibility guidelines for web content. They set out the criteria a site can be checked against, at three levels of conformance:
- A — the basic level.
- AA — the level normally written into requirements.
- AAA — the strictest one.
3. How do you check a site from the keyboard?
Put the mouse aside and walk the page with Tab and Shift + Tab, checking that:
- every button, link and field can be reached;
- the order the focus travels in is logical;
- the element that currently has focus is visible;
- controls can be activated with Enter or Space.
4. What is the alt attribute for?
It holds the alternative text of an image, the text a screen reader can read out.
<img src="logo.png" alt="Tallinn Learning logo"> — an image that carries meaning.
<img src="decoration.png" alt=""> — a decorative one: the empty alt hides it from the screen reader.
What has to be checked is not only that alt is there, but that its text conveys what the image means.
middle
5. What is ARIA for?
Roles and attributes that help assistive technology understand what an interface element is for and what state it is in.
<div role="button">Buy</div> — the role says the element is to be treated as a button.
<button>Buy</button> — a real button: the semantics and the keyboard support are there already.
ARIA does not replace correct HTML. Where a plain <button> will do, it is the better answer.
6. The text on a page is light grey on white. Is that a defect?
It is a checkable requirement rather than a matter of taste: criterion 1.4.3 Contrast (Minimum) at level AA asks for at least 4.5:1 for ordinary text and 3:1 for large text.
How to check: right-click the text → Inspect, then click the swatch in front of the color value in the Styles panel — the picker states the Contrast ratio and whether it passes AA. Lighthouse finds the same defect in its Accessibility category. Below the threshold it is an ordinary defect: reproducible, with a criterion to cite in the report.
The topic is covered in Web accessibility.