Test Execution & Defect Management.

Execution is the part people picture when they imagine testing, and the part they describe the most vaguely. It is not clicking around until something breaks. It is running known cases against a known build and recording what actually happened, so the team can make a decision.

• Why execution is the moment your test design either pays off or falls apart
• Entry criteria as a checklist you actually run: testable build, approved requirements, test data ready, environment up, cases reviewed
• Exit criteria as the line that ends a cycle: cases run, coverage met, no open critical or high-severity defects

A cycle that starts before it is ready, or ends because someone got tired, is where quality quietly leaks out.

A test run is how you turn a pile of cases into information someone can act on. You execute each case against one build, in one environment, and you mark a status that means the same thing to everyone reading it.

• The statuses and what each one promises: Passed, Failed, Blocked, Skipped, Retest, Untested
• The four environments and what is true in each: development, testing, staging, production
• Naming a run so the result is unambiguous later (Regression : v1.0 : Chrome : Staging), and capturing evidence on every failure

Blocked is not Failed, and Skipped is not Passed. Mark them wrong and your run lies to the people trusting it.

A failing case tells you something is wrong. Your job is to see exactly what, and to classify it so the team understands the shape of the problem at a glance. Most defects fall into a handful of recognisable categories, and naming the category is half the diagnosis.

• The defect categories that come up again and again: functional, control flow, calculation, error handling, performance, communication, missing command, and visual
• Reading a screen like a tester: the failure you were sent to find, and the two next to it you were not
• Telling a real defect from a misread requirement before you file anything

A bug filed under the right category is a bug a developer can start reasoning about before they read a single step.

A bug nobody can reproduce never gets fixed. A clear report answers one question completely, which is how do I see this for myself, and it carries severity and priority that mean two different things. This is the most visible thing you produce, so build it in the tool that scores it as you go.

• The parts every report carries: a specific title, environment, numbered steps from a known state, expected versus actual, and evidence
• Severity is impact, priority is urgency, and you state both. The tester usually owns severity, the product owner owns priority
• Reproducibility as its own field: Always and one in twenty send a developer down completely different paths

Getting a bug fixed is where the time goes, and most of that time is wasted on bugs that were reported badly.

Filing the report is the start, not the end. Every defect moves through a lifecycle, and at each step someone specific owns the next move. Knowing the states, and who owns each transition, is what stops bugs from dying silently in a backlog.

• The states a defect moves through: New, Triaged, In Progress, Ready for Retest, Closed, and back to Reopened
• The endings that are not Closed, and when each is honest: Deferred, Duplicate, Rejected, and Cannot Reproduce
• Retesting a fix properly, and the regression check around it, before you let anything close

You do not own the bug, but you have a say on it, and you make sure that say is heard until it is genuinely resolved.

A backlog of open bugs is not a to-do list you work top to bottom. Triage is the skill of ordering it by risk, so the right bugs get fixed first instead of whatever is loudest or newest. This is the line between a tester and someone the team trusts with a release.

• The severity by priority matrix, and why the corners (high severity, low priority and the reverse) are the interesting ones
• Risk-ordering a backlog: impact, likelihood, and what protects core functionality first
• Running, or surviving, a triage meeting: what to bring, what to defer, and how to hold a line on a critical bug

Ship the wrong fix order and you either delay the release or ship something low quality. Both land on you.

Numbers from your runs and your defects are how you tell the quality story to people who were not in the room. Used well they guide the team. Used badly they become a target someone games, and the number gets better while the product gets worse.

• The honest ones: defect leakage (what escaped to production), reopen rate, defect age, and defect removal efficiency
• Why a raw bug count is almost always the wrong headline, and what to show instead
• Reading severity and priority spread across a release to answer the only question that matters: can we ship?

A metric becomes a lie the moment it becomes a target. Know which numbers help, and which ones just look busy.

A cycle ends with a decision, and a tester is the person best placed to inform it. Closure is checking every planned case was run or consciously skipped, every known bug is fixed or accepted, and writing the one summary the people deciding will actually read.

• Closure activities: confirming cases ran, fixes were retested, and known bugs are resolved, deferred, or documented as limitations
• The test summary report that earns trust: what shipped, what is open, the risk, and your recommendation in one place
• Handover that does not drop anything: passing open bugs, environments, and known limitations to the people who own them next

A good idea is not a reason to ship. The call is whether it works and whether the risk is one the team can carry.

AI is genuinely useful in this phase, and it is useful in specific places, not as a wand you wave over the whole run. Hand it the work it is good at, the reading and the drafting and the combing through, and keep the judgment, the risk call, and the decision to ship for yourself.

• Where AI helps: turning a screen recording into draft repro steps, a wall of logs into the failing request, and a noisy backlog into clustered duplicates
• Where the human is non-negotiable: seeing a UI is visually wrong, judging real risk, the triage call, and whether the build is good enough to ship
• Doing it honestly: AI drafts the report and the summary, then you review, correct, and own every word with your name on it

AI drafts the obvious fast. Deciding what matters, and standing behind the go or no-go, is still you.