This blog was originally published by Ashish Shah on Linkedin.
Statistics suggest that there has been an 85% increase in test automation over the last two years. Test automation is being talked about like the silver bullet that solves quality issues and helps roll out high-quality software products faster. As the focus on test automation increases, you have to evaluate whether to approach test automation initiatives like a project or a strategy? Here are my 2-cents!
Test automation initiatives have inevitable, and often high, upfront costs. You need a team of experts, automation engineers, the right set of tools, etc. Key is to recognize that test automation initiatives are also software development projects with all the associated baggage. So all the best practices that go into the development of quality software such as code reviews, frameworks, and design patterns, maintenance, etc. all have to be followed with test automation too. Given the investment of time, effort, and money, it is hardly surprising that you want to guarantee success. In my opinion, succeeding at test automation will be very hard, if not impossible if we treat test automation as just another project. Test automation brings immense value to the table to think about the information value that automation brings. With test automation, you not only catch bugs but gain profound insights into how you can make product features stronger by coupling or decoupling them. Given the time investment to develop robust test automation suites it makes sense to look at automation initiatives from a more strategic point of view rather than as a project.
Software test automation has emerged as the great enabler for development methodologies such as DevOps that demand that the speed of testing matches the development velocity. Owing to this, every stage of the development lifecycle includes testing and is more integrated into the development process. With these new development methodologies becoming mainstream, testing teams can no longer work in isolation. Instead, they have to assume the role of active participants in the development process itself. As collaborators in the development process, testing teams have to understand the expected functionalities and requirements of the product, the architecture, and the software design. They must gain complete product knowledge to come up with a testing plan that takes into consideration all possible scenarios to find software defects. Moreover, then identifying candidates for automation and manually tested.
In the DevOps age, which runs on fast feedback and continuous development and deployment, the testing and development teams have to run in tandem to fix all issues and bugs on the go. This parallel activity means that every step of the development process, test automation teams have to integrate into every step to create better and more comprehensive tests to cover all aspects of the product in development. Since over 50% of defects originate in the requirement phase versus barely 7% during the development phase, the focus on quality and testing has to start right from the inception of the development process. Moreover, to test every functionality and performance aspect and to ensure comprehensive test coverage you have to treat test automation as a strategic initiative.
Test automation also has to be aligned to the business goals that the software under production is expected to achieve. Unless we do so, how can we create tests that ensure maximum code coverage and test the limits of the application? Test automation teams thus have to take into consideration the functional and non-functional requirements of the software. They must implement a smart test design to test boundary considerations. They must also verify the codes that perform those considerations. In test automation the devil lies in the details and automation experts have to look at these little details, explore how to get to these details and then create tests that help in developing robust software. Software products are not indifferent to the change that surrounds us. This change means that test automation suites have to work hard to stay relevant. Treating your test automation initiatives like a project might ensure that the effort is successful for that particular project. However, what happens as the product evolves? Does your automation suite have the capability to grow with the product? Can it accommodate the new testing demands of version 2.0? Alternatively, do you need to sit and draw up a new testing suite as your product evolves? Treat test automation as a strategic initiative to avoid shocks when the inevitable product evolution occurs and ensure that your testing suite can be an enabler of change. Test automation teams thus should look at the test suite they plan to develop and to identify reusability and redundancy within these plans. Monolithic test plans with too many interconnected parts impede the test automation speed. Instead, there has to be a focus on creating smaller and independent test cases to increase the efficiency of the testing suite. You also need to treat testing assets as any other piece of software that demands maintenance. Identifying the maintenance needs of the testing assets, the creation of test data to assess which tests are repeatable, creating test automation suites that are resistant to changes in the UI, etc. are a few things that should be considered to prolong the longevity of the test automation suite.
Test automation is not about automating manual tests. It is about identifying the right candidates for automation, figuring out how to optimally use testing assets, and ensuring that the automation suite remains relevant for longer to get to the happily ever after and that can only be achieved if you think of test automation as a strategy -not a standalone project!
