When you finish writing a new ABAP program it starts off as a thing of beauty. It does the one thing it was designed to do (e.g. list sales orders) very well indeed in an elegant fashion and you are incredibly happy with the quality and simplicity of your code.
 

Beauty and the Beast

Then the problems start. One of my favorite sayings is “no battle plan survives contact with the enemy” and in this case as soon as real human beings (the so-called “end users”) start to use your wonderful program in will come the change requests.

“Can we have an extra field here? Just one”.

“How about an extra selection option? Just one”.

“How about adding a calculated field? Just one. Oh and by the way make that other field editable”.

Before you know it your simple program has become a 60,000 line monster which has become business-critical whilst at the same time becoming so complicated nobody can understand it. All the changes were done by different people, in a hurry every time.

You are now in a horrible vicious circle. The more business-critical the program becomes, the more change requests and extra functionality come in, which makes it, even more, business-critical, leading to even more requests and so on forever.

Worse with every change the program becomes more unstable and the risk of causing something that currently works to stop working steadily rises until the probability of breaking something each time hits 100%.

You think things cannot possibly get any worse but yes they can.

Heads You Lose

In mythology, there was a sort of Dragon called a Hydra. If you cut off one of its heads then another seven would grow in its place. Programs get like that. Your latest change has a horrible side effect, you fix that side effect, and seven more side effects pop up, and so on ad infinitum.

Now you are at the stage that when a new change request comes your way, you start screaming and cannot stop. You may have heard the phrase “the worst sort of nightmare is the type that happens when you are awake”.

For example, the guy who sat in the corner of our office was the sole developer for a program such as the one I have just described, and every morning after the changes had gone into production, he would get a queue of business analysts from his desk out the office door and halfway down the corridor - each one with a list of all the problems the business users in the country they looked after had found.

Would you want to come to work that day knowing that would be waiting for you? It’s no fun for the developer, it’s no fun for management, and it’s certainly no fun for the end-users.

So what do people do to fight against this?

Agents of Shield

There are multiple approaches to solving this problem, some more effective than others.

• Once I heard a development manager decree “everyone must stop making mistakes, including the end-users”. That did not work as well as he had hoped.
   
• If a developer runs quality checks such as the ATC against the code that will help. However many people are not allowed to take the time to write quality code as the change has to be done by yesterday.
   
• You can limit the number of times you put changes to business-critical programs in production – say four releases a year. Then before each release, you engage an army of people to do regression tests + test the new stuff. That works OK but with every release, there is more to regression test, it’s a really boring thing to have to do, you have human error, and if they do find something and the developer fixes it, then it will most likely break something else unrelated and all the testing has to start again.
   
• There are frameworks available to run a large number of integrations automatically to see if anything has broken. ECATT is one - available as part of the standard SAP license, and there are commercial products available such as HP Quality Centre (HPQC). The idea would be that before putting any changes at all in production you would run these automated tests to see if anything had broken. The downside is that someone has to create and maintain those automated tests (despite all the adverts this cannot realistically be done by end-users) and they can take quite a while to run. Nonetheless, this approach has proven very successful for many organizations.
   
• What I advocate is a much more radical approach to the problem, changing the whole programming paradigm to something called “Test Driven Development” (TDD) which has had enormous success in organizations that use other programming languages than ABAP.

Not Only, But Also

This is not a replacement for all the approaches named above – e.g. manual testing, automated testing frameworks, ensuring code quality – but rather something complimentary which means there are far fewer errors in the first place. Strangely enough, it cannot stop people from making errors, but it can make them more obvious once they are there.

When I tell some management people that TDD involves automated regression tests using the (free) unit testing framework within the ABAP language they often say “But I have just paid XXXX dollars for HPQC why do I need another automated testing framework?”

To answer that I have come up with a grid to explain the difference between ABAP Unit (as used by TDD) and HPQC (and similar frameworks).

Table Created by MMC Instructor Paul Hardy

BSA stands for “Business Systems Analyst”. The focus of ABAP Unit (which enables TDD) is different from the focus of tools like HPQC. I liken TDD to testing every component of a machine before it is assembled, HPQC is doing thousands of automated tests on the finished product, and then it would be a really good idea to have humans’ do a bit of manual testing as well.

Video lesson: Debugging ABAP for SAP Functional Teams

Wrapping Things Up

The problem I have been discussing is the tendency for programs to get more “brittle” over time and become subject to unexpected errors whenever changed. I then noted some common techniques for trying to find those errors before the changes hit production.

However, the best way to deal with a problem is not to have that problem occur in the first place. My message to the world is that you write your program or make your changes using TDD then the program gets stronger with each change, not weaker. To this end, I created an ABAP course on Michael Management all about TDD which I encourage you to investigate.