Top 5 Factors that Influence your E-Commerce Automation Strategy
Should you have an automation strategy? What are some best practices for implementing an automation strategy? Before we discuss the factors influencing automation strategy, let’s first understand the purpose. Automation is used to reduce the time and cost involved in manual functional testing and repetitive tasks. As it relates to manual testing, it can become monotonous, especially in large complex products that have been in development for several years. Subsequent rounds of test executions might not give consistent results due to human error or testers missing important steps/issues because of carelessness. Or complacency can gradually creep in without notice.
Automated tests give faster, more accurate, and consistent feedback. Real-time feedback loops are a crucial component for any continuous integration strategy to be successful. Consider a new functionality that has been included in your product’s latest release. When this new functionality is tightly coupled to an existing one, the true value of having a stable automation suite is readily apparent. A comprehensive automation suite finds all the impacted areas at once, but the same cannot be said of manual testing due to the reasons explained above. Automation helps developers analyze impacted program modules while providing ample time for successful remediation and automation execution.
How to Implement an Automation Strategy?
Somebody new to automation, due to enthusiasm or short-sightedness, might get on with automating everything that’s in the application. However, this could result in an automation test suite that takes several hours to execute over time. In this particular use case, automation could take a longer time to provide results, thus discouraging developers, and ultimately resulting in less frequent and larger commits. This is a dangerous proposition because, with larger commits, the chances of things going wrong are higher. In addition, if the new code causes a bug with larger commits, the effort needed to analyze which part of the code caused the problem is infinitely more difficult. So rather than complete automation, the focus should always be to create and maintain a high-value test suite that aligns with the goal of continuous integration and delivery.
Note the scores of the parameters for each functionality covered in automation: business-critical nature, defect density, the impact of new functionality, and then total the score. The functionalities that score the highest should be featured in the automation suite.
Review the scores of the automated functionalities with each iteration or milestone of the product being released to the client. The score for each functionality for all three parameters varies with each release.
Below are the three things to note in terms of automation functionality:
- A functionality, in its early days, will score high on business relevance.
- Initially, unstable functionality will score high on defect density.
- Functionality that’s impacted heavily by the introduction of another would score high for impact.
But as time passes, the score comes down, so your automation suite should be designed in a way that allows for specific tests to be excluded. Automation scripts should be made independent as far as possible. The business relevance of certain important features might never change, so consistent collaboration with key stakeholders is important. One should also observe the history of automation execution results because scripts passing for several months can be labeled as stable and can be excluded from future runs, provided they score low on all three fronts.
Top 5 Key Factors influencing Automation Strategy
1. Importance of Risk Analysis Done Right
The value of automation is not just about risk analysis, it is also about the level of risks being mitigated. Assessment of risk doesn’t depend on defect density alone. How much of a risk is it for the organization if something doesn’t work? How much of an impact does it cause to the end-user? How much reputational damage does it cause to your organization? A tester, on his own, cannot arrive at the answers to such questions, and that’s why consistent communication with business teams is crucial. James Bach published a paper called Heuristic Risk-Based Testing, which provides a list of key questions to evaluate risks in an enlightened manner. Although risk analysis doesn’t play a part in the technical implementation of automation, it does play a key role in the initial stages to help decide what needs to be automated and what’s important in the eyes of the key stakeholders involved.
2. Use Objective Criteria as Key Measures
It’s always a good practice to start automating a list of objective statements that are critical to the application, such as those that address the highest risk areas, like the first cut. Objective criteria are facts that are known and do not change and most functional requirements can be taken up as examples for objective criteria.
Functionalities that can be fit into the BDD construct of Given, When, Then can be categorized as objective criteria. Teams that leverage BDD scenarios or the highly successful Three Amigos meetings to define the objective criteria almost always come up with a robust set of automation test scripts in the end.
3. Be Careful What You Choose To Evaluate
Automation tests can validate only what they have been coded to validate. So when trying to assess the cost and value of automation, do not just observe the time it would take to automate a workflow. Also, be sure to think of the number of manual tests it would prevent you from running, and the resulting amount of bugs…and their severity had you chosen to test the workflows manually. T. This is termed opportunity cost, where you choose to invest effort in doing automation instead of doing something else.
For example, consider a new functionality that’s included in your product. If this functionality affects an existing one, the automation script for the existing functionality may or may not find a regressive issue caused by the new addition. In contrast, a thorough manual test would capture it. So automation should be carried out when the opportunity cost becomes low, meaning the workflow is stable and there aren’t any high severity issues remaining to be found.
4. The Hunt for Repetition
Seeking repetition is one of the key steps that help you decide what to automate. It could either be a repetition of testing activities — a functionality that you have to go through every single time to test others, or the repetition in code. For example, the same widget is being used in several parts of the application. In both cases, we can use automated scripts to validate and confirm if the behavior of the repetitive workflow is consistent across multiple builds and browsers, and whether the widget behaves the same way everywhere in the application. We can reuse the same automation code if the widget is used elsewhere in the product in the future. Collaboration helps a tester during the hunt for repetition. Developers can guide testers to discover unknown or unobserved code repetitions and help reduce automation code redundancy.
5. Change in Organization’s Strategy
This criterion applies to only long-running products. Product strategy is bound to evolve as the technology landscape changes and the market caters to these evolving requirements. As features are added to the product and existing features are modified, those previously considered risks might become trivial, but new risks might evolve. As features get modified or added, what’s objective and what’s repetitive might also change. The time available for automation can also change. So it’s important to keep apprised of these changes when evaluating automation strategy. Understanding the cadence of organizational change is crucial such as does it change frequently or rarely, and are the changes predictable or unpredictable? The pace and nature of the change will impact the decisions you make for the automation framework and design. Based on these organizational changes, you can decide what to automate with a forecast of how things might change in the future to keep your solution relevant.
When Does a Workflow Qualify for Automation?
We should evaluate the following points thoroughly before deciding on the workflows to be automated.
- Is the workflow frequently subject to human error during manual testing?
- Is the workflow stable, low risk, and expected to have minor to no changes in the future?
Using a checkbox strategy, you can pick the workflows that have reached the maturity to be automated. When you decide that a workflow has matured enough to be picked for automation, the point in time plays a major part in reducing redundant effort, determining the value of your automation suite and its final ROI.
What Type of Workflows Should Be Automated?
As a rule of thumb, it is prescribed that automation of the highest priority workflows be taken up first. However, when deciding what type of workflows need to be automated, the following questions should be asked and answered with complete clarity.
- Does the workflow encompass legal and compliance-related matters?
- Is the workflow a critical path? Is it complex and time-consuming to be executed manually?
- Is it frequently reused as a prerequisite during manual testing to perform other functionalities?
- Is there a lot of data setup involved?
Evaluation Table for a typical Ecommerce application
Tally the scores for each and the functionalities and those that have the highest scores should be addressed first.
Applying Marketing Insights and Analytics Data for Automation
Make the best use of marketing insights and data from tools like Google Analytics as they provide you key information about how your end customers use your application, their location, and other related information. This information, combined with the answers for the following points will help in determining automation priorities.
- Most popular devices on which real-time users access your application.
- Most popular browsers with which end users access your application.
- Most popular workflows that customers perform in your application.
- Most frequent points of jump — points in the application after which the end-user ceases to use it because of bad UI/UX or complexity, lack of intuitiveness, or a host of other reasons.
Such data clarifies the workflows that need to be constantly featured in the automation suite and the browser/device combinations against which the scripts need to be executed.
Automation Strategy vs Product Strategy
Observing the bigger picture and understanding the product strategy is key because it directly impacts automation strategy. For example, consider the examples below of three different types of products and think about how the automation strategy differs in each.
Product 1: It’s a prototype you plan to release to the market for fast and authentic feedback from real-time users. The next version of the product might be significantly different when compared to the first. There is an emphasis on faster time to market and faster feedback.
Product 2: This is expected to become the marquee product of your organization in the next five years. There is a strong emphasis on technical architecture to make the product scalable in the future. The progress here would be at a steadier pace and never as hurried as in Product 1.
Product 3: The first release in a series of applications migrating from legacy versions to new-age infrastructure. The emphasis here will be on standard practices and common implementation. The product will also progress at a steady rate like Product 2 but never at the rate of Product 1.
For Product 1, investing much time in designing and constructing an elaborate framework is unnecessary as the next version could be entirely different. Automation scripts for such a product can be shallow, dirty, and quick. They need to be effective, and that’s about it. So it would be best not to worry about maintenance or code smells here. But the same doesn’t apply to Product 2 and Product 3.
For Product 2 and Product 3, analyze which features in the backlog are the most important. Use the prioritizing strategy discussed earlier and think about which currently implemented features are prerequisites for upcoming features. Since this is a product, certain features would score high from the point of view of your sales team and certain others from the point of view of your client. It’s important to decide whether the automation will focus on areas that are critical to both parties or just one.
Determining which parts of the current implementation would be affected when the upcoming features are incorporated, which part of automation must change the code, and how much effort is that change going to demand are factors that need to be carefully examined during the prioritization of automation workflows. Unlike Product 1, for Product 2 and 3, it’s wise to invest the required effort in designing the framework, the automation scripts, and the suite to be data independent, reusable, scalable, and flexible.
Collaboration is the Mother of all good decisions.
Deciding what to automate and leave out shouldn’t be a tester’s or a test manager’s responsibility. It should be a team effort. When we say team, it doesn’t mean the QA team only, but every team involved in the project, namely development, business, delivery, sales, and marketing. Each team brings a different perspective on why they think something is important and should be automated. True collaboration happens when you allow yourself to be influenced by the opinions of others, but also put forth your opinion to be evaluated by others.
To discuss Automation best practices in more depth based on your specific company’s environment, please reach out to connect with us now!
Authored by: Mohan Bharathi