Day 4: The Contexts Nobody Checks, Reports Nobody Ignores

1. Three contexts almost nobody tests

Mobile and responsive view. Most sites are designed for a big desktop screen first and squeezed down afterwards, and the squeezing is where things break. In DevTools, click the small phone/tablet icon (Toggle Device Toolbar) and preview the page at phone width. Look for overlapping text, buttons pushed off-screen, menus that will not open, and forms you cannot submit because the button is under the keyboard.

Slow network. In the Network tab there is a dropdown that usually says "No throttling". Change it to Slow 3G. Now reload. This is not an edge case in Nigeria, Ghana or Kenya — it is Tuesday. The question you are answering is: does the app show a loading indicator that tells the user to wait, or does it just sit there looking frozen and broken until the user gives up, closes it, and tells their friends the app does not work?

Keyboard only. Put the mouse down. Navigate the page using only Tab, Shift+Tab, Enter and the arrow keys. Can you reach every field and button? Can you always tell which element is currently selected? Some users navigate this way permanently, including people with motor impairments and people using screen readers. When keyboard navigation is broken, those users simply cannot use the product at all — and that is both an accessibility failure and, increasingly, a legal one.

2. Why most bug reports get ignored

A bug report is only useful if a developer can read it once and immediately understand what went wrong and how to see it themselves. A vague report — "the buy button is broken, please fix" — goes to the bottom of the pile, because reproducing it will cost the developer thirty minutes of guessing. A precise report gets fixed the same day, and gets you hired again.

3. The eight parts of a report that gets fixed

1. Title — short, specific, searchable. Not "button doesn't work" but "Buy button throws 500 error on the 99th consecutive click".
2. Environment — browser and version, operating system, device, the exact URL, the date and time.
3. Steps to reproduce — numbered, exact, repeatable. Anyone following these should see the same thing.
4. Expected result — what should have happened.
5. Actual result — what really happened, precisely.
6. Severity / priority — how bad is it, honestly.
7. Evidence — screenshot, screen recording, or the Console log. A picture ends all argument.
8. Frequency / notes — every time, or sometimes? Anything else you noticed nearby?

4. Severity, judged honestly

A junior tester marks everything High because everything feels urgent when you just found it. A tester people trust marks the misaligned button Low — and precisely because they do, everyone believes them when they mark something Critical.

5. Bad report versus good report

You are a busy senior developer. A tester just sent you the bug
report below. You have never seen this product and you cannot
ask any questions.

Read it and answer strictly:
1. Following ONLY these steps, could you reproduce this bug?
   Where exactly would you get stuck or have to guess?
2. List every piece of information that is missing or vague.
3. Is the severity justified by the described impact, or is it
   over-stated? Say what you would change it to and why.
4. Rewrite the title so it is specific and searchable.
5. Score the report out of 10 for reproducibility, and tell me
   the single change that would raise the score the most.

Be strict. A generous review helps me nothing.

BUG REPORT:
[paste yours here]

• I tested one site in mobile view, on Slow 3G, and by keyboard
• I wrote a full eight-part bug report with evidence
• Someone else reproduced my bug using only my steps