New · Specialised Track

Bug Reporting & Evidence

Finding the bug is half the job. The report is the other half — and the half that gets paid for.

A defect that no one can reproduce does not get fixed. A report that lands without evidence sits in the backlog, gets bounced back with “cannot reproduce”, or quietly closes as stale. The report is where most of a tester’s value is created or lost. This track teaches you to write reports a developer can action on the first read, and to gather the logs, console output, and network evidence that turn a rejected report into a fixed one.

Start with Lesson 1 → Back to Specialised

This track covers

Anatomy of a Great Report Isolation & Reproducibility Severity vs Priority Logs, Console & Network Correlation IDs

Why the report is 70% of the value

Anyone can stumble onto a defect. The skill the team pays for is turning that into a report someone else can reproduce, prioritise, and fix without coming back to you. A vague report wastes a developer’s hour; a sharp one saves it. The finding is cheap. The report is the deliverable.

Who this is for

Testers, Test Leads, and developers who raise defects in NZ teams. Assumes ISTQB Foundation Level or equivalent. No tooling background required — the browser console and network tab are taught from first principles.

The 2 lessons

From the write-up to the evidence

Lesson 1

Anatomy of a Great Bug Report

Isolation and reproducibility. Title, steps, expected versus actual. Severity versus priority, the developer’s perspective, and Jira/Xray-style markdown templates that get a fix moving.

~30 min read · ~70 min with exercises · Bug Reporting

Lesson 2

Logs, Console & Network Evidence

Reading server logs, the browser console, and the network tab as evidence. Correlation IDs, capturing payloads, and what turns a rejected report into an actioned one.

~30 min read · ~75 min with exercises · Bug Reporting

Why this track

The report is the product, not the by-product

Picture two testers who find the same defect on an IRD myIR login page. The first raises “login broken, please fix”. The second raises a titled report with exact steps, the browser and version, a screenshot, the failing network request, and the correlation ID from the response. The defect is identical. One report gets bounced back the same afternoon with “works on my machine”; the other is in a developer’s hands and fixed before stand-up. The difference was never the finding. It was the report.

Most of the cost of a defect is the back-and-forth around it. Every “can you give me steps?”, every “which environment?”, every “I cannot reproduce this” is a round trip that burns a developer’s time and a tester’s credibility. A report that answers those questions before they are asked removes the round trips. That is where the 70% sits: not in spotting the problem, but in making it cheap for someone else to fix.

This track teaches both halves of that skill. Lesson 1 builds the report itself — isolation, reproducibility, a sharp title, expected versus actual, and the difference between how bad a bug is and how soon it must be fixed. Lesson 2 arms the report with evidence — reading logs, the console, and the network tab, capturing payloads, and pulling the correlation ID that lets a developer find your exact failure in their systems.

Other specialised tracks

Specialised