The world of software development has undergone significant changes in the past few years, primarily in terms of process. Traditionally siloed teams are starting to become more collaborative in their efforts to reduce time to market for solutions, and ultimately to deliver superior software to end users. Specifically, a rise in DevOps culture—which refers to improved cohesion between development and operations—is driving the shift to agile.
As this shift occurs, the question of where testing fits in, especially automated testing, is a top-of-mind concern for many developers. In order to have a clear answer, software creators must take a step back and really evaluate their current automation framework. This is a multi-step process with its fair share of moving parts, but it's a journey worth taking.
Firstly, it's important to understand that everyone wants to be agile; however, the term is relative. What may seem agile to one company could come across as a wooden process to another. Before a true assessment of automated testing framework can begin, developers must figure out where they fall on the spectrum of agile development, so they can tailor a test management strategy accordingly.
As part of a study titled "How the World Tests" Zephyr recently surveyed thousands of software developers in over 100 different countries, and one of the key questions was just how agile they believed themselves to be. Less than 60 percent of respondents said they were at the half-way mark, and less than 30 percent claimed to be completely there. More importantly, the biggest barrier to achieving agile was listed as "process." Respondents stated that not having the right processes in place—or being unable to implement them—is ultimately what acted as the missing component.
These findings highlight two key points. The first is that developers have a way to go before they can confidently identify processes as agile. Secondly, it highlights the need for a very clear outline of how agile will be achieved across the board. This must include a roadmap for agile testing methodologies, and more specifically, automation integration. If testing is still siloed, and largely occurs at the tail end of development, your automation framework is either not being correctly utilized, or can hardly be called agile.
Fitting Automation Frameworks Into the Equation
Not surprisingly, Zephyr's report identified testing, and specifically automation, as one of the most difficult nuts to crack when it comes to software development processes. The general consensus among the experts is that automation can speed up the process of regression testing while improving the accuracy of test results. More automation is generally better, but integrating it into development is not always easy, and requires a fair degree of expertise, and often, multiple test management tools.
That said, agile testing methodologies are improving automation by making it easier to develop what TechTarget contributor Nari Kannan refers to as "scenarios" rather than "requirements."
"Scenarios are more akin to use cases than requirements," Kannan writes. "Support for automated testing scenarios may be much more useful when using agile software development methodologies rather than support for specified inputs and expected outputs as in traditional automated testing tools." Kannan goes on to explain that many of these flexible test cases can be reused, or easily tweaked, which can save time as software is altered or patched.
For test managers, it's worth taking this concept into consideration when choosing or evaluating an automation framework. Zephyr's research notes that there is a clear market leader in terms of automation tools being leveraged; however, it also notes that the majority of developers are using two to four tools. It's worth determining whether or not these tools play well together, and if they lend themselves to agile testing methodologies.
If the answer to both of these questions is yes, then you're using the right automation framework. If it's no, the time to reconsider may be at hand.