Software Testing

Why Business Objectives from Test Automation are Not Met?

To automate, or not to automate…that is the question.

Take a look at these statistics:
•    Globally companies spend over USD $300 million in debugging their software – (Research from Cambridge University’s Judge Business School)
•    In 2015, stock prices of companies with news-making software failures fell by 4% and by 5.7% for those publically subjected to multiple failures (Study by Parasoft)
•    It costs four to five times as much to fix a software bug after release than when it is caught in the design process – (Source Systems Sciences Institute at IBM)

Organizations have the need to get their software products to market quickly and at a level of quality that guarantees a great customer experience. Clearly, in today’s competitive business environment, organizations have to give paramount importance to software quality. Organizations have to increase their test coverage and accelerate their testing process to produce quality and bug-free products that perform according to the user’s expectations. Since the cost of a bug increases depending on when it is discovered in the Software Development Life Cycle, it becomes all the more essential to catch these bugs as early as possible. The adoption of agile methodologies to push out more releases, in shorter windows and add new functionalities to existing products further increases the pressure on testing.

Obviously, organizations today are getting increasingly conscious of these details and have thus, given testing a boost in priority. While an increasing number of organizations across the globe are jumping on the test automation bandwagon, many of them also complain that their test automation initiatives are not yielding the kind of business benefits they anticipated – testing and development costs are still high, the user experience is still getting compromised, and bugs keep coming back! In this case, should organization ditch automation and go the manual way?

The right objective
First, business leaders have to take a close look to assess what business outcomes do they expect from their testing automation efforts and investment and make the right calls. The main aim of test automation, apart from finding bugs faster, is to accelerate delivery and reduce time-to-market, increase cost efficiencies and ensure that upgrade and iterations to products do not impact the user experience. A small change in the code still demands testing of all the code features. Automation reduces the cost of failure by increasing test coverage so that bugs can be uncovered before any real damage is done. It takes a little time for automation investments to reflect their true ROI, but when they do, the impact extends beyond the cost advantage.

When to automate?
Many organizations adopt automation testing believing that automation is all about repeating pre-scripted tests. A test automation tool is not a magic wand that will make all bugs disappear without any effort. For test automation projects to be successful, organizations need to understand that some tests lend themselves to automation well and some, should just be executed manually for effectiveness. Test automation is not a low-cost replacement for manual testing. To automate the testing process, you need to know what to test and what to automate. For example, UI testing lends itself better to manual testing while Regression Testing should definitely be automated.

Test Automation = software development
In one of our earlier blogs, we had shown how the lines dividing test automation and software development are increasingly blurring. In today’s software development environment, developers and testers have to work together to develop bug-free products. Lisa Crispin, SearchSoftwareQuality expert, says, “automating tests is software development. It must be done with the same care and thought that goes into writing production code.” Both the teams need to work together for automation experts to identify the testing paths, discover bugs and implement fixes as the code is being developed or iterated. Organizations that differentiate between the two and expect one to function in isolation from the other do not get the expected time and cost savings from their automation efforts.

Having a solid test strategy
Test automation is not about adding a few automated tests to the existing testing process. When implementing test automation, organizations have to understand that the testing team needs to rethink the entire testing approach and develop a robust test strategy – it has to align with the business objectives right from the beginning, have defined and quantified objectives for quantified outcomes, employ the right test automation tools and most importantly, lend itself to evolution given the demand for frequent product upgrades and release cycles. Organizations that view test automation as a ‘create it and forget it’ option to optimize testing and let it run on autopilot face greater challenges in meeting their business objectives that they desire from automation.

QA and testing professionals are now more valued than ever before and given the increasing adoption of automation the lines dividing testers and development professionals are beginning to blur. Test automation is a dynamic process and taking the above-mentioned approach will not only improve product quality and stability but also improve resource allocation and manage testing expenses to increase profitability – meeting business objectives is what it is all about after all!

Advertisements

One thought on “Why Business Objectives from Test Automation are Not Met?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s