Brainstorming, would you use this page recording Chrome extension?

Thinking about starting this tool project. Would love to hear your thoughts.

The idea is a Chrome extension that sits in the background and records all the page contents that you see. It would record all the HTML / DOM / events, and then you could playback or share a recording later.

A big use case would be web dev testing. If someone on the team is using the site, and they see an issue or something that needs attention, they can share their recording. It would save everyone a ton of time trying to figure out the repro steps.

There’s a lot of video-based recording extensions out there (like Loom) but it seems like the weakness with those is that you have to actually be recording. If you’re not expecting an issue then you might need to do it twice to capture a recording of it.

Another diff is that instead of playing back video, the approach I’m looking at would reproduce the original web page DOM, which would include a lot more debugging information.

  • Would you actually use an extension like that?
  • Are you using any page recording tools right now? If not why? if yes, are you happy with the one you’re using?
  • If you’re already using page recording, do you typically start recording as soon as you start testing, or do you want till you see a bug and then go back to capture a recording of it?
3 Likes

I seem to recall that Cypress has something like that, I didn’t use it much so I’m not 100% sure if they’re just recording video and screenshot or the DOM traversal as well.

But I think I would use something like that it does sound useful in pinpointing exactly where a UI issue could be, a big potential time saver!

1 Like

I don’t use Cypress, but I do know it has a built in recording feature - which is just a movie, not the DOM. obviously for Vue/ajax apps you don’t want to record every single DOM change as that might become a rather large object, although I’m still not sure I would pay money for a tool that records the DOM, I can see, it would be a useful bug tracking and repro tool.

I just have not got much web app experience, so whether it’s a great idea I cannot say.

1 Like

Yeah we use video recordings for failed tests in Cypress and those are definitely a huge help! Don’t know if Cypress does DOM capture, but the videos work pretty well, they get the job done.

The use case that I’m brainstorming is an easy & lightweight way to capture recordings of manual site usage, like ad hoc / exploratory testing. There’s tools like Loom, but I haven’t yet been on a team yet that used them. Feels like they are probably a lot of overhead to set up & use. Curious if I’m alone in that feeling, maybe a lot of teams are happily using tools like that, not sure!

Anyway appreciate your feedback!

1 Like

@conrad.braam awesome, that feedback is helpful!

on Vue/ajax apps, my hunch is that even if they churn the DOM a lot, it might still be cheaper to record the DOM changes than to record an entire video, but that’s a guess, will have to see about that.

Definitely helpful to hear what kind of tools are worth paying for. Are you using any bug recording & capture tools as part of your process now?

Andrew, at the moment I’m using selenium with our own grid, and busy learning enough java just to get by. Aside from a screenshot and a static page dump, nothing more in the way of tools, since most of the work is done by grabbing the live console out log from the transpiled C++ to java app that is the main gubbins of the job. But later that day, while writing a new test, I did imagine, that any tool that did grab diffs of the DOM if only to tell me that a list-control (element) populated or depopulated in a way I did not expect. That would be useful, no idea of monetary value though.

Just that ability, although I’m not an HTML speed-reader who would parse these comfortably, would sometimes be very helpful when triaging failed tests.

As for worth paying, I’ve paid for tools infrequently, mainly because I prefer tester jobs that are off-pieste, or on other words hard. I’m not good at it, but I prefer the harder problems, and with territory comes a lack of off-the-shelf tooling. Thus more likely to pay for a one-off tool that solves a problem I have today, and then discard the tool so that I don’t have to keep worrying about the tool breaking later. Most of our team budget is on buying mobile phones, and then a few small subscriptions.

2 Likes