It's Just a Minor Bug

When you’re working in a company with only a few people in IS, developers usually have to test their own code, manage database resources and just about everything else that goes into developing and implementing an application.

There are some advantages to this. When a developer tests their own code they have a pretty good idea where it’s most likely to break. Unit testing in particular is best done by the developer. However once you compile the code the developer becomes less effective at testing. Anything the developer overlooked in unit testing, the developer will most likely miss when testing in “user mode”.

All programs have bugs. I define a bug as any instance in which the application functions in a way that is unexpected. Using this definition, some bugs are better than some features. Finding, tracking and fixing bugs is much more difficult in a non-structured environment. That is one reason it is better to have another person test the application is the structure that situation imposes. At minimum, the tester will communicate the bug to the developer, who fixes the code, recompiles, releases and tells informs the tester, who then retests. That is where a one man show breaks down.

When you’re designing an app, writing another, and fixing bugs on a third, while doing some admin type duties, it’s very easy to skip a step. When the step you skip is compiling, and nobody is there to verify the fix, the bug doesn’t get fixed any where but in the source code. That’s exactly what happened to me. My background is quite varied. I’ve done tech support, training, documentation, QA, development, design and management of those disciplines. So I’m well versed in the development process and the reasoning behind the various steps. All the more reason I should have been able to avoid this mistake.

How did it happen? I was finishing up an application that gets data from a SQL table, performs some calculations, and updates the records with the results. I was also writing an app that converts a AS400 signed integer format from a fixed width text file and inserts it into various SQL tables. Since the both of the apps were needed ASAP, I was in a bit of a time crunch.

The bug itself was simple. There was some confusion as to which field should contain the results of a particular calculation. Once the expert determined the field in which the results should be written, it was a simple, almost negligible, fix. The main problem with testing the fix was lack of test data. Since it was such a simple fix, I assumed it would work. After all, I only changed the SQL column name. If I made a typo it would return a SQL error.

After we started getting live data (or as live as we get), and people started generating reports based on the results the application recorded, I decided to double check the code. Somehow the change wasn’t there. That can’t be possible, I thought. So I checked the dll and no, it hadn’t been changed since before the date that fix would have been implemented.

Why did the code revert? Most likely I didn’t save the changes and didn’t compile. Yes, I would love to blame Visual Studio. However, it’s been years since I’ve seen VS fail to save a file properly. Humans are much more fallible.

Fortunately the effects were extremely minor, since it was discovered when it was. A couple of months down the road and it would have been a big problem. Also since it’s an ASP.NET app, the dll only needed to be updated on one machine. The lesson is simple - document bugs. That’s the best way to insure that fixes are implemented by the time the app is released.

Tags: Quality Assurance, QA, Software Development, Project Management