The Risks Legacy QA Tools Pose for Modern Software Engineering Teams

To succeed with agile transformation -- and reduce risk -- it is critical to modernize your testing toolset.

What You Don’t Know About Using Legacy QA Tools Can Hurt You

Organizations may believe they are avoiding software quality issues by using familiar quality assurance (QA) and test management tools. In some cases, they feel the safe route is to call upon a single, legacy vendor for both testing and development tools. Yet sticking with legacy tools is not always a risk-free bet, especially as other areas of the software delivery pipeline undergo modernization.

Many trends — namely, the shift to agile development — mandate the need for companies to better equip their software testers. Whether an organization has adopted agile software development methodologies or plans to do so, it’s essential that they concurrently evolve their QA tools. Those who don’t will quickly realize that legacy tools are not equipped to accommodate agile testing practices.

Between 2006 and 2017, the percent of organizations practicing agile development rose from 39 percent to 94 percent. At the same time, the number of active Jenkins installations and Jenkins-related job postings point to significant interest in DevOps.

The uptake in Software as a Service (SaaS) has in large part driven this evolution. As more organizations – even those in the government sector – opt for cloud-first software, developers are evolving their practices to keep pace. Unfortunately, in their rush to adopt the latest development techniques, many organizations are overlooking QA and inadvertently missing opportunities to improve their releases.

An Agile Approach Encompasses Testing

According to VersionOne’s global agile survey, on-time delivery is the top driver for agile adoption. To realize this benefit, organizations must equip their testers to quickly, consistently and repeatedly execute fast, accurate tests. In an interview with Stickyminds, QA consultant Prasad Mk noted that “…trying to enhance speed to market or bringing in the right set of efficiencies is absolutely impossible without the right tools.”

A true agile mindset recognizes the need for tester-specific tools. Yet testing is still too often an afterthought. As they shift to agile, companies focus on maximizing the performance of their developers and business analysts. Their choice of best-of-breed solutions designed to support Agile planning and development reflects this priority. Legacy tools such as HP Quality Center Application Lifecycle Management (ALM) may satisfy the demands of teams harnessing a waterfall approach. However, many agile teams find that HP’s solution falls short due to its clunky user interface and restrictive workflows that prevent quick iterations.

Even as they make an investment in more sophisticated development tools, organizations overlook the specific, unique needs of their testers. A true agile mindset recognizes the need for tester-specific tools.

Consider the soaring demand for both Selenium automation engineers and those with knowledge of JMeter for performance and load testing. Moreover, Jira now counts over 60,000 customers for its test management tools.

Understanding the Risk of Legacy QA Systems in Software Engineering

Lack of granular insight into legacy tool shortcomings may help explain why organizations are not making it a priority to upgrade their testing tools.

Managing defects and requirements between Jira and HP Quality Center requires significant back-and-forth between the two tools.A simple process such as this can occur hundreds or even thousands of times in a sprint.

It can take hours to transfer defects from HP Quality Center into Jira, stalling testing at the end of every agile sprint. Bi-directional data syncs between the two tools can slow down Jira or even cause it to crash. If users are working on items within the two systems simultaneously, these crashes or slowdowns can lead to data loss. It’s even possible for users to unknowingly create and edit Jira issues in a way that violates the organization’s data integrity policies. Within HP Quality Center ALM, someone could edit a requirement in Jira, leading to ripple effects throughout the sprint.

Some legacy tools, including HP Quality Center, also lack support for modern web browsers (i.e., Chrome, Firefox and Safari). When using HP Quality Center, organizations must install a heavy client on every user machine needing to manage and execute test cases. This client is only compatible with Internet Explorer. Plus, with every server update of HP Quality Center, organizations often must update every installed client.

HP has developed a strategy to support DevOps via its new ALM solution, Octane. However, existing HP ALM users must start over in Octane due to the lack of a migration path. Though real-time synchronization between Jira and HP ALM Octane isn’t possible, organizations can schedule synchronizations. However, Octane becomes the system of record for user stories and defects. As a result, testers cannot take full advantage of the rich functionality in Jira designed to support those elements and activities. To complicate matters, HP Quality Center and Octane do not share a reporting architecture. Organizations whose development teams call upon both waterfall and agile methodologies can only gain visibility across all development and testing by manually linking processes.

In other words, some legacy tools may not integrate with the application lifecycle management tools the organization’s developers are using. These legacy tools could create risk by constraining the ability to use the latest test automation tools, or by limiting the testing team’s visibility into development projects.

Take the Pulse of the Testing Team

Organizations relying on outdated testing tools are often burdened by operational inefficiencies. In turn, they might struggle to gain and maintain marketplace traction. To determine whether or not their legacy tools are introducing risk, organizations must find out if their testers are being forced to make compromises. A straightforward approach is to survey the testing team with the following questions:

  • Are our current tools allowing you to perform testing best practices?
  • Does our current toolset support your testing needs without the need for workarounds?
  • Are you able to isolate and identify the integrations, functions, and permission in our toolset that are specifically built for you?

If the answer to one or more of these questions is “no,” the organization should seriously consider empowering the team with a tool designed with the tester in mind.

Continue Reading

We just need a little info from you.

More Great Content