I’ve been troubleshooting software for around 6 years now. My first job out of college was as a Technical Support Specialist for an accounting firm in Gainesville, FL. I was originally pursuing a Materials Engineering degree before moving over to IT so I was spared having to take classes like accounting.
But there I was, supporting two versions of a software package: DOS based and Windows based. Software that had no documentation at all. Well, I figured they’d train me. Nope. I was expected to jump right in and begin handling calls on a software consisting of tenant tracking, accounts receivable/payable, work order, inventory, etc. modules built around 50 or so databases. On top of that, this software sent data directly to HUD. Working with government agencies is something else, and another story (don’t ask me why I linked that…haha…there’s some good reading out there).
Well, I dove in head first and learned everything I could about the software. I had a test environment setup where I could run scenarios that allowed me to study the software (in between being yelled at on the phone), eventually leading me to narrow down what databases to have open so I could see where and when data was written. I eventually created a User’s Guide for a Palm based software used for inspecting properties that I was handed and told to learn.
The first time I was able to solve a new problem on my own I was ecstatic. Whatever, I’m a geek. Self back-patting aside, I realized that I had asked the right questions to lead me to the problem, and then to a solution. Asking the right questions is the key to troubleshooting, whether you are asking a client or asking yourself. Knowing the right questions to ask comes from the knowledge of what you are trying to troubleshoot. If you don’t know how it is supposed to work, how can you determine what wrong?
On my first day at D-Tools, I was handed a stack of User’s Guides and software that I immediately loaded. I read the rest of the manuals that night. After my second read of all the books I wasn’t even really sure what this software was used for, but I had a good handle on what it claimed to do. It was my job to make sure that it did what it claimed to do, and if it didn’t, find out why, and then figure out how to fix it. Or at least troubleshoot it down enough so that those with powers greater than mine can step in and fix the problem as fast as possible.
Here is how I approach troubleshooting issues with SI 5.
- Listen to what issue the client is experiencing.
- Is there an error message, and if there is, what is the exact error message, verbatim.
- Connect out and witness the error. There are many methods for remotely connecting to a computer. Citrix Online has some great options. Witnessing the issue is always preferred because there is a good chance that you will observe key details that the client may not have noticed like the two error messages that pop up before the one they called about. Details matter.
- Did the software ever function properly on the machine? If the answer is yes, the follow up question is “When did it stop working?” followed by “so what changed?”. ‘Nothing’ is the most common answer and 99% of the time, something changed. Whether the domain/workgroup changed, or they changed the name of their computer to something that expresses who they are, or they are logged in under a new user profile, something changed. Sometimes I have to play hypnotist: “Just sit back. Relax. Close your eyes and think of what changed on your machine/network”.
- What operating system are they using? This matters. Long live XP! That’s not entirely fair. I want to give Vista a chance, I really do, it’s not like it is going to go away. Until every software company learns the ins and outs and nuances of integrating with Vista, there will be issues. Anyway, OS info, it’s a good thing.
- Is the issue specific to a certain file, or all of their files? Filtering down. If it’s just one file, well then a major isolation has just taken place.
- Are any other machines experiencing the same issue with the file(s). Filtering down further. If all machines are experiencing the issue, a recent software update may be the culprit.
- Are all machines using the most current version of the software? They should be. Running two different versions of a software that shares data is never advised and causes many issues.
- Attempt to duplicate the issue on my machine. If I can, then, “Zed, we have a bug“. All details gathered are then written up for our development team.
- If I can not resolve the issue, I try to find a workaround until a solution can be determined.