All jobs / QA / manual tester

Web Testing interview questions

Web Testing questions a QA / manual tester can be asked, from first job to senior. Open one to see the strongest answer and why it works.

1. A page shows “Something went wrong.” What does the Network tab tell you before you file the bug?

   The strongest answer: Which request failed, its status code, and whether a response arrived at all — so the bug says “POST /orders returned 500”, not “it broke”

   Why it works: Exactly — the failing call, its status and its response turn a vague report into one a developer can start on.

   • Open the Network tab before filing.
   • Find the failing request.
   • Read method, path and status.
   • Put them in the bug title.

2. What is the practical difference between a cookie, localStorage and sessionStorage when you are testing a login?

   The strongest answer: Cookies are sent to the server with matching requests and can be HttpOnly; localStorage stays in the browser until cleared; sessionStorage dies with the tab — each changes what “still logged in” means

   Why it works: Right — where the session lives decides whether a new tab, a restart or a different subdomain is still signed in.

   • Know where the session lives.
   • Cookies ride along with requests.
   • localStorage persists; sessionStorage is per tab.
   • Test new tab, restart, logout.

3. The fix is deployed, the release notes say so, and a tester still sees the old behaviour.

   What do you check before filing “the fix did not work”?

   The strongest answer: That I am actually on the new build — hard reload with cache disabled, read the version the app reports, and confirm my request reached the new deployment

   Why it works: Exactly — prove which build answered you, then talk about behaviour. Version evidence ends this argument for good.

   • Prove the build before the bug.
   • Hard reload with cache disabled.
   • Read the version the app reports.
   • Then judge the behaviour.

4. How do you test a responsive page properly, beyond dragging the window narrow?

   The strongest answer: At the breakpoints the design names and just either side of them, in both orientations, with the on-screen keyboard open, and on at least one real device — the emulator hides touch targets

   Why it works: Right — breakpoints, orientation, the keyboard and one real device catch what the resize handle never does.

   • Test the breakpoints, not the drag.
   • Try both orientations.
   • Open the on-screen keyboard.
   • Confirm on one real device.

5. A checkout step fails for one tester and works for everyone else. They are on a different browser from the rest of the team.

   What do you establish before filing it as a browser bug?

   The strongest answer: The exact browser and OS version, whether it survives a private window with extensions off, whether a second machine reproduces it, and what the Network tab shows differently — then file with all of it

   Why it works: Exactly — version, clean profile, a second machine and the request difference separate a browser behaviour from one laptop’s state.

   • Separate the browser from the machine.
   • Record exact browser and OS version.
   • Retry clean: private window, no extensions.
   • Reproduce it on a second machine.

6. A bug only appears on a slow connection. How do you capture it so a developer can work on it?

   The strongest answer: Reproduce it with the network throttled, export a HAR of the session, note the timings that matter, and scrub tokens and personal data out of the HAR before attaching it

   Why it works: Right — a throttled repro plus a scrubbed HAR gives exact timings and keeps a live session token out of the tracker.

   • Reproduce it under throttling.
   • Export the HAR.
   • Scrub tokens and personal data.
   • Name the timings that matter.

7. Marketing publishes that the product “supports all modern browsers.” You own the quality bar.

   What do you owe that sentence?

   The strongest answer: A written matrix of the browsers and versions we actually test, chosen from our own usage data, a smoke that runs on each before release, and an honest note when a row was not covered

   Why it works: Exactly — a public promise needs a tested matrix behind it, chosen from real usage, and honesty when a row was skipped.

   • Back the promise with a matrix.
   • Choose the rows from real usage.
   • Run a smoke on each row.
   • Say plainly what was not covered.