Test Automation- the need for speed

By freeing automation from the burden of a script based on code, we can begin to imagine a solution that could be used by subject matter experts and not limited to frustrated developers, a solution that could adapt to changes in the application under test. www.altimetergroup.netThe way we work has changed. In the last decade, the rate of business change has risen beyond anything we could have expected. The availability of new technology and the strategic advantage that it can potentially provide businesses has fuelled this, along with the need to adapt quickly to changing market requirements.

As the fortunes of markets change and move with a frighteningly sudden pace, every business finds itself needing to achieve more, with static or reduced budgets and resources.

Agile and hybrid development are now well established although many waterfall projects still happily co-exist. What is common to all is that today’s fast-paced business environment demands an organization’s development process to be flexible and adaptable to changing needs.

Any agile model provides frequent delivery, increased customer involvement and helps to deal with the problem of rising complexity in systems.
QA teams now have to accept that requirements can often change during and after each iteration, depending on the feedback from the customer.

These changes in requirements are consequently reflected in the code and the tests that QA teams have to develop, which in turn can lead to a large amount of rework and script maintenance.

With delivery cycles getting shorter, and with security concerns and new regulations to manage, applications are becoming more like living things; beings that grow and mature, morphing from new-born status to an almost unrecognizable fully-grown adult with all the associated trappings and documents that adults tend to collect throughout their lives.

How on earth is outdated and cumbersome test automation technology supposed to cope with this level of change and complexity? It simply can’t.

HP in a refreshing burst of honesty now states that unless you will run a script a minimum of seven times, there will not be any payback from automation. That is one heck of a statement. Any part of an application that needs to be tested at least seven times, suggests an almost static application, not one that is subject of active development efforts.

This sort of automation is fine for regression tests but will not make any impact on current QA bottlenecks. The need is for a solution that is faster, lighter and better able to respond to dynamic application developments.

In short, the modern business with all its need for speed and agility just has no place left for these types of solutions, regardless of how much organizations have already invested in them, and regardless of how much resource is tied up in trying to maintain them. The need for change is now.
 
This blog is an extract from a white paper “Throwaway Test Automation”. You can read the whole paper here.
For a fast and painless route to test automation click here.