• White Papers |
• Blogs |
• Video |
• Webcasts |
• Podcasts |
• Events |
• Solution Centers |
• Newsletters |
• RSS Feeds

IT Troubleshooting: Quickly Identifying and Solving Software Bugs

By Dennis Jones

May 14, 2008 — CIO — Nearly every IT project manager, designer, DBA and developer wants to build the perfect software application: the seamless union of hardware and software, intuitive and robust, with eye-popping performance and rock-solid logic. While this pinnacle is difficult to reach&emdash;and flaws will be found—there are steps you can take to resolve them more quickly.

Countless hours can be spent gathering requirements, creating meticulous database and program design, and utilizing the very latest development tools and techniques. We can employ a seemingly endless array of unit, system, integration and regression test scripts, along with the finest implementation and training plans and procedures. Yet all of this massive effort and intent is simply no match for the one entity that reigns supreme when it comes to finding and exposing the most well hidden bug: the end user. Our customer. We might as well face the fact that no matter how many hours are spent bulletproofing code, end users are going to find problems. The tips below will provide the developer or technical support person with methods to quickly identify, verify, isolate and ultimately resolve such technical challenges. (Also read Seven Free Tools for PC Geeks--and One Quick Tip.)

Oh *#@$&!, We've Got a Production Problem!!

The words we hate (but are destined) to hear at some point. What to do? First things first, there must be a procedure in place to allow the user to properly describe and document the problem. Every production application should have a central help or support desk to be contacted when user issues arise. The help desk personnel are critical components to a thorough and complete resolution. As such, they should be functional experts on the system being supported, so they can interact intelligently with the users. They must obtain information and documentation on the entire issue, not just the error condition or message that the user ultimately received. What were all the steps taken? A screen print of any error messages should be obtained. These can prove invaluable when a developer is trying to piece together exactly what portions of code have been executed, and in what order. Users can sometimes leave out details that might be second nature to them, and a screen print may point out these details to the support person.

To learn more about process improvement and workflow, see ABC: An Introduction to Business Process Management and Workflow Gone Wrong.

Lucky You, This Is Now Your Issue to Resolve!

Hopefully it's not a Friday afternoon where you have a lot of documentation to go through. Do that, and request confirmation of any ambiguities. You need to know exactly what steps were taken and the exact verbiage of any error message(s). Here's where all of the time spent coding and testing that pesky error handling logic in your application can pay off. Thorough error handling logic is sometimes overlooked as a necessary part of an application. However, it is extremely important because more often than not, when an error condition does occur, it will be at a critical juncture and will need to be diagnosed and corrected quickly. In your application, you should be able to anticipate most error conditions, and thus handle them gracefully. Do so with a nice message to the user gently telling them how they, (and not your robust application), have somehow made an error. Do not be naive enough however, to think that errors you code for or handle will be the only ones that occur. You must also have "catch all" error logic to handle unexpected errors. Example: You can easily code error logic to inform your user that no records could be found based on some search criteria they entered. But what will happen, say, if the database goes down just as the user hits the "search button? Or, what if there is a power outage while your program is in the middle of saving records? How about when the user presses Ctrl-Shift-F8 while creating a new record, inserting a disc, and playing Solitaire in another window? You can bet on the fact that nearly every conceivable keystroke and concurrent program combination will eventually be attempted by your users. Your error-handling and commit logic must work together to not only capture information relative to error conditions encountered, but also preserve the integrity of your data in such events. (Also check out the podcast 20 Top Tips for Software Testing

It is an excellent idea to have a common error-handling routine that writes to an error log. Your "catch all" error logic can call this routine whenever unexpected errors occur. In this error log you can record the exact date and time, the name of the offending program and/or any subprograms, any pertinent record names or ID's, and any error codes and text generated by either your application programs or by the database. Bottom line: Provide the user with an error message that means something to them (i.e., "An error has occurred while processing this record. Please contact the help desk immediately."), and provide the support person (via the error log) with information that means something to them. All of this information is necessary because your initial goal is to recreate the error condition in your development or test environment. In general, error conditions must be recreatable in order to be correctable. Many times, error conditions that cannot be recreated are a result of a user who has forgotten some of the steps that were taken, or other circumstances that were present. These are the dreaded one-time problems that mysteriously go away by themselves. Guess what? Just as mysteriously, they tend to reappear by themselves at a later date, often with the same user. If you can speak directly to the person who received the error, do so. Go over all steps that led to the error. If possible, visit the location to examine the software, hardware and data. If a site visit is not feasible, an export of the user's data can be very beneficial to resolving errors. Ask some additional questions. What other processes were running when the error condition was encountered? Any other unusual circumstances present? Were multiple error messages received? It is sometimes difficult to get the entire story, especially if the user feels that they have somehow made a mistake in the process. By being sensitive to this, and communicating your sincere desire to help, you can usually get all the details of the event.

 

 

 

Email

Print

Comments

Digg This

SlashDot