Scriptless Automated Testing is not the same as Record and Playback

Record and Playback Testing vs Scriptless Automation Testing: Which is Good?

An alternative to record and playback tools for enterprise-class Test Automation

An Alternative to Record and Playback Tools for Test Automation

Test Automation has become an immediate requirement for every engineering team to match the pace of continuous delivery. On the other hand, it can also become a waste of time, money and resources if the test automation strategy and your Test Automation tool is not a fit for your requirements.
Generally, when teams <a class="brand-color" href="https://www.utest.com/articles/why-shift-from-manual-to-automation-testing-for-continuous-delivery" target="_blank" rel="noopener noreferrer">shift from Manual Testing to Test Automation</a>, they tend to look for the simplest and easiest solutions to get started. Record and playback tools are one of the options a lot of managers consider.
Near zero initial time and programming knowledge are some presumed advantages of choosing record and playback tools. The general perception is that initial investment of time and effort using these tools. But time and again it is being proved that such tools do not work well to meet enterprise-class test automation requirements.
However, it is agreed that these tools are not suitable for test automation if you have a user interface that constantly undergo changes. 
Tests created using Record and Playback tools are often outdated for even a small change in the application. You need to re-record all of the tests or you end up spending a lot of time editing tests.
<div id="toc_container" class="no_bullets">Table Of Contents<ul class="toc_list"><li><a href="#Getting_Started">1 Getting Started</a></li><li><a href="#Why_is_it_difficult_to_generate_stable_tests_easily_with_Record_and_Playback_tools">2 Why is it difficult to generate stable tests easily with Record and Playback tools?</a></li><li><a href="#Why_does_it_fail_to_handle_Dynamic_ObjectsElements">3 Why does it fail to handle Dynamic Objects/Elements?</a></li><li><a href="#Why_can8217t_Record_and_Playback_tools_avoid_maintenance_for_small_UI_changes">4 Why can&#8217;t Record and Playback tools avoid maintenance for small UI changes?</a></li><li><a href="#Why_do_these_tools_not_support_Shift-Left_Testing">5 Why do these tools not support Shift-Left Testing?</a></li><li><a href="#How_Record_and_Playback_tools_fail_to_maintain_a_shared_Element_Repository_to_reduce_maintenance">6 How Record and Playback tools fail to maintain a shared Element Repository to reduce maintenance?</a></li><li><a href="#Why_record_and_then_edit_doesn8217t_work">7 Why record and then edit doesn&#8217;t work?</a></li><li><a href="#Why_isn8217t_Re-record_an_option">8 Why isn&#8217;t Re-record an option?</a></li><li><a href="#So_where_do_Record_and_Playback_tools_fit">9 So, where do Record and Playback tools fit?</a></li></ul></div>
<h2>Getting Started</h2>
Many teams shifting from manual to automation might look at Record and Playback tools as the test scripts are created automatically for every action that a functional tester performs manually.
These scripts can be easily re-run to test the same functionality provided the application does not change.
It may seem easy and compelling but requires a lot of rework and changes. The system generated scripts or tests are hard to understand and maintain. 
We will look more into this in detail.
<h2>Why is it difficult to generate stable tests easily with Record and Playback tools?</h2>
It&#8217;s been proved that these tools would fail to generate stable and reliable tests for enterprise-class applications that has complex scenarios with dynamic data.
A lot of manual revisions are required to make the script generated by Record and Playback tools to be stable and production-ready like editing test data and element information, adding assertions, conditional statements, handling dynamic data etc.
Also, you cannot record all the steps for dynamic enterprise-class applications. You may need to add custom actions, assertions and, dynamic steps manually.
Record and Playback tools would record both necessary and unwanted steps automatically. The recorded steps would not be as per your business documents.
Quite often, for the same action, more than one copy of the same script is generated multiple times and the tester has to identify which copy of the script requires editing. It’s difficult to understand what part of the code belongs to the test steps, what is the exact data the tool collects that needs change.
A lot of time is spent cleaning unnecessary data to make the tests reusable and readable and in-line with your business documents/process.
Maintaining test scripts would be a complex task with a lot of duplicate and disorganized elements making your tests very difficult to understand and maintain.
AI &amp; ML can be helpful to maintain these tests for basic element attribute changes. But in reality, there can be more than just element attribute changes. 
There may be layout changes, design changes etc. in which case these duplicate elements requires a lot of maintenance work from developers.
The alternate approach would be to re-record all the steps from the beginning. However, this demands huge effort having to go through the entire process over and again. And, you may lose the test history.
Identifying the problem area first from the huge script that is auto-generated, making edits to the code and fixing them is a tough task. 
The time required to manually test an application vs the time to repair the recorded steps or re-record is relatively less.
The time saved getting started with the application testing is wasted editing and re-recording every time there is change. 

