Why an automated, 'shift-left' approach to performance testing is crucial to success

The ability to empower their developers to work on COBOL applications with greater speed and confidence is crucial for business success.

This is a contributed article by Stuart Ashby, DevOps Specialist at Compuware.

 

As we continue to hurtle forwards into a digital-first future, it's increasingly important for today's software-driven enterprises to accelerate the delivery of new applications and provide the best possible user experience to their customers. Without this capability, it will be increasingly difficult to keep pace with new digital natives and traditional competitors alike, as speed of innovation becomes ever more important to success. For many large organisations - in fact, around 70 percent of the global Fortune 500 - mainframes continue to power the majority of the core business functions that support their digital service offerings. As a result, the ability to empower their developers to work on COBOL applications with greater speed and confidence is crucial for business success.

 

The performance paradox

Despite the importance of accelerating mainframe innovation, a shortage in COBOL programmers and a tidal wave of demand for new digital services and application functionality mean that developers are increasingly overwhelmed, forced to choose between speed or the quality of their code. However, delivering high quality, high performing applications is key to providing customers with the seamless experiences they now expect; so testing is a crucial part of the delivery process. Unfortunately, it's difficult for many to strike the balance between testing code thoroughly and conducting that work quickly and efficiently; especially as the growing pace of digital transformation means there is more code to test than ever.

Underscoring the extent of this challenge, research has found that development teams spend 51 percent of their time on testing during the release of a new mainframe application to ensure services will work as expected. It's easy to see how this can impact the speed at which mainframe-powered organisations can deliver innovation, and the reality is that this can either make or break their ability to compete in today's market. However, sacrificing quality for speed by reducing the extent of the testing that's conducted can still lead to significant time and resource costs. Code that's progressed quickly without thorough testing will likely need to be reworked at a later stage of development, which ultimately hinders the pace of innovation and increases the cost.

The key issue behind mainframe-powered organisations' difficulty in solving this quality vs. speed of innovation conundrum is that testing processes are often manual, and there is a shortage in the COBOL developers with the skills needed to conduct those tests. This means that time-consuming, repetitive, and yet necessary testing drains resources from already shrinking development teams. Not only does it take longer for code to be promoted through the pipeline, it also means that programmers have less time to spend on value-added tasks like application development, delaying innovation from reaching the organisation.

 

Solving the speed vs. quality dilemma

Enterprises are looking at ways of alleviating the demand that performance testing places on their developers' time, with many now acknowledging automation as the best solution. In fact, 82 percent of organisations say unless they can automate more test cases, they won't be able to meet their business' need for speed, and innovation and customer experiences will suffer. The combination of automating testing processes and "shifting left" - so that software performance is tested earlier in the development lifecycle - can help mainframe teams deliver software faster and ensure only high-quality code is sent into production. By automating repetitive tasks and executing performance tests earlier in the development cycle, developers get ‘fast feedback' on all aspects of their code. That means that performance problems can be identified and fixed before they ever affect the customer experience or lead to delays in the later stages of development.

This is crucial in today's agile IT environment, as it not only frees up developers' time, but also makes it easier for programmers of all experience-levels to balance their development and testing responsibilities. This means that those brought in to bridge the COBOL skills gap do not have to spend their time getting to grips with mundane day-to-day tasks and can focus their efforts on more value-added roles, such as delivering new applications and services to the end user. One of the UK's largest banks has demonstrated the benefits of this approach, having reduced test execution time from two weeks to just five minutes. This has meant that where a typical project used to take anywhere from six to nine months, the bank can now deliver in a third of that time. Automation removed manual effort from the process, so programmers can just focus on writing code and make the best possible use of their skills to drive innovation and create better services for customers.

 

Reaching a higher middle ground

Fending off competitors in today's digital economy requires speed, but to balance this delivering quality experiences, enterprises must embrace automation and ‘shift-left' when it comes to performance testing. This combination will enable development teams with a shrinking pool of COBOL specialists to better manage both their testing and development responsibilities when it comes to mainframe code. In the longer term, this approach will mean enterprises remove the performance testing bottlenecks that slow innovation and achieve their key goal of accelerating the pace at which they can offer new digital services - enabling them to steal a march on their rivals.


Stuart Ashby is a DevOps specialist for Compuware, where he is responsible for evangelising enterprise DevOps and helping customers develop and nurture enterprise DevOps ecosystems. Prior to Compuware, he worked as a DevOps engineer/architect at a UK retail bank. He has extensive enterprise knowledge acquired over the past 30-plus years.

 

Related: