The Agile Tribe

Teaching an old dog new tricks – Trick No. 3

Author: Nic Woollett

As part of our ongoing Agile journey in the mainframe/legacy environment, Acceptance testing is next in our list of our three ‘tricks’.

Acceptance testing was another big change to the way we normally operate in a mainframe/legacy environment. Acceptance testing was fully automated by using scripts: scripts run for each day to perform online maintenance, create files for the batch and then to validate the data post update. We actually developed a new scripting tool that enabled the testers to create test scenarios in a easy to use interface. The scripting tool then build executable scripts from the tester generated test scenarios.

When using scripts we required a testing region that could be restored back to a base point for each acceptance test run. When a test is built it will be run in every acceptance cycle thereafter – ensuring constant regression testing. Again, this offers a level of robustness above the standard testing approach where after a test is performed & accepted it is ticked off & (more often that not) forgotten.


Despite some initial scepticism that Agile could not work on a purely mainframe project – what with moving targets, short iterations and aggressive delivery times – we agreed from the start that we would stick as closely as possible to pure Agile. Whilst we are not LIVE yet I don’t think we would be as far along as we are now under waterfall and I believe the product we install will be much more robust under Agile.

What I learnt:

Formal system and user testing have both proven to be ideal subjects for automation.

1 Comment »

Teaching an old dog new tricks – Trick No. 2

Author: Nic Woollett

This blog is the second part of what we have learnt as mainframe/legacy developers while adhering as closely as possible to pure Agile principles. In order to do this we have tried to make a series of fundamental changes to how we operate.

So the second trick we have used on our Agile journey relates to Build and Unit Testing.

This was where the biggest shift came in our mindset as mainframe legal programmers. With iterative development you have to have repeatable testing – otherwise you’ll be stuck in an endless cycle of regression testing. Also, locating or manipulating test data can be a labour intensive process and in any case. Very rarely is all logic in the program tested.

A program could be changed in multiple stories and within each story only the changed portion of the program should require to be tested – regression testing should be automated. So, for our project we needed to:

  • Take away the need to locate/configure test data for each code change
  • Automate regression testing
  • Be able to target specific code to test
  • Make every test easily repeatable.

We did this by building a unit test framework – the first and probably only one in existence for Hogan. The framework consists of various tools and utilities that we developed for the Agile process. Broadly, each program requires a test program to drive the unit testing of this program. When run in the test framework the program can be tested in isolation and it requires no specific environment data – such as files or databases. The program can be tested over and over without the need for any user intervention.

The test framework (named the HUTF – Hogan Unit Test Framework) is now at the tried and trusted level and whilst initially it adds to the development time, when a developer is conversant with the tools they should be able to code and unit test much more efficiently. We also automated unit testing – a daily run was set-up to test all the test cases – a list that grows with each story. A report is generated and should any test fail an email is sent to the development team highlighting the failure(s).

What I learnt:

Developers spend too much time doing user acceptance testing under the name of unit testing. Using a test framework greatly cuts unit testing time allowing developers to do more developing.

Leave a comment »

Teaching an old dog new tricks – Trick No. 1

Author: Nic Woollett

I’m currently working on an in-sourcing project that involves only mainframe legacy systems. We’re attempting to stick as closely as possible to pure Agile principles. To get the most out of Agile we had to make a series of fundamental changes to how we (mainframe legacy programmers) operate.

Our approach took three parts:

The first of these was – Story elaboration

This was interesting – not using the waterfall method of waiting for fully described business requirements was initially a challenge. Developers were required to be fully involved in the elaboration process & this lead to a greater understanding of our business needs. It was a fundamental shift from “tell me what you want and I’ll build it” mentality.

It was quickly realised that we weren’t going to get the full story fleshed out in one elaboration session so the mentality of “build and show” was encouraged. This is iterative development within iterative development! It’s much better to be able to show the team something than theorise. After a few tweaks here and there the story is completed to everyone’s satisfaction – that renders the old waterfall post-implementation complaint of “that’s what I asked for but not what I wanted!” moot. After a while a common understanding takes over and (as a developer) you start to know what the business will want.

What I learnt:

I don’t always know what’s best for the customer and the customer doesn’t always know what they want. The best result comes from a show and tell style collaboration and co-location is a must.

1 Comment »