In-Sprint Automation: Is it just a wish or can it be achieved?

In- Sprint Automation: that’s a dream for every project manager and client working in Agile. But very rarely do we see project teams considering this option because the source code development and the UI Automation code development together have very high chances of expanding beyond the allocated sprint duration. So we decide to settle for n-1 sprint automation as it’s the next best thing.

However, if we do not do in sprint automation we are essentially creating technical debts. The reason for opting to automate is to reduce or completely remove manual regression testing efforts. But if we do not do in-sprint automation, we are not performing automated regression for the build delivered for that sprint along with the latest features developed. This proves to be of great consequence when the new feature developed throws several integration scenarios and has an impact throughout the application.

Manual regression cannot be done for every sprint owing to the enormous efforts involved. All that testers can do is to test the features that are directly related to the story, test the related impact areas, and also do a high-level sanity check of the existing features. But this does not provide assurance that all the features that already exist are in fact working as they should in the latest build.

It seems to be an impossible problem to solve. On one hand, developing automation scripts for an unstable product can lead to redundant efforts. On the other hand, we lose out on the core benefit of automated testing if we choose not to automate in sprint. There is a way out of this. Here are some strategies by which we can achieve in-sprint automation.

Collaboration is Key

In order to implement and successfully achieve in sprint automation, the first important thing to incorporate into your process is for the automation testers to collaborate with the business analysts, the functional QA folk, and the developers.

The Business Analyst

When the automation testers collaborate with the business team, they get an idea regarding automation priorities — the workflows which cover the core logic and integration checkpoints of the newly developed feature. If you have to encourage any thoughts of achieving in-sprint automation, then it is critical to understand that you cannot automate everything.

To ensure that the right things are being taken up for automation, the business team can provide insights into what the new feature is about, its purpose, how will it be used by the end-user, and how does it fit in with the existing features. Gaining this perspective will give the automation tester a good idea about which tests to automate.

The Functional Tester

Functional testers are capable of providing the automation team a drilled-down perspective of the feature being delivered and provide key insights into the business-critical integration scenarios. They can also prioritize test cases in coordination with the business analyst and provide data sets that can be incorporated into the data-driven automated tests. The test cases written by the functional tester serve as the base to derive automation script journeys. Many a time, you might find that the functional test cases contain scenarios which you, the automation tester, or the business analyst haven’t thought of.

The Developer

Early collaboration with the developers provides automation testers the golden opportunity to educate them about the requirements that would make automation scripting much easier. Such expectations of the application being developed are termed Test Automatability. It’s nothing but how easily, the elements of a page can be identified, whether each element in the page has been assigned a unique id and other features of the application that help reduce automation effort and the formed scripts to be stable.

Unique attributes such as class, id, value, help the identification of HTML elements in a page much easier, make the locator strategies and scripts more stable, and less prone to failures even when there are additional UI elements brought into the same page. A leading cause of flaky tests is the unreliability of the identifiers of the HTML elements. So by collaborating with the developers, the automation testers can work to implement this as a coding standard.

This meeting is important for another important agreement between the developer and the automation tester and that is the mock-up of pages that are to be developed as part of the new feature. The automation tester can mock out the design of the page and the elements in it and get the developer’s concurrence. Since the locator identifiers have been standardized, this mock screen acts as the contract between the developer and the tester.

The automation tester can now start scripting the workflow even before the developer has started coding for the feature. By establishing this mock-up the developer is now aware of the test automatability standards that need to be adhered to and if a deviation is somehow necessitated, it will be communicated to the tester promptly.

Implement Hybrid Automation Strategies

UI Automation test methods contain much more than just the scenario that’s in focus for that test method. You might call other page methods in order to set up data, navigate and clean up data post the execution of the test method’s core logic.

Based on the workflows to be automated, the automation testers can ask the developers to build Code Seams or specific APIs to help quicken the process of UI Automation scripting and execution. Code Seams can be used by automation scripts to quickly achieve something that’s a pre-requisite for the execution of a particular script or to clean up the data after the script is done executing. This setup and tear down of data is crucial to make the automation test methods reusable. Consider the scenario where you need to delete the products in the shopping cart after updating the quantity. As a prerequisite, the following steps need to be performed before the quantity of the product can be incremented and the shopping cart can be updated.

• Search for the product.
• Validate the presence of the results.
• Click on a specific product.
• Navigate to a product detail page.
• Provide quantity and configuration selection.
• Click add to cart. Validate the mini cart.
• Click mini cart and navigate to the shopping cart.
• Update quantity and validate price changes, quantity changes.
• Delete product from the shopping cart.

A significant amount of coding would be required to incorporate all the above steps and even if you have the code already written, the time taken for these steps to be executed cannot be avoided in another test method where you would be validating the update and delete of items from shopping cart specifically. When a huge number of test scripts are being run in a suite, execution of redundant test steps must be avoided to minimize execution time. With Code Seams, we can achieve these steps by simply accessing a URL.

This method of automation essentially bypasses the UI by performing a service level automation, by coming one step down in the testing pyramid. This is one of the prime examples where developers can contribute to improve the test automatability of the application and help reduce automation effort significantly. This method of switching between UI and service level automation is termed Hybrid Automation.

By using Hybrid Automation, the script steps would contain:

• Call API to add a specific product to the cart using a unique Product ID and quantity
• Launch shopping cart page.
• Update quantity and validate price changes, quantity changes.
• Delete item from the shopping cart.

Apart from reducing scripting and execution time, this method is also less prone to errors. Since you are not executing redundant actions, you are also effectively cutting out the chances of failure of your scripts in those steps. So there are fewer lines of code, which means lesser effort, lesser time taken for execution, and the flakiness of scripts is also reduced, which in turn saves even more effort which would otherwise be required to fix the issues and stabilize the script. And thus, the chances of meeting the In Sprint Automation goal are increased.

Develop Scripts Incrementally

If you want to achieve the goal of In Sprint Automation, one of the key rules to follow every step of the way is to remember that not everything that’s developed can be automated. Suppose a new page is being built as part of a new feature. It’s not ideal to start scripting the page class with all the functionalities on the page. Instead start writing the test class first, covering the scenarios that have been confirmed for automation. Include yet-to-be-created page class methods with appropriate names in your test class so that you will know exactly what needs to be created in the page class and do nothing more than what’s necessary.

To avoid deviation, in such cases, it’s best to follow a TDD approach which helps you to switch between the tester and developer mindsets seamlessly.

Also, if a feature is developed but not the entirety of its functionality is going to be completed in the sprint, do not wait for the functionality to be completed to start automating. Consider a typical eCommerce My Account page which has all the basic details of the customer in text fields and an update button. For the current sprint, the development delivery is the complete My Account page except for the Update click. The updated click does nothing now. If you wait till the next sprint for the Update button to be clickable, and the update function to work to start automating the My Account feature, then you would have to code to validate if all the registration details are properly reflected in the My Account fields, View Account details and in addition to that, the update of My Account, which would become an overhead.

Do not postpone the scripting of features that are yet to be completed because if you do, firstly you are not actually achieving In Sprint Automation, and secondly, achieving In Sprint Automation in further sprints becomes even more difficult due to the cascading effect.

By utilizing the above three techniques, and by making subtle process and coding standard changes, through collaboration and early confirmation, you can bet that In Sprint Automation will no more be just a wish. It’s quite possible to make it a reality.

Author: Mohan Bharathi Srinivasan