How to Build a Test Automation Strategy?
Software development is a path full of chaos. Here’s why!
Software projects start with excess enthusiasm. It starts with the design, then comes the architectural pattern, and everything looks fine. Even ahead of the schedule. But then things get weird. Rework happens and you’re now a bit behind schedule.
In the end, your time-to-market is months behind. You cut some corners knowingly acknowledging the technical debt. Because, of course, you’ll take care of that later. Finally, you ship to production. First some bugs trickle in and then it streams in. Now, you’re in the loophole of breaking/fixing things in parallel with new development.
You think software testing automation can save your time and things can be back on track. You start doing things only to find that everything is haywire. Because you don’t know which tools to use or have any software test automation strategy in place. At the end, it turns out, you’re never going to pay down that technical debt.
Why does implementing test automation seem to be a rescue option, rather than the rule of thumb, in software development? Why, after all these years, does software testing still inevitably seem to work out this way?
Let’s help you out!
Test Automation: How to Get Started?
One of the missing parts in the software development industry is bug fixing, which leads to delays in projects. This is backed by the world quality report that suggests 61% respondents have difficulties in automating their QA, resulting in the biggest disregarded costs. Test automation breaks the conventional pattern of finding and fixing bugs and fixing them back followed by the longer regression tests.
“Test automation is making software work to test one.“
The figure shows the initial time & efforts it takes in learning the best practices of test automation. But we can see how it saves the overall effort and time spent.
It’s like, it takes time to learn a programming language. But then, we have today’s world.
The critical scenario that comes up is at the time of software delivery. And testing turns out as the common “bottleneck.” We started our test automation journey back in 2010, which brought a major change in our processes. Now, why did we need that change? Not because we couldn’t cope with faster deliveries, but our process needed to be more productive.
I didn’t have much experience with test automation back then, but it was more of a learning experience for all of us. We, at Simform, however, applied test automation for a pharmaceutical client (one of our then clients) where the UI was tested first followed by the known areas and eventually, we took off in the direction of fully automated test runs.
At the time of manual testing, we used to allocate half of the time to testing. Later, if things go well, we deliver the product/software. Otherwise, again we’d get back on phase one of development. Because developers could never come to know the faults until they complete the entire thing.
With test automation, we’ve learned a lot and have started strategizing it with the help of experienced agile coaches. Let’s understand the test automation strategies below.
Test Automation Strategy
As said in the tweet below, test strategies should be made specific to the project. Let’s walk through the steps that will help you define the strategy for your next project.
#1. Defining your goals
When I started my career, test automation wasn’t looked up with many aspirations. We have faced many test automation challenges like you might have too. If you ask me today, things have changed dramatically, mainly due to the availability of reliable tools. However, this doesn’t mean we automate everything we can. The first step towards a successful enterprise test automation strategy is to define our goals and figure out which tests to automate.
The deciding factor for any test to automate is linked with how many times that particular test can be repeated. The best example of a test that can be automated is the one that runs often, is a mundane task, time-consuming, and requires a huge amount of data to perform the stipulated task. Here’s the list of potential test cases that can be automated:
- Automate tasks that are highly repetitive, for example, log-ins.
- Tasks that carry high risk or probability of failure or high
- Tasks that require testing over multiple browsers/devices/OS/environment/hardware/configurations
- Tests with clear pass/fail results
- Automate tests that require operating through multiple data sets
- Automate exercises that allow for multiple options, for example, form submission that accepts different combinations.
- Tests that require a lot of time if done manually; for example, we had a test that required logging in every time we run a new task.
- Lastly, you should definitely automate tests that require checking of stable features.
Andrei Mikhailau, Software Testing Director at ScienceSoft, and his team applies test automation to reduce the meantime to validate new features or fixes, improve regression testing coverage, and eliminate human errors. They also apply automated tests when manual testing is inefficient or impossible, e.g., for testing performance.
However, their biggest challenges in test automation resides in surviving the fast and frequent UI layout and functionality changes. Even the smallest modification may require a rewrite of a substantial number of tests. One of the ways to minimize this inconvenience is to ensure maximum test code reuse. Creating standard high-level application-specific libraries is a suggested option here.
Success in test automation requires you to plan things meticulously. Once you’re done defining your goals and scope of test automation, the next step is to look out for different test approaches.
#2. Planning a test approach
My overall experience in testing has taught me one thing: the overall testing culture in any organization is highly influenced by the prevailing testing approach, apart from how they envision the test automation and how are they planning to collaborate beyond the development teams.
This means retrospecting the current process, finalizing and deciding the new test approach as well as determining the level of testing, roles, and responsibilities of the team members.
But first, let’s decide on the testing method that can provide the maximum value when automated. Different testing methods can be employed for different testing levels.
Unit testing is the backbone of any test automation strategy in agile that provides the team with the highest ROI. This testing employs a small piece of code (either function or method) that developers can write, execute, and maintain.
For instance, if you’re constructing a building, a unit might refer to the cement. This cement is one functional piece of code that is irrelevant outside the context. You could test this grey powder separately to check if it hardens after mixing with the water.
Likewise, each unit should be tested individually, but this won’t provide you with a house. Unit testing will give you observability at a granular level which is important for the developer, however useful for the product owners. It is recommended to run these tests locally and in the build.
Imagine yourself updating your product build. Now, you return to your product to check the new functionality only to land in disappointment because the feature that you’ve been using since ages has stopped working.
Each time you introduce new functionality into your product, you need to check whether it breaks or makes the existing features. Since regression tests return investments after each build update, they should be your second most priority after unit tests.
Let’s take our constructing a house metaphor a little further. You’ve tested bricks, cement, tiles, and everything that is needed to construct the house. Will all these ingredients result in a house after they’ve been assembled together? And does it look like a house at all?
Component testing doesn’t care about the quality and quantity of these entities. It only tests the overall business value.
Imagine a house. A house will have all sorts of parts– bathroom, porch, dining room, kitchen, etc. Are each of these areas easily accessible? For example, will a person looking for a bathroom result in him actually finding a way to it? The utmost concern of the end-to-end tests is to see if all the components of the product can interact with each other in the correct order.
As the name suggests, this type of testing is slow since it conducts the test of the entire business flow from beginning to end. It is surely an effective way to verify the system interaction, but only when you don’t have too many systems.
We always run these tests in our release pipeline once the system is deployed. You can also run it locally if your architectural pattern requires.
As said earlier, end-to-end tests are complex by nature. So how do you tackle this? Well, the solution that has worked for us is to select the tools that are easy to use, maintain, and scale so as to ensure the long term success.
Integration and API testing allows you to test how well the system works with the external systems. In other words, how stable your system is when it comes to interacting with APIs.
Since modern software development relies on APIs & SDKs to a larger extent, validating the overall business logic and app’s behavior is critical.
The best way to execute these tests is to run them before deploying the system in your release pipeline. We often automate API tests that are repeatedly executed like regression cases. The common test cases where we run automated API testing are the areas where the changes of the code directly affect the API functionality.
Checking your app’s functionality over multiple browser/OS/devices/screen resolutions is no brainer. Conducting these tests manually is a time-consuming task. But what if you want to do it at scale with high speed? The answer, automating the cross-browser tests.
Automated cross-browser testing has tremendously increased the test coverage and reduced our testing efforts and time by 80%. Leverage the power of test automation by conducting tests for the most common combinations your target users employs. Another focus area should be testing high-risk features.
We conduct smoke tests to verify and get instant feedback about the system builds. It ensures that all the critical functionalities (config, permissions, .net frameworks, etc.) are working correctly.
If these parameters fail under smoke tests, the product updates are rolled back. However, a series of smoke tests is even more important since it gives us the answer to these three preliminary questions:
- Is the application successfully initiating without an error?
- Is the login functionality working correctly?
- Are the primary buttons and menus working correctly?
We run these tests in our release pipeline once the system is deployed in production. To conduct smoke tests efficiently, the number of tests should be manageable so as to execute quickly.
#3. Selecting Test Automation Framework
The test automation framework is a set of detailed guidelines that one needs to follow while writing and running tests. For example, coding standards, procedures, test-data reporting, etc. Here is the list of six test automation framework that you can choose from:
Linear Scripting- Record & Playback
One of the handiest frameworks of all. Once set, you can play it back for the rest of the time. It allows testers to record the steps sequentially. For example, navigation, inputs, etc.
- Coding expertise is not required
- Generates test scripts faster
- Maintains the sequence and hence easy to understand for anyone
- Impossible to re-run the test cases with multiple datasets
- Not scalable for the extended project scope
- Rework will require for the changes in the application
Library Architecture Testing Framework
Library architecture works on the principle of identifying and dividing. That means the framework easily identifies the common tasks and group them accordingly. The framework saves these similar functions into the library and uses it whenever needed by the test scripts.
- Maintains high-level of modularity
- Cost-effective and scalable
- Easy to run multiple test scripts
- Requires changes to the scripts since data is hardcoded
- Technical expertise is required
Modular Based Testing Framework
As the name suggests, the framework divides an application into separate units and conducts isolated testing. A separate test script is created for each part and later combined as merged tests.
- Modular changes will not affect the entire application
- Test scripts are reusable
- Less efforts and time for creating test scripts
- Multiple datasets can’t be used
- Technical expertise is required for setup
Data-driven Test Framework
It overcomes the glitch of the linear or modular-based framework. It doesn’t hardcode the data, but allows to store and access it from the external file such as Excel, CSV, etc. It allows testers to test the same feature with different sets of data.
- Tests with multiple datasets are possible
- Less number of scripts
- Future changes in the modules will not affect the entire application
- Framework setup is time-consuming
- Expert needed to format the data sources
- Data is hardcoded
Keyword-driven Test Framework
Keywords are used to represent the actions performed on GUI. For example, phrases like “click the link to verify” or “click the login button”. It stores the keywords externally and is used for testing the GUI of an application. These keywords are separated from the test logic, and it makes seamless testing of actions by following a set of instructions.
- Independent test scripts of AUT is possible
- One keyword for multiple test scripts is used
- Code is reusable
- Setup cost is high
- Time-consuming as the object repositories need to be setup
- QA engineer with great automation skills is required
Hybrid Testing Framework
It is the combination of previous frameworks that overcomes the flaws and boosts the benefits. The hybrid framework favors the flexibility for different applications; hence, it is quite good at bringing accurate test results.
- Flexible, reusable and adaptable
- Wide community of support
- Can be integrated with CI pipeline
- Granular reporting
- Test automation expertise is needed
#4. Select your tool
Automation testing largely depends on the selection of the right testing tools. The first step to selecting the right automation tool is to understand the technology the application is built on and test requirements of the Application Under Test (AUT). One of the main aspects of selecting the right automation tool is the compatibility with the tech stack of the AUT.
There are few tools that are popular among testers; however, they might fail to address the testing demands of certain kinds of applications. One more thing, the tool must support the programming languages and testing environments your testers are most comfortable with.
A specific example is to figure out whether your application needs both functional and performance testing. For mobile apps, if you’re targeting both iOS & Android, opt for a platform that supports both – Selenium, Appium – or you may also use separate testing suits– Robotium for Android, UI Automation for iOS.
The second step is to check whether the tool has the right balance between the supported platform and the ease of use. A growing number of platforms impose the requirement of testing the app deployments on various platforms.
You must note that even in a single variant of the platform there are various versions that need to be supported. For example, if a desktop app claims to run on Windows, then it has to run on Windows 7, 10 (both 32 & 64 bit), etc.
Similarly, a mobile application could be supported on different versions of Android and iOS. Having said that, it is mandatory for the automation tool to test the application on all the platforms with a minimal change to the configuration file once the test script is written.
A must have for test automation tool is to support cross-platform testing for all the required platforms with maximum use of the test scripts.
The third aspect is to find a tool based on popularity. Popularity is proof that the tool has the availability of support, quality documentation, and technical forums. This helps you in finding the relevant testing engineers for executing and maintaining the testing tool.
There are higher chances in the way that some of the other testers might have exposure of using the tool. For example, if we consider web app automation testing, Selenium is popular and widely used in comparison to Sahi.
The fourth aspect to take into consideration is the licensing cost of the tool. However, this isn’t as simple as comparing the pricing of the shortlisted products. You need to select the tool which has the right balance of cost and fulfillment of your testing requirements.
Firstly, there are two kinds of tools that you can choose from– open-source and commercial. Open-source tools are an attractive option; however, commercial tools offer better support and learning resources.
Yet, while choosing an open-source tool, the license agreement needs to be carefully assessed before purchasing since all come with their own caveats. There are two kinds of license associated with commercial tools:
- Development license which allows you to write scripts on the limited number of machines
- Runtime license which allows you to execute tests on a limited number of machines
Commercial tool necessitates you to buy both the licenses while the open-source tool provides them for free. Lastly, the two important aspects that we consider at Simform are integration with project management software & CI suite, and the availability of training resources and customer support.
In my experience, building a custom test automation framework over a free open-source tool has worked best so far. The greatest advantage is control. With the in-house automation path, what you will need is exactly what your team builds.
If you’re still not sure how to get started, you can choose both initially. Most commercial tools come with a free trial period. At the same time, you can start building the MVP of the in-house framework.
After three weeks, it should be clear whether the commercial tool will work or it is within the budget or your in-house tool is a better option. Hope this helps!
#5. Create and run the tests
Once you’re done with creating your test automation strategy and selecting the right tools, it’s time to write and execute the scripts. From time and again, we’ve observed that making automation testing a part-time job of manual testers decreases team morale and productivity.
These are the two things we’d not suggest you to compromise with. Suggested option is to hire a dedicated automation testing team. If hiring isn’t a feasible option for you, outsourcing software testing services can be a good option.
When you start writing test cases, it is advisable to follow best practices. Here are a few of them that we rigorously followed at Simform.
- Writing test case templates in a way that they could be re-used in multiple projects. Before writing any new test cases, we make sure to check if there are similar test cases written already. This helps us in reducing the redundancy.
- Often times it happens that the one who has designed the test case isn’t the one executing it. This has encouraged us to write test cases in a concise and understandable manner.
- Over time, we’ve learned to prioritize each test case based on the feature or component involved. Practicing this helps us in ensuring that high priority cases are executed first.
#6. Maintain scripts
Maintaining test scripts involves scrutinizing the testing parameters. For instance, when the product is rich with features, implementing a regression test may take more time and under-exploit the importance of test automation.
For such cases, maintaining test cases plays a crucial role. The test cases should be optimized and categorized in such a way that it evaluates the subset of test cases and clearly defines the purpose of test automation.
In my experience of working with agile coaches and QA professionals, I’ve always been advised to remain focussed on maintaining the effectiveness of regression tests.
This can be achieved by periodically cleaning older test cases and categorizing the current ones. You should remain clear on your requirements and whether old test cases are effective to keep.
Test scripts should be minimal with more outcomes. If you can make smaller test cases, automation becomes easier.
For example, if you are testing an eCommerce website, you have to check events such as placing an order, selecting an item, completing the transaction, and more. Placing an order requires clicking on the button and it can be separated from the navigation test case.
Automation will not do everything automatically unless you trigger it. You will have to make it work for you by designing the test cases as per the need since it is directly related to your product delivery and ROI. Ask your QA analysts to work on subsets of test cases to save a lot of time.
The more streamlined the test cases are the more rapidly a software can be ready for production.
Don’t go for meandering objectives when writing a test case. Keep it concise. Keep narrowing the scope of a test case when it comes to automation. For example, when you write a script for checking whether a user can upload a profile picture or not, the script should not outperform the scope.
It means it should not be checking whether the user can successfully register or not or should not be trying to change the profile picture in order to check the upload process. You need to automate the process of checking functionalities. In order to automate other functions as well, you can better split the test cases separately.
Over time, while implementing test automation, we have realized that in order to be successful, automation needs to be everyone’s job. We worked hard on changing the way how business analysts and testers collaborate together along with creating and running tests.
By implementing the automation to our testing process, we are able to spend more time on planning, detect more defects faster, and better meet the project demands.
For Joe Wilson from Volare Systems, the end goal of automated testing is to have a decoupled software design and confidence in the quality of the software product being built. Automated testing doesn’t mean there is no manual testing. It means the important things the application used to do still work as they did before. However, there were two main challenges that they faced.
In the next section, I am sharing the steps and considerations you can follow to create the test automation strategy document.
Test Automation Strategy Document: Steps to Follow
Software glitches cause huge disasters. Error could occur is possible while programming, but it shouldn’t be when you’re testing. To avoid these errors, we have test automation. However, to implement this, you will need a thoroughly prepared test automation strategy document.
Let’s discuss the building blocks of this automation test strategy example document.
#1. Test Automation Scope
Before getting started, it’s good to have a clear picture in mind. For each module of the project, there should be timelines and milestones defined from an automation perspective. For any particular project, define a scope of it. It should keep everyone on the same page (project stakeholders, consultants, project managers, tech leads, developers, testers, etc.)
#2. Test automation Approach
This is a broader term to define; hence, it can be broken into three parts: process, roles, and technology. This includes what tests to automate and the decision of when the test cases should be developed during the sprints.
During this part, you should define the roles for designing and reviewing the test cases. A well-followed approach leads you to a successful test automation.
#3. Risk analysis
As the name suggests, what are the risks involved in running the automated test case? If yes, at what percentage it may happen and how to optimize it? This will keep you one step ahead of the unexpected disasters. You should consider conducting it before starting the test automation.
#4. Test automation environment
Make a concrete pipeline to go through before the software is ready for production. This is how the test automation environment is defined. You need to have a clear understanding of where the data will be stored and whether it can be reused or not.
There has to be a stable and predictable test environment. For instance, for a particular project to go under the test automation, you need to plan the test cycles, prepare the test cases, and predict the testing time required.
Test automation infrastructure should make it easy for anyone to create, maintain, run and consume your tests and test results – Carlos Kidman, Founder of QA at the Point
#5. Execution plan
The execution plan is the backbone of “bug-free” testing. Run individual test cases before the regression test suite and ensure they are working great. Avoid false outcomes and test fails. It consumes a lot of additional time.
The execution plan should include day to day tasks and procedures. You can use a tool like Bamboo or Jenkins for scheduling the execution. Ask your QA Analyst to set up a test case in a fashion that brings faster feedback to the development team.
#6. Review & analysis
Filter the test cases that have consumed more time and analyze them for optimization. Review the entire test automation strategy and take feedback from everyone involved i.e., peers, DevOps engineers.
Ask DevOps engineers to plan out the things that hinder the automation environment. Ensure the QA team to acknowledge the bugs in test scripts and they are resolved. Remember to document everything i.e., analysis, results, and suggestions.
Successful implementation of test automation is an art — the one which requires you to iterate on the go. However, the universal key is to start small and invest over a long period of time.
What if your first experiment fails? A lot of organizations get started with automating tests only to realize that their tests are unreliable or impossible to maintain. In such cases, I’ve observed companies continue to lose money, having fallen for sunk cost fallacy.
If you’re one of them, what should you do? Scrap ineffective tests. Reframe your test automation strategy. Select the new tool. Or hire a software testing service provider like Simform who can help you analyze your current approach and suggest you the best options to take forward. Nevertheless, I’d love to hear your feedback. Connect with me on twitter @HirenDhaduk_ or drop me a line firstname.lastname@example.org