Study notes from Julia

This is the part people picture when they hear testing, but good execution is not random clicking. You take the cases you designed, run them against one known build in one known environment, and record what actually happened so the team can decide what to do next. By the end of this deck you will have run a real cycle, written a report a stranger could act on, triaged a backlog by risk, and made a release call you can defend.

Study notes from Julia

A test cycle has a rhythm. First you decide whether the build is ready to test at all, then you execute the cases with the right status. Then you turn failures into reports a developer can act on, and drive each defect through its lifecycle. Finally you help the team decide whether the remaining risk is acceptable. Every section here ends with something you can practise in a tool on this site.

Study notes from Julia

The first discipline is honesty. Passed, Failed, Blocked, Skipped, Retest and Untested do not mean roughly the same thing. If you mark them casually, your run lies. If you mark them carefully, your run becomes decision-quality information the whole team can trust.

Study notes from Julia

Entry criteria are not ceremony. They protect your time and the team’s trust. If the environment is down, the test data is missing, or the cases do not match the build, the result is not a clean cycle. It is confusion with timestamps. Exit criteria close the other end: cases run, coverage met, no open critical or high-severity defects.

Study notes from Julia

Name the environment in every run and every report, because the same build can pass in testing and fail in staging over one config difference. A run named "Regression : v1.0 : Chrome : Staging" tells the next person exactly what was true. "It works on my machine" is not a status, it is a missing environment.

Study notes from Julia

People make real decisions from these words, so use them precisely. Blocked is not a softer Failed, it means the case could not run to its end. Skipped is not Passed, it means the team chose not to run it. Untested said out loud is a thousand times more useful than a green check that is a lie. The run only stays trustworthy if every case ends in the status that tells the truth.

Study notes from Julia

Mark a Blocked case as Failed and you send a developer hunting a bug that does not exist. Mark a Failed case as Blocked and a real defect hides behind an environment excuse. Keep them apart and your run stays honest. The same care applies to Skipped versus Untested: one was a decision, the other is simply not done yet.

Study notes from Julia

Here is a real run on a checkout suite. Two cases pass, one fails with evidence, one is blocked because the saved-card service was down, and one was never reached before time ran out. That mix is not a bad run, it is an honest one. A screen of all-green on a brand-new build should make you more suspicious, not less. Practise the whole loop in the Test Run Simulator until choosing the honest status is automatic.

Study notes from Julia

This activity is small on purpose. The skill is not running a huge suite, it is refusing to make the result prettier than it is. One honest case teaches more than twenty casual green checks. Do it in the simulator so you can see how the run reads to the next person.

Study notes from Julia

A failing case gives you a signal. Your job is to turn that signal into a report a developer can act on: the exact environment, the starting state, numbered steps, expected versus actual, evidence, severity, priority and reproducibility. Getting a bug fixed is where the time goes, and most of that time is wasted on bugs that were reported badly.

Study notes from Julia

Naming the category is half the diagnosis. A bug filed under the right one is a bug a developer can start reasoning about at a glance: a calculation defect points at the maths, an error-handling defect at the unhappy path, a visual defect at the layout. You do not need a perfect taxonomy, you need a shared vocabulary so the shape of the problem is clear before anyone opens the steps. IEEE 1044 is the formal version if you ever need one.

Study notes from Julia

This is one real defect written out in full. Read it and there is nothing to ask: you know the build, the exact steps, what should have happened, what did, and how bad it is. Reproducibility is its own field for a reason. "Always" and "one in twenty" send a developer down completely different paths. The Bug Report builder writes cases in exactly this shape and scores them as you go.

Study notes from Julia

The bug is identical. The difference is entirely in the report. The first one starts a conversation, three messages, a screen-share, and a day lost. The second one gets picked up and fixed before standup. Writing the second kind is not extra work, it is the work. Vague reports are the single biggest source of wasted time between QA and development.

Study notes from Julia

Keep this template one click away and your reports get consistent overnight. The builder on this site turns it into a scored form, so you learn what a strong report feels like while you write one. Paste this into your tracker, or better, let the builder generate it for you and export it.

Study notes from Julia

The test of a report is simple: hand it to someone with no context and see if they can reproduce the bug without asking you anything. Build it in the Bug Report builder and it scores each part as you go, so you feel the difference between a report that gets ignored and one that gets fixed first time.

