Are You Confused Between Scripting Testing and Record & Replay Testing?

So you are planning to make a move towards automation testing. But you are continuously debated about which one to opt for? Should you make a move towards Record and Replay automation testing? Or Would you rather stick to good old scripting? In this article, we will help you gain clarity among the differences between these two approaches i.e. Record & Replay & Scripting testing.

Software Planning, Development, & Testing are critical activities that you would come across in any project and each of these activities cannot be executed in a silo since every project will have some ‘internal & external dependencies’. When it comes to testing, you should follow the right mix of ‘Black Box Testing’ and ‘White Box Testing’. The primary difference between both the test methodologies is the depth of technical expertise required for test strategy, test planning, test scripting, and test execution. A tester whose expertise is in ‘Black Box Testing’ tests the product against normal & boundary use cases without having any internal knowledge about the source code. This approach is completely contrary to ‘White Box Testing’ where the tester writes test code in order to test functionalities of the product.

‘Record & Replay testing’ is a popular testing mechanism to perform Black Box Testing. It is ideal for products that have static user-interface and fewer changes are pushed to the production server (at least from UI/UX point of view).

Insights Into Record & Replay Testing

As the name signifies, pre-defined test scenarios are recorded & those can be played at the push of a button (i.e. ‘Record’ to record use case and ‘Replay’ to playback the recorded use case). This approach sounds interesting since the tool lets you create a script that can execute those recorded actions automatically. There is a huge upside to this approach since the QA team can get started with the product testing at the earliest and the QA team does not need to have any programming expertise. It makes a perfect choice for organizations preferring to perform “Shift-Left” Testing.

It is a known fact that product requirements can alter bug fixes over a period of time which may result in changes of back-end code, as well as changes in the user interface (front end). In such a situation, record & playback tests would break since those tests have been created with the assumption that there would be infrequent changes in the UI.

Record & Replay can be the first step to learn about test automation since the tester does not require any scripting/coding expertise. It is a good learning tool for someone who comes from the Manual testing background and wants to get a foothold in the world of ‘Automation Testing’. However, the recorded scripts can be large in size as the number of use cases increase and this would impact the execution speed of these scripts. It is an ideal approach for a product where the changes in the UI are far-fetched since it would not have much impact on the recorded scripts. To summarize,

• Record & Replay testing is suited for applications/websites where testing schedules are tight.
• It is ideal for test teams who have a background of Manual testing and want to venture into Automation Testing.
• It can be used by members who are outside of the development/test teams.

Major Real-Time Problems That Can Occur With Record & Replay Testing

Every technique has a downside, here are the ones with respect to Record and Replay Testing:

Problem 1 – Too much recording

When you navigate on any website, you tend to perform many actions and some of these actions might be unintentional. The issue with Record & Replay tools is that it would record ‘too much information’ and majority part of that information can be ‘noise’ i.e. not required to be a part of the test script. For example, below is a snippet of the recording

• Move the mouse to location 100,200 (relative X, Y coordinates)
• Click on ‘Userid’ text box
• Type the user-name
• Click on ‘Password’ text box
• Type the Password
• Wait for 5 seconds
• Click on ‘Submit’ button

The scenario looks perfectly fine, but a delay of 5 seconds could be misleading. There is a possibility that tester might have entered the wrong password and was trying to delete the same or there could be some other reason.

Problem 2 – Too less recording

The problem with Record & replay tests is that sometimes the recording would be too less and such a short recording would not transcribe into a ‘valid test script’. In such a scenario, the recorded test script has to be re-recorded which may take more time & a couple of re-tries.

There is also a possibility that you record the wrong thing and the time taken to do the recording would be exponential depending on the complexity of the use case. For example, while recording a use case, you commit a mistake at the last step. Since you cannot record in parts, you need to re-record the whole scenario.

Problem 3 – Modification of test cases & execution of test cases in a loop

Consider that you have a test scenario where you have to test the authenticity of a user. This would involve permutations & combinations of test cases based on ‘usernames & passwords’ in the respective fields on your web-app/website. If you plan to perform the testing using ‘Record & Replay testing’, you have to perform the same task for every set of username & password. You cannot modify the ‘recorded test script’ to enter the details about each user in the script.

Since the recorded test script might not be understandable (i.e. it could be HexCode that can only be decoded by the Record & Replay tool), you would have a new script for each scenario; even though the change in the test scenario might be minimalistic in nature.
These are some of the major downsides of Record & Replay testing, but it can be an ideal starting point for someone who is interested in Automation Testing. Plus, it can be executed by anyone belonging to your organization, from your DevOps team to your Marketing one.

Insights Into Scripting

Creating test scripts using Selenium (an open source tool for automating web applications) is considered as the most sought-after an approach for automation testing. Unlike Record & Replay testing, a tester who is assigned the task of writing test scripts using Selenium framework needs to have a fair amount of coding expertise with Python/PHP/Perl/Ruby/other programming languages.

Depending on the functionalities that need to be tested, the tester should also have an understanding of the different modules available in Selenium for the corresponding programming language. Script based testing is always a viable option for any kind of project (whether it is in the development phase or maintenance phase). Since Selenium is a widely used test automation framework, it is likely that members in the development team would also have a good amount of knowledge about it. In such a scenario, they can co-work with the testers and come up with effective test cases and test scripts that have long-term benefits.

Unlike Record & replay tests, modification of scripts (that are written using Selenium) is possible; though the turn-around time depends on the coding expertise of the script developer/tester. It is also suited for performing stress testing & regression testing which makes it a ‘more scalable approach’ for automation testing.

LambdaTest blog already has a number of resources to get started with Automation testing which can be helpful to get started with Automation. Plus, we are regularly posting more and more blogs for you to go about automation testing.

To summarize,

• Scripting using Selenium is preferred by testers who have a ‘development mindset’ and possess knowledge about frameworks like Selenium.
• It is suited for creating test suites/test cases in a more robust manner.
• Test scripts using Selenium framework can be used to achieve the best ‘code coverage metrics’ i.e. the test code can be used to test even the boundary scenarios along with the normal test scenarios.
• Suited for performing end-to-end testing.

Conclusion

Based on the timelines of the project & technical know-how of the test team, you should choose either Record & replay testing or Scripting using a framework like Selenium. Though each approach has its own share of pros & cons, an ideal test plan is the one where tests are executed in parallel. As a tester who is responsible for testing the features of a web application/website, you should keep in mind about cross browser compatibility of your web-app across different browsers, operating systems, and devices. Parallel Testing can provide the maximum throughput as far as automation cross browser testing is concerned. If you are new to automation then Record and Replay can save the day for you. Once the tests are saved using the Record & Replay, you can execute those scripts in parallel (on different combinations of browsers, operating systems, and devices). However, If you are already proficient with programming language then Selenium can offer powerful, customizable multithreading capability for running automation cross browser test cases in parallel with maximum efficiency.

Harshit Paul

Harshit works as a product growth specialist at LambdaTest. He is also an experienced IT professional, who loves to share his thoughts about the latest tech trends as an enthusiast tech blogger.

See author's profile