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 tools used to help you deliver better customer experience. Despite the names, each serves a vastly different purposes 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 are designed to help site owners understand how real visitors or customers interact with their websites or applications. With a session replay tool (E.g. FullStory[1]), you vicariously experience what it was like for real customers to interact with your site (or app). Session replay tools record all user interactions in the browser in order to reproduce those events. The result looks something like a video though it's technically more complex.

For a deep dive into session replay, see The Definitive Guide to Session Replay.

Benefits and trade-offs: session replay tools

Session replay tools help you:

Bonus: If you have a session replay tool that captures everything and easily shows you 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 get captured, 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 canc require some ongoing attention [2].

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 and 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 replay, you might uncover a popular customer journey on your website that you wouldn't have necessarily predicted as 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.

That's a proactive way to prevent customer frustration and reduce time spent responding to bugs, too! So yeah, why not both?

Do you use record and playback tools and session replay tools? Let's hear about it!

  1. FullStory is best-in-class, pixel-perfect session replay. The tool captures everything—all navigations, clicks, keystrokes, and errors encountered from real site visitors. The app makes that data available for searching, segmenting, uncovering frustration signals, analyzing click maps and more. ↩︎

  2. For example, if you have a saved custom Segment report to watch all sessions where customers click "Purchase" and you push a change so that the "Purchase" button is now labeled "Buy," you'll need to update your saved search or Segment to look for the newly named "Buy" button. ↩︎