Part Five - Testing And Debugging

Written by Stéphane Richard (Mystikshadows)


And here we are, you coded your big application project, you were prepared for it to, and today you are at your desk, patting yourself on the back on a job well done, you sit yourself back and you are about to sip down a fresh cup of coffee. When suddenly you get an email. Not from your boss, from users, people that paid the big bucks for your applicaiton, clients in other words. It seems you either forgot something crucial to the working of FinanceCAD, or they get an error when they try to run it, or install it. And you thought you were done with this project didn't you? You start to stress like never before, you get dizzy and you almost choke on that sip of coffee you were taking when you got the email. Then, you wake up, in your home, and you say to yourself, thank God I was prepared. But the big wheel doesn't stop at the end of the coding phase, far from it. Welcome to the official testing and debugging phase.

Don't worry, bugs as they are called, have been around for a while, no self respecting software had, at one point, a testing and debugging phase. So your project isn't the first, and it certainly won't be the last. In this series we will look at this phase in all it's glory, some say the testing and debugging phase is the most important phase of the development cycle and I tend to agree with that. The main reason is because it directly affects the overall quality of the resulting application and once again, if you've prepared for it (like all other phases of the development cycle) in advance, you can go through the testing and debugging phase in an organized fashion. This is what this part of the series is dedicated to. We'll see what you need to do in order to make this phase as smooth as it can be. So let's get right to it.


A bug is a problem, at any level of the application. Typically a bug is noticed first if it stops the normal execution of the application. But there are more than that too. There are different levels of bugs and of course, fixing the bigger bugs is typically the way to go, then you work your way down the list of bug priorities from start to finish. Let's review these categories of bugs, in order of priority, so we can see how bugs can be categorized:

I can't stress this enough, but these categories of bugs have to be established before any "efficient" testing and debugging can occur. Users tend to consider any bug as critical, and this is why I am listing them here because there really is a difference between these bugs and their importance. When you receive a bug, the first thing to do is take the time to categorize it properly, just doing that will help greatly with the testing and debugging phase.

Now, when is the best time to start preparing for the testing and debugging phase? As soon as the coding phase begins. Let me explain. There are certain things that can help you waste as little time as possible before you officially enter the testing and debugging. Remember that you have the visual aspect of your application and the non visual aspect and both will need to be tested thouroughly. Let's take the forms to begin with. When you create a form, you should establish, right then and there, how the form should work. By that I mean you should know, from the design part of the coding project, what fields must be entered, what calculations should be performed what happens after the calculation is executed, and the order in which the fields or controls should be accessed in. Once the form is coded, the first test to do is to make sure that the form can perform it's designated task in a normal usage situation (taken from the user requirements and the design part of the coding phase) for all used input devices (when using the keyboard only, or the mouse depending on what you are testing). For added testing, this preliminary testing could be done by another programmer which didn't create the form or the code being tested. Remember that it's good to have a good way for the user to report their bugs, there are many applications out there that allow you to manage the bugs that are discovered as testing begins. For example: There is BugZero™ which is an online web based bug reporting and management tool and BugCollector Pro which also offers a great tool to collect, prioritize and organize the bugs. These tools are made to do just that and the do their job well.

If, in normal situations, you can go through the fields, enter the data, in the right order, and perform the task the form was coded for, you have just created a preliminary test of the form. The preliminary test can help weed out, at the coding phase, almost half of the testing and debugging phase so it's crucial, when planning the project coding phase, to attempt to give enough time to perform this preliminary testing on everything that is coded. Again I can't stress this enough that preparation, at the right time, will greatly affect the testing and debugging phase in a good way. This is true for forms as I've explained, for reports (to test the validity of the results returned by the report, for databases inserts, updates, deletion and querying too for obvious reasons. There are software that allow you to automate a series of tests to be applied to an application or parts of an application. One of the most popular testing software available is called TestDirector™. If you take the time to visit and read about Test Director you'll soon see everything it allows you to do in a testing and debugging phase and you'll quickly see just how good it is at what it does. When a bug is first reported, it's important to know some minimal information about the bug and the situation that caused the bug. In the next section we'll look at exactly what you need to know about a bug.


