Automation is an area of high demand today in the world of software quality. Automation of applications under test, unattended automation runs, integrating the test suite into the continuous delivery pipeline are all common in today’s scenario. Not much is asked about return of investments from an automation run, as it is a given today compared to a few years back when this was a commonly asked question. Today, automating as much as possible and ideally all of the coverage is what most quality teams strive for given the limitations in time and resources to test. Also, a continuous delivery cycle demands continuous integration and testing for which automation is inevitable.
That said, a test automation solution extends itself much beyond the core of verifying an application’s quality, robustness and performance. It is often used for a lot of support functions including testing the test automation code, migration scenarios (database, test case and defect management tools, reports), test data generation etc. In such cases, since the main goals are able to handle volume and get the job done fast, along with repetitive nature of the work that may become mundane to be done manually, the question of ROI comes to the fore-front. Also, in most of these cases, the re-usability for the automated suite may not be very high, especially in scenarios such as migration.
Thus, it makes sense to build a simple automated utility to support the action rather than anything very elaborate. We were on a call with a prospect recently on this exact topic to support them migrate their test cases from one commercial test case management tool to another when this topic came up, which got me thinking about the differences in automation goals when it is taken up for product quality v/s a support function. Software test automation is a very customizable piece and its relevance largely depends on the defined automation strategy – it is essentially like clay with which one can make a beautiful piece of art or a piece of trash. One needs to understand the true application of the automation suite, the need for it, and all constraints within which it needs to be built to determine what kind of a solution is needed.
At a very high level the kind of test automation solution to build for support functions is very different from the core application under test, and hope teams are cognizant of this at the very start.