How to verify a bug fix with before and after recordings

To verify a bug fix, reproduce the bug on the old build, repeat the same steps on the fixed build, compare both results against explicit checks, and test a nearby behavior for regressions. Before and after recordings make that check easier to review; they show what happened in the recorded case.

It's Thursday afternoon. A customer reported that filtering their request list sometimes shows nothing at all. You found the problem, pushed a fix, and opened the PR.

Ten minutes later your reviewer comments: "Did you actually check it? I can't reproduce the original bug."

Now you're writing a paragraph explaining what you clicked, in what order, on which build, and hoping they believe you. They'll probably pull the branch and try it themselves anyway. If you've had this conversation before, this guide is for you.

There's a faster answer: two short recordings of the exact same steps. One on the build with the bug, one on the build with the fix. Your reviewer watches the bug happen, then watches it not happen. Nobody has to take anyone's word for it.

Below, we'll walk through one example from start to finish. It's a fictional app called Cedar Desk, and the builds, timestamps, and results are made up for illustration. We build Rill, so we'll use it here, but the habit works with any recorder.

Bug fix verification checklist

• Define the expected result before checking the fix.
• Record the original bug and the fixed build with the same steps and test data.
• Label both recordings with a build or commit identifier.
• Compare the results and note the timestamps that show each check.
• Run a nearby regression check and list what you did not test.

Step 1: Decide what "fixed" means before you look

Here's the trap. You open the new build, the list looks better, and you call it done. But "looks better" isn't the same as "fixed." Half the bug can still be hiding.

So before recording anything, write down what a correct result looks like. In Cedar Desk:

• There are 24 test requests (R01 to R24), 10 per page. Four of them are Open: R03, R09, R16, R22.
• You start on page 3 with every status shown.
• You pick the Open filter once.

When the bug is fixed, four things should be true:

1. Open is selected.
2. You're back on page 1.
3. Exactly R03, R09, R16 and R22 appear, in that order.
4. The total says four, Next is disabled, and you didn't need an extra click to get there.

Those four lines are what your reviewer will check. They turn "seems fine" into pass or fail.

Step 2: Pick how you'll record

Rill gives you three ways to capture the same check. Choose by who does the clicking.

For a visible bug like this one, recording it yourself is plenty. If the fix touches API calls or errors, recording through an agent lets your reviewer see the network requests next to the video.

Step 3: Record the bug, then the fix, the same way

First, go to the old build and catch the bug on video. Then do exactly the same thing on the new build.

Include the build or commit identifier in each recording title alongside "before" or "after." Once another change lands, nobody remembers which "after" you meant.

• BF-01: build cedar-41, the bug
• AF-01: build cedar-42, the same steps after the fix
• NG-01: build cedar-42, a quick check that nothing nearby broke (more on that in Step 5)

To record it yourself, open Record my screen in Rill and pick the tab. Then:

1. Start recording before you touch the filter, with the filter, the rows, the total, and the page numbers all in view.
2. Show that you're on page 3 with everything listed.
3. Pick Open, then keep recording until the list stops changing.
4. Stop, preview, and save.

Now do it again on the fixed build. Use the same account, the same data, and the same browser. Don't add a refresh or an extra click you didn't do the first time, because that can hide the very bug you're checking. And make sure the new build is really the one that loaded. A deploy notification doesn't prove it.

If an agent is doing the recording, give it the same steps and the four checks. Ask it to record each build separately and send back the share links, which build each one used, a pass or fail for each check, and anything it couldn't verify. Setup is in the agent quickstart.

If the bug only happens sometimes, record repeated attempts and report how many failed on each build. One successful attempt does not establish that an intermittent bug is fixed.

If the old build is already gone, keep any existing recording of the bug and say so. You can still check the fix against your four lines, but don't call it a side-by-side comparison.

Step 4: Point your reviewer to the moments that matter

Your reviewer shouldn't have to scrub through two videos. Tell them where to look:

Then score both against your checks:

Be careful not to claim more than the video shows. It shows the old build stayed on page 3 after filtering, which hints that the page number wasn't being reset. But a video can't prove the cause. That takes a look at the code or a test. If an agent made the recording, you can open its network requests in Rill and jump from each one to that moment in the video.

Step 5: Check one thing the fix could have broken

Fixes have side effects. If this one resets the page too eagerly, the Next button might stop working.

So record one more quick case, NG-01, on the fixed build. Start on page 1 with every status shown, pick Closed, then click Next once.

You should see Closed still selected, a total of 20, page 2 active, and R13, R14, R15, R17, R18, R19, R20, R21, R23, R24 in order. In our example it passes. If Next had bounced you back to page 1, that would belong in the review too.

Step 6: Leave a note that says what you did, and what you didn't

Post the links and a short verdict in the PR or issue:

FILTER-17: verified on cedar-42 for the recorded case.

BF-01 (cedar-41) at 00:10: picking Open from page 3 leaves an empty list on page 3.

AF-01 (cedar-42) at 00:12: Open selected, page 1, R03/R09/R16/R22, total four, Next disabled. All four checks pass.

NG-01 (cedar-42): Closed filter reaches page 2 with the expected ten records.

Not tested: other browsers, switching filters quickly, reloading the page, empty lists, two people editing at once. Root cause not confirmed by these recordings.

That last line does a lot of work. It tells your reviewer exactly how far your proof goes, so they know what's left to test.

Before you share, watch each recording for private data. Rill doesn't blur or hide anything in the video, and anyone with an active share link can view the recording and its diagnostics. Share it only with the people reviewing the fix. Details are in the CLI and sharing reference.

Try it on your next fix

Next time a reviewer asks, "Did you actually check it?", you can send two links instead of a paragraph.

Start with Rill Free, with no card required. See current Free and Pro pricing. Start recording in Rill, or set it up for your agent.

Related guides

• How to report a bug with a screen recording
• Show someone a bug in an app running on your computer