Back in the day, you could fail in computer games in all sorts of ways. I’m thinking specifically of adventure games like Sierra On-Line’s King’s Quest series from the 1980s. Some of those ways to fail were so amusing that you would actually go out of your way to trigger them – acting entirely on the motto: “I wonder what happens if I do something stupid right here?”
Unfortunately, in software development, we also encounter failure time and again. It happens unintentionally, of course – because, as a rule, it’s anything but funny. Despite our best intentions, runtime errors still occur. And I have yet to see anyone laughing when they do.
Since I’ve recently had a few fresh encounters with unexpected program crashes, I’ve taken some time to reflect on the general causes of software errors. These causes aren’t necessarily limited to programs written in ABAP.
Below, I’ve listed some typical sources of errors that I’ve identified, along with corresponding strategies for avoiding them. Incidentally, “error” here does not merely mean that the program crashed.
| Error because… | Avoidance Strategy |
|---|---|
| error handling was insufficient. | – more frequent code reviews – more tailored unit tests – more manual testing – greater diligence during development |
| was indeed programmed correctly, but was not the right thing (requirements either not implemented or implemented incorrectly). | – improved project organization |
| system resources were exhausted at runtime. | – more resource-intensive testing |
| the algorithm was implemented incorrectly. | – more frequent code reviews – more tailored unit tests – more manual testing – greater diligence during development |
| the input data was unsuitable for the algorithm. | – use of high-quality data – better validation of input data – more tailored unit tests – more manual testing |
| type conversion has triggered subtle data loss. | – more frequent code reviews – use of static code analysis – more tailored unit tests – greater diligence during development |
| components used, which lie outside one’s own development scope, have changed. | – use of static code analysis – more tailored unit tests – more manual testing |
| program states and state transitions were not taken into account in the programming. | – more frequent code reviews – more tailored unit tests – more manual testing – greater diligence during development |