Maria Homann
Shift left testing is a frequently discussed topic in mainframe application testing. Its popularity has only grown along with the need to modernize the approach to testing mainframes.
The need to modernize mainframe testing has emerged as a result of a series of changes in the mainframe testing field.
First, the businesses using mainframes have seen a decrease in the number of personnel with mainframe expertise, since the technology is approximately 30 years old and few people continue to build their skills in this field.
Second, the pace at which businesses must deliver quality at speed has increased dramatically in recent years. As a result, many businesses have adopted DevOps and agile methodologies, which don’t blend well with traditional mainframe testing.
These changes are pushing mainframe developers towards new approaches - including shift left testing.
Related reading: What is Mainframe Automation?
What is shift left testing?
Shift left testing is an approach where testing is performed earlier in the life cycle (or moved to the left on the project timeline). The purpose is to catch bugs earlier, when they are cheaper to fix.
In that sense, shift left testing bears much resemblance to agile and continuous testing, which share the purpose of catching bugs early on and reducing the overall costs and time spent on bug fixing. It’s important to note that shifting left doesn’t mean that there is no testing ‘to the right’. Shifting left simply means that more tests are performed earlier.
What also makes shift left testing different is the notion that not only testers should do the testing. Rather, testing efforts are spread out, and essentially anyone can contribute to testing efforts.
One of the challenges in achieving shift left testing in mainframe development is the limited availability of testers and developers who know the mainframe application well enough to operate it.
To help solve this challenge and enable more and earlier testing, shifting left requires test automation.
3 reasons for test automation in shift left testing
Test automation is an essential part of shift left testing, as it significantly increases the speed and accuracy of testing, which in turn allows for more testing to be performed. At the same time, it can help free up tester and developer resources - for mainframe, this is particularly crucial due to the limited number of experienced mainframe programmers.
It can only help, however, if the mainframe developers don’t have to spend all their time on setting up automation scripts.
Related reading: Everything You Need to Know About Green Screen Automation
Test automation should be simple enough to work with so that a person with lots of mainframe programming knowledge, who knows the mainframe application inside out, can design tests without necessarily also being an automation expert.
No-code test automation is therefore an essential ingredient in enabling shift left testing for mainframes.
There are three reasons in particular why mainframe testing can benefit from a shift left approach involving no-code test automation.
1. Higher speed
Automation significantly speeds up testing for a number of reasons. First, there’s the test execution time of repetitive tasks. If performed manually, it goes without saying that repetitive tasks take up a lot of time to perform - and the more repetition, the more time goes down the drain.
Automated tests do take some time to set up, but once in place can free testers from tedious, manual work. If the test automation tool is codeless, however, this initial setup time can be reduced, which in turn increases agility and reduces the overall time spent on testing. And if it’s codeless, anyone is capable of setting up tests, eliminating dependencies on code writing capabilities. By removing dependencies, bottlenecks disappear and teams can flow through release cycles faster.
Finally, as test automation robots run 24/7 and don’t get sick or take vacation, tests can be run at essentially any time and frequency, which is a crucial capability in shift left testing. In addition, you can put more test automation robots to work simultaneously and do parallel testing to retrieve broader test results quicker.
2. Higher quality
By increasing the frequency of tests, it becomes possible to test more. And by testing more, QA can feel more confident that the product is bug-free before it reaches production.
With a no-code test automation tool, testers can quickly set up tests, run them, and maintain them with ease.
Meanwhile, developers can spend their time on actual mainframe development, and testers can spend their time on exploratory testing, test design, and overall improvement of testing efforts.
As a result, quality is improved across the board.
3. Reduced costs
Testing faster is in itself a cost-saver. But by doing it as a part of shift left testing, where tests are performed earlier, even more can be saved.
The reason for this is that bugs become increasingly costly the later in the release pipeline they are found. By automating tests (with a no-code automation tool), developers can have their code tested immediately, meaning defects can be found early, and situations where developers are building on top of broken code can be avoided.
Tests can also run overnight, and bugs can be located and fixed right away, before they become costly to resolve. As a result, updates can be released more frequently with higher speed and higher quality.
Again, by using a no-code tool that lets testers do the testing and developers do the developing, everyone’s time is better spent, in a way that helps the business save costs.
The end result from using shift left and automation for mainframe testing is the ability to move away from outdated processes that account for slow and rigid development, towards a positive trend of more efficient testing, more time for development and QA, faster releases, higher quality, and lower risk.
Download our guide to green screen testing to learn how to overcome common challenges in mainframe testing to achieve efficient, low-risk, and low-cost operations.
