Let's Make This Error Happen!

OK, have all of the background information and documentation on the error condition in your hands. Now you need an environment where you can recreate the error condition without causing undue harm to any of your fellow developers, testers or (heaven forbid!) to your production users. Usually at any given time in a production system, there will be programs that are in the process of being modified, new modifications that are being tested and/or successfully tested changes waiting to be deployed. This can pose problems when trying to recreate an error condition from the field. Version control is also a big topic unto itself, so I'll not delve too deeply into it here. Suffice it to say that you will need access to all programs and database objects currently in use at the location where the error occurred, and use this environment when attempting to recreate the condition. Typically, these programs and objects will be bundled into a particular release, which you should be able to load onto a test machine. It is absolutely critical that you work to recreate the error in the exact same environment, (with the probable exception of hardware), that your stricken user is in. If the issue is one of performance, research the hardware in use at the site in question and attempt to recreate the error with similar hardware. Do not attempt to recreate a "slow response" condition using a brand-new PC with a 3.2GHz processor and 4GB of RAM, unless your user has the same or nearly the same setup.

If an error message was received by the user, you should be able to locate the area in your code that displays this message. Look for conditional logic surrounding the error message (i.e., what conditions must exist for this error message to be displayed?). This will also help in determining exactly what steps were followed by the user to reach that block of code. Hopefully, what you discover coincides with the user's account of their steps taken.

Some error conditions, however, are not as obvious as those that result in an error message being displayed. It may be that all appears well until a particular report or screen is accessed, and the data contained therein is misrepresented or inaccurate. This can be the result of "logic loopholes" that allow users to create, modify or delete data in a way that was not intended by the system designers. These loopholes can and should be minimized very early in the software development life cycle by performing negative testing. It's very easy for developers and testers to just test processes for functionality as designed. However, test scripts should also include a healthy amount of steps unrelated to the actual functionality of the process. Many testers would perform negative testing before even attempting to test the intended functionality. If the process passed their "use all available fingers on the keyboard simultaneously" type of negative testing, they would then proceed with the positive testing. This may be time-consuming, but can pay huge dividends later.

Error Condition Recreated...Let's Celebrate!!

Once you are able to consistently reproduce an error condition, you are well on your way to resolving it. Resolutions may be simple and confined to a single program (i.e., a cosmetic change to a GUI), or massive. Your analysis must be thorough enough to determine the scope of any resolution. Remain cognizant of any ripple effects your proposed change might cause. If you intend to change the way certain data is populated or manipulated, do a search of the entire system for this data to determine how your change might impact other system components. (Do not just do a search of the system documentation; instead search all of the physical source code, all database objects and any initialization, configuration, control files, etc.) Such a search should also be performed if it is deemed necessary to modify the database structure (i.e., adding new data elements or constraints, etc.). Failure to do complete analysis before making code changes of this sort leaves you vulnerable to introducing new issues, along with your fabulous fix. Nothing frustrates a user community more than a fix of one problem that introduces one or more new problems. It is one of the quickest ways to break down the trust that needs to exist between customer and support staff. Also, don't fret if it has taken a considerable length of time to pinpoint flawed logic, only to find that it takes just a couple of moments to actually correct the code. Analysis, diagnosis and testing are the hard parts and will typically take much longer than modifying code. Please also remember that if "bad" data has been introduced into the application, that the resolution must not only address the process that allowed the "bad" data to exist, but also include some mechanism for correcting this data. And unfortunately, that mechanism typically will end up being some sort of data manipulation script that is outside of your application. These types of "fix-it" scripts can be very dangerous, so great care must be exercised when creating, testing and deploying such scripts.