Study notes from Julia

Defect management is ownership without pretending you own everything. Developers fix, product weighs priority, and testers keep the evidence honest. 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, not just quietly closed to tidy the board.

Study notes from Julia

The lifecycle makes ownership visible. A New bug needs triage. In Progress belongs with the developer. Ready for Retest comes back to you. Closed means the fix was verified, with proof, not just claimed. Deferred, Duplicate, Rejected and Cannot Reproduce are honest endings too, when they are used correctly and not as a way to make a real bug disappear.

Study notes from Julia

Severity and priority get mixed up constantly, and keeping them apart is one of the fastest ways to sound like you know what you are doing in triage. Severity is how badly it breaks the product, and you usually own that call. Priority is how soon it should be fixed relative to everything else, and the product owner usually owns that. The interesting bugs live in the corners, where the two disagree.

Study notes from Julia

A backlog is not a queue you work newest-first. Triage is ranking it by risk so the right bugs get fixed first instead of the loudest or the latest. The double-charge is P1: it touches money and everyone can hit it. The coupon reuse is real revenue loss but has a workaround, so P2. The missing email image is annoying, not blocking, so P3. The stale footer is cosmetic, P4. Being able to say "here is the order and here is why" is the line between a tester and someone the team trusts with a release.

Study notes from Julia

A metric becomes a lie the moment it becomes a target. A raw bug count is almost always the wrong headline: it rewards a messy build, punishes a clean one, and turns testers into bug farmers. The honest numbers answer real questions. Leakage asks what escaped to production, reopen rate asks whether fixes hold, age asks what is rotting in the backlog. Read severity and priority across a release and you can answer the only question that matters: can we ship?

Study notes from Julia

The skill you are building is the reasoning, not the ranking. Anyone can sort a list. Being able to say "this is P1 because it touches money and everyone hits it, and this is P4 because it is cosmetic and rare" is what a triage meeting actually needs. Move real defects through the states on the Defect Triage board to feel how the order changes the release.

Study notes from Julia

A tester does not ship the product alone, but a strong tester shapes the decision. Closure means you know what ran, what failed, what was fixed, what remains open, what was consciously skipped, and what risk the team is carrying into release. 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.

Study notes from Julia

The best closure summary is short because it is prepared. It does not bury the decision-maker in a spreadsheet. It tells the truth: here is what we know, here is what we do not know, here is what still worries me, and here is my recommendation. Handover that drops nothing goes with it: open bugs, environments and known limitations passed to whoever owns them next.

Study notes from Julia

This is what closure looks like on one page. Every High and Medium case passes, one Medium and three Low defects are open, all six fixes were retested, and the one shipping limitation is written down with product-owner sign-off. The recommendation is GO with a known limitation, and the reasoning is right there. QA recommends, the product owner decides, and this evidence is what makes that call defensible instead of a gut feeling.

Study notes from Julia

A checklist beats a memory under deadline pressure. Run this before every release and the summary writes itself, because you gathered the evidence as you went instead of scrambling at the end. The status cheat-sheet from Section 1 and this checklist together are most of what closure needs.

Study notes from Julia

AI is genuinely useful in this phase, in specific places, not as a wand. Hand it the reading and the drafting and the combing through. Keep the judgment, the risk call and the decision to ship for yourself. A screen can be technically functional and visibly wrong. A release can be mostly green and still too risky. That call stays human, and it stays yours.

Study notes from Julia

If you keep one thing from this deck, keep this. Your job in execution is not to make the build look good. It is to find out what is true and say it clearly: what ran, what failed, what is fixed, what is still open, and what risk the team is carrying. Teams learn fast who they can trust for a straight answer. Be that person and the interesting work finds you.

Study notes from Julia

The fastest way to learn execution is to practise the whole loop, not just read it. Run a case in the simulator, write the report in the builder, move the bug across the triage board, then say what you would recommend for release. The full course adds nine modules, flashcards and a knowledge check on top of this lesson.

Study notes from Julia

This is the finish line for the beginner track: not because you know everything, but because you can now move through the actual work. Design the case, run it, report what failed, follow it to closure, and help the team make a release decision with evidence. Keep doing the small drills in the tools and they compound into the judgment that makes a tester worth keeping. I am proud of how far you have come. Go run something real.