November 21, 2020

5 Reasons to Shift Left Your Mainframe Testing

Continuous Testing

While the development world has been bustling with discussions of how to increase agility and implement shifting left methodologies, mainframe and server testers were left behind. Until now.

The future of testing is in open source, and so now there finally exists an open source solution for mainframe testing. BlazeMeter has recently contributed the JMeter RTE plugin to the open source community. This plugin enables IBM 3270 and 5250 based applications load and functional testing on Apache JMeter™, the leading open source load testing tool.

But testing in JMeter is just phase one. Running mainframe tests through JMeter, enables mainframe developers and testers to finally introduce agility to their testing habits. Here are 5 reasons why shifting mainframe testing left will benefit developers and testers:

Back to top

What is Mainframe Testing?

Mainframe testing is a type of testing that covers all applications and software services on mainframe systems. Mainframe testing plays an important role in end-to-end test coverage, but only recently became more incorporated into shift-left testing processes.

Legacy infrastructure experts, adept at ensuring mainframe servers kept performing, were tied down to old-school testing tools. These antique tools might have enabled more of the same testing, but they did not release the mainframe testers from their mundane tasks to faster and better product releases. Thus, not only were the testers shackled. So was the mainframe product.

📕 Related Resource: Learn more about How to Test Mainframe LPARs

Shifting your mainframe testing left is critical for the following reasons:

Back to top

Why Shift Mainframe Testing Left?

1. Higher Code Quality, with Fewer Errors

Shifting left means that more automated tests are run, and more frequently. By constantly checking the system for errors, and by running tests every build, you and your team are constantly being alerted of errors, which you can then immediately fix. The result is higher quality code, and much better system performance.

Another positive outcome is less hassle for your team when developing, because you don’t have to keep dwelling on previous version errors. Those have already been fixed or dealt with, so you can focus on future plans and exciting developments.

2. Frequent Releases

JMeter, BlazeMeter, Taurus, and Jenkins are ideal substitutes for legacy tools, for two reasons. The first is that they are very easy to use, so developers and testers no longer have to wait for long periods of time for Performance Center testers to provide them with results. Rather, they can use them themselves. The second is that they can be easily automated, so once scripts are set up, they just run, and developers can get the results and monitor the system and their code.

These two reasons are the building blocks of what shifting left is all about: frequent releases. Instead of: developing, waiting for QA to run tests, arguing with QA about the results, fixing the code, waiting for test results again, realizing you forgot to commit an important part of the fix, sending the code again, waiting for tests, pulling an all-nighter to fix the code for the last time, only to realise that your code clashes with a team member’s code and you can’t release, there is a much quicker option.

By integrating your code tests into the development pipeline, every piece of code is immediately and automatically tested, on its own and encapsulated with other parts of the code. Once the code is approved, a new version is immediately released, to the customer’s/user’s benefit. This also benefits the developers, by giving them a clean slate to continue working on. If the code needs fixing - no problem, an alert is sent to the developer, who can easily identify the problem and fix it. The fixed code is immediately tested and released. Now that’s much easier, and much more motivating for everyone involved.

3. More Team Collaboration

The idea of automated and autonomous mainframe testing might come across as deterring teamwork. But the opposite is true. Even though developers become more self sufficient with their own code, this complete ownership actually encourages teamwork.

Team members will collaborate more on joint feature development, with each developer bringing the code they produced to integrate with others. They will also work together on discovering the system’s shortcomings, to learn how they can fix bugs and bottlenecks.

Finally, developers’ collaboration with Product Management will improve. Immediate mainframe testing and alerts on code will reflect developers work more accurately, letting product and team leaders assign developers with tasks aligned with their strengths or addressing areas they need to improve. More transparency into the development process also enables flagging product deficiencies that should be addressed.

4. Cost Reduction

Shifting mainframe testing left means faster and automated testing, resulting in a higher quality product. All of the components of the sentence above are cost effective for the business. By having machines run more tests in parallel all the time, testers and developers can focus on developing new code, instead of on mundane and exhausting processes. If you’re running tests in the cloud, you’re also saving infrastructure costs.

A higher velocity of releases with quicker fixes and new features grows happy customers, who stay with you instead of moving to your competitors, and who are happy with the value they get from their investment. Customers stay with who they feel is concentrating on the future, instead of lingering in the present.

5. Flexibility and Automation

Automating banal tasks and setting up clear testing pipelines with intuitive tools gives developers and teams more flexibility when planning and executing development. Instead of having whole chunks of work days devoted to waiting for Performance Centers or to running tests, automated testing with easy to use tools clears up schedules and gives more room for other tasks. This makes schedules more flexible. Schedule flexibility is beneficial for developers, who will work better without stress or boredom, and for managers, who can assign developers to other projects that might be delayed.

Agile testing tools are also flexible. For example, BlazeMeter can run 20+ open source testing tools (JMeter, Gatling, Selenium, etc.), so developer teams don’t need to choose just one and train everyone on it. This widens the testing scope, cuts training time and introduces new skills and abilities to the team, which everyone can learn from.

Finally, shift left and automation make the product more flexible. More time for feature development, more time for getting customer feedback and responding to it, quicker fixes and faster releases helpy your product live and breath. This is crucial for competing in the market, for providing the best services, for attracting the highest quality workforce and for maintaining product security.

Learn about using tools to find code vulnerabilities, ensure standards compliance, and reduce time-to-market early in the development process with Perforce's Shift Left 101 >>

Back to top

Mainframe Testing With BlazeMeter

BlazeMeter is 100% aligned and always up to date with shift left testing technologies and methodologies. Just upload your script and run, to get immediate and clear results. Then, integrate into CI/CD pipelines with tools like Jenkins.

Start shifting your mainframe testing left today.

This blog was originally published on September 13, 2018, and has since been updated for accuracy and relevance.

START TESTING NOW 


Related Resources: 

Back to top