Introducing the Chrome Step Recorder


I’m sharing the ShiftLeft Chrome Step Recorder:

It’s made by testers (me) for testers.

You turn it on, do some stuff in chrome and it takes screenshots and transcribes all of your actions. In other words - does all your test evidence without any effort. If you need to, you can then annotate any steps as you need.

When you’re done, it’s all designed to save as single file (no external image references). Do this either with ctrl+S for a html file or press ctrl+p and essentially “print to pdf”.

I’d really love any thoughts/feedback from the testing community.
I’d love to expand it if there are any more ideas on any directions that are useful. I’ve not updated it for a few weeks as not sure what else would be useful (beyond the dreaded feature creep).

Kind Regards,


That’s a good idea. There are websites that do that as a service for users. But makes sense to have something similar for testers.

How are you funding this work Rich, I mean how do you sustain it (other than the company is still paying your lunches)?

Will defo have a good look, neat. It looks like a really useful tool, pretty sure i have used something similar while exploring.

There is no funding.
It’s just a side project I do in evenings and weekends because it’s fun and i wanted to flex some JS muscles :slight_smile:

The initial buildout took a few weeks over xmas holidays but recent enhancements only take a couple hours here and there.
The recent annotation update was 2 or 3 evenings worth of time. Nothing too major for something I enjoy.

Thanks for having a look.
Keep me posted if you have any further thoughts :slight_smile:


Thanks @crunchy
I had no idea that were sites that offered it as a service! Have you got an example?

Either way - this extension is free so that undermines their business model little bit :slight_smile:

1 Like

So I’m thinking of… UserReplay I’m sure there are others. They have pivoted toward Useranalytics now but I believe they started with reproducing with hard to find bugs.

I’m loving it so far. I can even try auto-install the plugin inside Selenium at some point to see if I can get it to record a automated test - that would be totally funky - assuming I can find the time.
(Today the devs deleted a button in the app, a very important button that might break a lot of tests, so as always emergency update to the tests is needed, it never ends.)

I would include screenshots of the recording to show what I think needs a bit more love, but it’s backend pages, so not for consumption, so Will try explain. BUT, from right to left

  1. the screenshots thumbnails are effing great, who came up with the “click-and-hold” zooming, so that I don’t get RSI trying to close images, this is high spec UX stuff, good job!
  2. I manually ran a few steps, and the page load time was always 1949 milliseconds, for every transition, so I’m a bit puzzled, since that’s consistently 2 seconds, is the page load time value shown something I just don’t understand? (I’m a newbie at web apps , but if it helps, this is a Vue framework based app).
  3. Formatting , namely the identifiers column in the report have “[” “]” braces around it… why are the “[” “]” braces there?

    [textContent : [[password values not recorded]]]
    [value : [[password values not recorded]]]
    [id : ppr-login-password]
  4. I really do like the password hiding happening, cool plugin skillz
  5. Steps column - this column is brilliant, succinct and easy to understand!

Although I’m not about to buy this plugin, I think it’s great, and deserves a virtual beer.

Thanks for taking the time buddy!
Happy to accept the virtual beer.

Good news is you won’t need to buy it - it’s free and there are no plans to change that aspect. If anything, I’m more likely to go the other way and stick the source on github…

Trying to comment on your awesome feedback.

  1. :+1:

  2. Two parts to this. Partly me, partly the web standards.

The me part: I write out the page load times time per step/action and multiple actions (clicks, sets, etc…) can be done over and over on the same page. I totally agree it’s not the clearest when times look the same but writing out the time for each action (in my head) means “The page you see on the screenshot took this long to load - same page = same time”

The web standards part:
Page load time comes from what the browser itself records. This is where different web technology like vue and angular come into play.
Paste this line in chrome devtools console and you’ll see the raw data recorded by the browser: performance.getEntriesByType('navigation')[0];
Point being - It’s only updated when a new page loads.
If your page doesn’t change (i.e. it does async JS calls to modify content) then page doesn’t reload so doesn’t get new times. I’ve been looking at this for a while but it’s a difficult to create a one glove fits all solution to the internet.

  1. Literally no reason for the square brackets - That’s just the way I wrote the output! It was just to make the start and end of each identifier… I captured 12 different identifiers and only write the ones that are relevant. While designing, I suppose I was worried it would be too much without a logical grouping…
  2. :+1:
  3. :+1:

Really good getting independent feedback. Thanks again.

1 Like

That makes sense, the way timings work. I’m still learning so much about browsers, dang complex beasts. I think the beautiful part of any well built tool is that the tool can often be a way of teaching other people about the craft it’s used for. And that also plays into the “raising the bar” of tool quality, so that fewer people end up with terrible tools, by having one really good tool out there and available, to force the standard of other tools higher.

And good luck with the publish to open source step, it’s definitely a big step coming with it’s own responsibility, which is always worth downplaying if possible.