If a users reports a bug just by saying "the program doesn't work" it doesn't really tell you much about the type of problem that occured and where it happened. It also doesn't give you many clues as to what a possible correction to the bug could be. Just like the other phases of the development cycle, documentation is the key to a successful testing and debugging phase. If enough information is supplied about a reported bug, the time to locate the bug and ultimately fix it finds itself greatly reduced thus shortening the testing and debugging phase. So let's review what type of information that can be provided about a bug that can help you in the testing and debugging phase.

Of course, if you are managing more than one application, you can add "which application" as the needed information, but that goes without saying. Error reporting is also done from the application in the Error Management part of the code. There you can help yourself even more by adding code specific information to the error report. Code level information would be, for example, which routine was being executed, in which module is the routine found and other such relevant information. This will definitaly help locating the bug at a much faster rate as well as correcting the problem too. Another important point to make is that if there is more than one programmer involved in the testing and debugging phase, these programmers should have some mean of reporting the bug they are working on.

So you have your bug categories, you have all the information you need about a given bug. What should you be doing? This is what the next section will talk about. There is a certain method in the testing and debugging phase, a certain order of things so to speak and because I've seen this order tempered with at different levels in my career, I will explain them here, in the order they should be in for a better and quicker testing and debugging phase.


As I mentionned, having the information you need to look at a bug is only half the solution. As much as it's important to know of the existence of a bug, it is also important to know what to do with the bug in order to have it corrected hopefully as soon as possible. This is where a systematic method of dealing with a bug becomes important. Of course some types of bug can easily, obviously and quickly be fixed. For example, a cosmetic bug is usually fixed by moving a control to it's proper place, changing the label with the rightful name of the field, or changing the tab order of the controls so that the expected order is achieved when the user presses the tab key to go from one control to the other. Those are quickly located and fixed. However, for the other types of bug, having a method in place can give the programmers a sense of control over the bug and help the whole testing and debugging phase go smoothly. Here is that method, that order of steps to follow when dealing with a bug. Hopefully this will help you deal with the debugging phase in a much more organized and controled environment making it easier to manage.

And there you have it. As I mentionned, it seems that because of time issues, these steps aren't always respected and often it's the cause of a never ending testing and debugging phase that just seems to get longer and longer. So before you decide you should follow these steps or you think you don't need to, take the time to think about it a while. Good testing and debugging practice will help the phase reach its end and in the world of software development, the end of the debugging phase should be of the highest priority throughout the development cycle.

Even if the size of the project is much much smaller than a big scale application, testing and debugging should not be neglected or overlooked at all. In fact, in many cases, not paying attention to this phase is often the cause of delayed releases, deadline that can't be met, and other serious issues of the sort. So for these reasons, testing and debugging must be treated as a very important aspect of the development cycle.


And this pretty much concludes the whole testing and debugging phase. Needless to say there's alot of material in this phase too. Some of you might have discovered many things about the testing and debugging phase that you never knew existed. If this is the case, then I'm glad because it means that this series of documents is doing it's job. This is the reason why I created this whole series of documents, to really teach you what you need to know about each phase of the development cycle and what exists to help you along the way at each and every step of the way. I also hope that I've made clear, in each part of the series so far, that preparation is as always the keep to the success of each of those phases. Some of you may wonder if there is really a need to do absolutely everything that I am mentionning in this series. Well to that I can tell you that it won't hurt to do them all, it will make the whole project documented a lot better. Maybe, after a few projects you'll think you're familiar enough with the process to start creating shortcuts to these steps. Well, what I can tell you about this is that I wouldn't if I were you. Just like any process you do in a job. If you have all the documentation you should have, then there is no guess work involved and in a development project, the less guess work you have, the better it is for the life, and the success, of the development project.

There is one more part to this series, Installation and Integration. That part will talk about the last steps of the development phase, making sure your application installs itself and executes as it is supposed to. there's different considerations for a commercial and a professional application and we'll be covering each of them in detail in the next and final part of this series. Until then, email me with questions, concerns, suggestions and ideas about this series of documents if you want to know more about a certain part I've covered in this series, let me know as well and I'll see how I can better the contents of this series. Until next time, happy reading and I'll see you then.

Stéphane Richard