Complete the picture – enable Mainframe Testing for DevOps flexibility

In simple terms, mainframe DevOps is a process of ‘joining the dots.’ But until an organization can link all the elements to create a true end-to-end application development process then this will remain an incomplete picture. In our ‘DevOps for the mainframe’ blog series we have already covered off clearing development bottlenecks – but for many mainframe delivery teams, testing requirements remain the biggest barrier to delivery efficiency. In the last of the series, Derek Britton attempts to link continuous integration testing and traditional mainframe QA…

Introduction

DevOps is as much a point of view as a process. It requires a holistic view of delivery and involves QA expertise, insight and activities as a core component of the release cycle – one of the primary reasons for its growing popularity. Testing experts are involved from the outset. Quality is built-in and quickly verified. A laudable strategy, for sure – but how does this translate to the mainframe world?

Mainframe QA

Core systems are complex beasts. Decades of investment in technology require every last moment of testing time for major releases to meet an exacting and comprehensive QA process. Clearly the best fit for testing mainframe systems is the mainframe itself. But how realistic is this? There are issues…

  • Mainframe production workload has expanded to an unprecedented level
  • Most mainframe environments only offer restricted testing LPARs or allocated MIPS
  • Many mainframe applications have elements away from the mainframe and require a test environment beyond the mainframe itself

Consequently a huge amount of testing must be delivered quickly, putting a strain on finite mainframe resources, straining  schedules and resources. As Figure 1 illustrates, the busy mainframe will inevitably creak under the pressure of the testing burden and plans for faster builds and test cycles become distant dreams. In her book, Mobile to Mainframe DevOps for Dummies, Rosalind Radcliffe rightly states “It doesn’t help to … improve the productivity of the development team if there isn’t an environment for them to develop and run their … tests”.

Unfortunately, the regimented, MIPS-restricted mainframe testing environment is largely incompatible with DevOps levels of continuous integration and parallel testing. More often, a compromise is inevitable and in quality-focused environments, that may impact the schedule.

DevOpsTesting

Modernized Mainframe Testing – an example

One Micro Focus client, an insurance provider, relied on their z/OS mainframe environment to support a multi-billion dollar business. However, business growth, an expanding production workload and the demand for additional services was outstripping delivery capacity. Testing was the major culprit but without the overall MIPS capacity to free up more testing time their primary objective of improving time to market for key application sets remained out of reach.

Their specific requirement was fundamentally two-fold:

  • To commission and invoke faster test cycles while supporting ad hoc and faster-moving delivery cycles. Their processes and capacity needed several weeks to get ‘ready to test’.
  • A testing environment to support testing across a range of composite applications involving developers and testers from a variety of teams.

Flex for test

The client needed a fresh perspective on application testing. Micro Focus’ technology supports the more flexible dev/test model the customer needed. Now, an application change automatically triggers an application build with components being auto-built under Micro Focus Enterprise Developer. A test region starts automatically in a virtualized environment and application load-modules from the build process are copied across, ready for testing.

DevOpsTest2

The scenario illustrated by Figure 2 equates to an almost unlimited number of individual testing environments. Spun up on demand, they enable testing for multiple, parallel product releases. ’Continuous testing‘ is now a reality: test regions are provisioned in minutes. Development teams have an environment for testing application changes – including composite applications spanning mainframe and distributed components. Defects or issues are identified and fixed earlier in the process. The average test cycle has been slashed by half.

Of course, the customer still uses the mainframe for the final system test and UAT, but these slots are more readily available due to greater capacity freed up by the virtualised test environment.

Conclusion – DevOps: The Dev is in the Detail

DevOps for mainframes is not a piecemeal commitment. If the accelerated changes cannot be tested, there is little point in resolving application development backlogs in the first place. So the vision for faster mainframe application delivery must be holistic: application testing must achieve faster throughput for a wider variety of application types. This customer story is typical of the profound impact that Micro Focus technology can have.

While DevOps adoption is far from straightforward, successfully implementing its ethos can resolve some important underlying challenges. These blogs have outlined what contemporary technology can achieve for organizations looking to embrace a more DevOps style model. Looking at the concept in general terms , examining parallel development , considering greater efficiency in development, or improving testing cycles, Micro Focus is providing practical technical solutions to today’s delivery challenges. While DevOps provides the outline, Micro Focus joins the dots to complete the picture.

Leave a Reply

Your email address will not be published. Required fields are marked *