🐞 E5 · Catching Defects from Network

E5 · Catching Defects from Network: Everything you learned in E1-E4 (columns, filter, tabs, Timing) exists for one purpose: **the Network panel is a lie detector that reveals the

Everything you learned in E1-E4 (columns, filter, tabs, Timing) exists for one purpose: **the Network panel is a lie detector that reveals the gap between what the UI SAYS and what the server REALLY DID.** The UI always shows text the developer WROTE ("Success!"), the Network panel shows what the server REALLY returned (500, an empty body, a leaked field) — the mismatch between the two is exactly where a defect is born. So why is there so often a gap between UI and reality — is the developer lying on purpose? No — most of the time the developer only tests the happy path, and either never writes the error case (the `catch` block) or mistakenly shows a "success" message there too; this is not intent, it is an OVERSIGHT. The Java equivalent is a `try` block SILENTLY swallowed by `catch (Exception e) { }` — the error really happens but is never logged/reported anywhere, just like the UI showing a 500 as "success". For QA, this tab is the peak of the entire GROUP E — you are no longer just READING the panel, you are HUNTING for real bugs HIDDEN inside it.

5 Real Defect Scenarios and Which Layer Catches Them

The 5 scenarios below are real defect categories caught from the Network panel. Each represents a different kind of "gap between UI and reality".

The UI Says "Success", the Network Says "500"

**1. Silent 500** — the UI says "Operation complete" with no visible error, but in the Network panel the request returns `500 Internal Server Error`. **Root cause:** the frontend code runs its `.then()` block without EVER checking the response status code. **Where the tester catches it:** always checking the Status column in the Network panel, INDEPENDENTLY of the UI message.

**2. Double POST** — the user impatiently clicks "Save" twice; since the button is not disabled, the SAME `POST /api/v1/bugs` request appears TWICE in the Network panel, creating two separate bug records. **Root cause:** the button is not made `disabled` while the request is in flight. **Where the tester catches it:** counting the repeat of the same request in the Network panel after a rapid double-click.

**3. N+1 requests** — the bug list page FIRST fetches 10 records with `GET /api/v1/bugs`, then calls `GET /api/v1/bugs/{id}/details` separately for EACH record — 11 requests instead of 1. **Root cause:** the list endpoint does not already return the needed detail, forcing the frontend to fire a separate request per row. **Where the tester catches it:** seeing the SAME URL pattern repeated as many times as there are records in the Network panel.

**4. Leaked `passwordHash` in the Response** — in a user list request's `Response`/`Preview` tab, even though the UI never displays it, the JSON body contains a field like `passwordHash` that should NEVER be returned. **Root cause:** the backend serializes the database entity (with all its fields) directly to JSON, without filtering fields through a DTO/response model. **Where the tester catches it:** scanning the JSON in the Response/Preview tab even for fields NOT VISIBLE in the UI — this is a security hole, not just a "cosmetic" extra.

**5. Missing Cache-Control** — a user views a sensitive bug detail, logs out; pressing the browser's BACK button shows the same page with the old (now supposed-to-be-unauthorized) data FROM CACHE, without firing a new request. **Root cause:** the response headers have NO `Cache-Control: no-store`, so the browser freely caches the sensitive response. **Where the tester catches it:** checking the presence/value of the `Cache-Control` field in the Headers tab, then trying the back-button scenario.

🎬 A Bug in the Network Panel

UI: "Created successfully"

Network: 500 Internal Error

Tester opens Network

Evidence: row + Response body