<h2>Why does it fail to handle Dynamic Objects/Elements?</h2>
Most of the modern applications are built with dynamic elements with no unique attributes. In such cases, record and playback tools rely on HTML element hierarchy/absolute paths which is the most unstable and unreliable approach to build automated tests.
These tests fail during subsequent re-runs, as the attributes of these dynamic elements change every time.
The ability to define dynamic element paths as part of element repository is required to handle these cases, which is missing in record and playback tools.
Also, these steps fail even for the slightest change in the application (not just the element attributes) and are not always dependable.
<h2>Why can&#8217;t Record and Playback tools avoid maintenance for small UI changes?</h2>
The slightest change in the recorded element or any element on the page can break the recorded tests easily.
Many of today&#8217;s testing tools capture more than just the required attributes to identify a particular element. This way, whenever there is a change in any one of these attributes, any of the remaining attributes can be used to identify those elements.
This has become a standard practice in many Test Automation tools. The approach is required to address some of the maintenance issues with element attribute changes. Some of the Test Automation tools like <a class="brand-color" href="https://testsigma.com/" target="_blank" rel="noopener">Testsigma</a> use AI to create paths dynamically using the recorded attributes.
<a class="brand-color" href="https://testsigma.com/" target="_blank" rel="noopener">Testsigma</a> not just uses the Dynamic Locator Strategy on element attributes but also takes into account the attributes of siblings and parent elements to solve this maintenance issue better!
Many a time, there would be more than just element attributes changes. These tools should consider the parent and sibling attributes of a particular element to ensure that the tests won’t break easily.
<h2>Why do these tools not support Shift-Left Testing?</h2>
It is essential to start the test automation process, early on, with the Agile and DevOps methodologies demanding faster, frequent software product releases. If testing cannot keep up with these modern approaches to ensure continuous software development and delivery, the goal is not fully achieved.
With these tools, you cannot start your Test Automation until you have a stable UI to automate.
Because of this either Test Automation will be pushed out of delivery pipeline or takes more time to release your quality products. Both these options are not acceptable for current fast-paced Agile and Continuous Delivery practices. 
<a class="brand-color" href="https://testsigma.com/blog/test-automation-tool-ready-for-shift-left/" target="_blank" rel="noopener noreferrer">Is your test automation tool ready for Shift Left testing?</a>
<h2>How Record and Playback tools fail to maintain a shared Element Repository to reduce maintenance?</h2>
Whatever may be the approach, test maintenance is a continuous effort and plays a major role in automation success. Maintaining elements is highly important for test maintenance.
Record and playback tools generates a lot of duplicate elements as explained earlier and do not reuse the elements that are already available. This increases the need for test maintenance with the need to manage multiple instances of the same element.
The tools are expected to be smart enough to reuse the element if it is already recorded. None of the record and playback tools address this.
<h2>Why record and then edit doesn&#8217;t work?</h2>
Recorded test steps are not always stable and are not reusable by default and can break as the application code changes.
The recommended approach is to either edit these steps manually or re-record the entire test again.
To edit a recorded test you need to first understand the system generated test completely, then decide on what to change and how to change. This requires programming knowledge and constant reviewing. Without this, for every change in the application, these tests will continue to fail.
But the fact is that editing an automatically generated script is more difficult and time consuming compared to many programming based tools. 
Manually testing the same feature end to end takes less time and effort compared to editing these tests every time.
The purpose of Test Automation is to allow the automated tests to run unattended. On the contrary, testers are expected to sit through the whole of the execution process and find problem areas by looking them up manually and make changes to the generated code/test steps continuously. 
The test automation efforts go in vain as testers eventually shift back to Manual Testing.
<h2>Why isn&#8217;t Re-record an option?</h2>
An alternative to maintaining these tests is re-recording. 
 Re-recording the whole of the application for minor changes is not very convenient especially for large applications. 
The QA team has to go through the entire process of re-recording and editing the tests to make them stable and reliable.
Considering all the effort needed after recording, like editing, clean-up, etc., Re-recording is not an affordable solution for bigger teams who practice Agile and Continuous Delivery methodologies.
<h2>So, where do Record and Playback tools fit?</h2>
Record and playback tools can be considered for small static applications whose application code and UI does not change frequently.
 It would be appealing to the management to introduce the concept of Test Automation, what and how can be automated and how much time can be saved through Test Automation once the automated tests are in place.&nbsp;
The better approach would be test automation with the same simplicity of record and playback tools along with enterprise-class flexibility and stability.
Check out <a class="brand-color" href="https://testsigma.com/blog/alternative-to-record-and-playback-tools-for-enterprise-class-test-automation/" target="_blank" rel="noopener noreferrer">an alternative to record and playback tools for enterprise-class Test Automation</a>