Record and Playback and Session Replay tools may sound similar but they're wildly different.
Have you ever wondered:
What's "record and playback?" Is that like "session replay?"
"Record and Playback" and "Session Replay" (or "Session Playback") are two similarly named but different types of features used to help you deliver better customer experiences. Despite the names, each serves a vastly different purpose within the software development lifecycle ("SDLC").
Let's define them both, compare the two, and look at which solution will make the most sense for you.
What is Record and Playback?
Record and Playback is a common feature for automated user interface (UI) testing. With a Record and Playback tool, you can hit “record” and begin clicking on elements within a user interface on a website or web app. The Record and Playback tool will record your interactions so that later you can hit “play.” The tool will then recreate your interactions—every navigation, click, or keystroke–in the browser, exactly as if you performed them yourself.
These scripted interactions can then be manually kicked off to run later as needed. As the automated test runs, it will return error messages if the automated testing tool fails to complete one of the interactions as programmed.
Understood through the Jobs-to-Be-Done framework (JTBD), automated UI testing via record and playback does the job of repeating manual interactions as a check to make sure key functionality works as designed.
These test scripts can also be integrated with other systems to:
Run on command as part of a QA process
Run on demand as part of the build process, to prevent broken code from shipping to production (this is typically referred to as "automated testing within continuous integration / continuous delivery"), or
Run on a schedule from remote machines to monitor performance of a site or web application proactively, watching speed and reliability (this is typically called "synthetic monitoring" or "transaction monitoring")
What are some Record and Playback tools?
Common record and playback tools include:
Benefits and trade-offs: Record & Playback tools
Record and Playback tools can be helpful for:
Reducing manual work in QA and regression testing,
Preventing usability or performance bugs from going live, and
Quickly creating highly portable tests for ongoing performance monitoring
Here are some trade-offs to consider:
Recorded tests are limited. You can write transaction tests to run common user flows, but it would take a whole lot of recorded tests to get full coverage of every possible click path.
Recorded tests are fragile. Because the recorded test scripts often rely on specific CSS or XPATH to reference the correct elements with which to interact, minor changes to a site's code could cause the tests to fail when they run. Scripts must be actively and carefully maintained to reflect any changes to a site's navigation or user interface.
It's worth noting that some Record and Playback tools only work in designated browsers. If you're looking to import your recorded tests into a suite for ongoing monitoring, you'll need to make sure that the script output from your Record and Playback tool is compatible with your monitoring service. (For example, some synthetic monitoring solutions will accept Selenium IDE tests but not Java-based Selenium tests; it's important to know the difference!)
What is Session Replay?
Session replay tools help you:
Bonus: If you have a session replay tool that captures all user interactions and surfaces errors errors, you basically have 100% coverage for monitoring all of the performance problems with your live site. And, you'll never have to wonder how to replicate a bug, because you'll have the interaction and console errors logged in one place. That's super valuable!
Here are some limitations of session replay tools to keep in mind:
Session replay helps you react quickly to bugs, but it might not help you prevent bugs. It is possible to use session replay on a staging environment to record errors as they occur, and it's super helpful to use session replay to QA on production or live sites, but most session replay tools won't integrate nicely into your build process to prevent those bugs from going live in the first place. That said - the beauty of replay is that every bug will be captured as it occurs, and sessions with captured bugs can help you respond quickly and keep your time-to-resolution low (fast).
Some light maintenance may be required. While session replay itself doesn't come with the limitations and fragility of automated test scripts (everyday updates and changes to your website won't break recording) you might not completely escape the light maintenance work that comes with site updates. While recording itself might not require any instrumentation, the reports or Segments that make session replay so valuable can require some ongoing attention.
Is session replay right for you?
Let's break it down:
☞ Looking for a tool to help you record interactions to create scripts for automated testing?
Nope—session replay isn't the thing to solve that problem. But if you Google "automated UI testing," you'll probably come up with something useful.
☞ Need answers about your customer experience to make critical business decisions? Want to support customers with less back-and-forth, save time spent debugging, and optimize your site or web application?
Yes—session replay is the tool for you!
But why not both?
For most organizations, it probably makes sense to have both record/playback and session replay tools in their SDLC tool kits. These tools can be complementary. In fact, session replay can be powerful for informing which user flows will be most valuable to record and automate for proactive monitoring or testing.
For example, through watching session replays, you might uncover a popular customer journey on your website that you wouldn't have known was business-critical. Once you know how many of your customers rely on that path or set of features, you can use record and playback to build a test specifically for that critical customer flow and make sure that it never breaks when you deploy new code.
