I was looking around for a "classic case" of a typical assignment the test team gets to discuss when I got an email similar to the following:

"OneNote is using hard coded path names in some of its automation batch files. Specifically, these 4 files [the email included a list] will need to be updated. You can follow the directions here [a link to an internal website with documentation].

This is critical to the build process. If these changes are not made, the OneNote test project will fail to build and may be disabled."

The email was marked as high priority and definitely sounded urgent.  How serendipitous - this is a good example of the type of tools\automation work we get on the test team.

Let me start by saying I'm against hard coding paths as much as the next tester. Hard coded path names generally are too fragile for extended use and our automation system includes a strong set of environmental path names we should use instead. This way if we have a batch file including commands like this:

@rem -- delete the old onenote.exe

del \\c:\program files\Microsoft\Office\12.0\onenote.exe

we can expect it to fail if the test prior to this run had installed OneNote to a custom location. And it will only work for OneNote version 12 (aka OneNote 2007. OneNote 2003 was tagged "11.0" internally. This line is hard coded twice over - it assumes a default install location for only one certain version of OneNote).

We should have a batch file command like this instead:

@rem -- delete the old onenote.exe

del %ONInstallLocation%\onenote.exe

Assuming, of course, that ONInstallLocation is defined as the location in which OneNote was installed. This way, we can be assured our file will always be able to find the file it is looking for. And if the environment variable is adjusted for the correct version of Office installed, we can not have to update this batch file for each new generation of OneNote. This is a good engineering practice, and I heartily support it.

Now back to the email. I was a little worried about the tone of the email. I could easily imagine a new change I had not heard about making this change mandatory immediately. It looked like a simple task to complete and my estimate was less than a day to make the changes and test them. When I got the email, though, everyone on our team was swamped with work and I wasn't sure when we could get to this task. I was hoping the next week would be OK since I did not want to derail anyone for even one day of this work.

I sent the sender of the email a high priority reply as to what the due date was and braced myself for a "4 PM today" type of answer. His reply was "oh, sometime before next July is fine."

We both got a little smile out of the implied urgency of the original mail, and I now can insert this task into a day for someone to take care of when all other higher priority tasks are completed.

Lesson learned: when someone has a task that needs to be completed, be sure to find out what the deadline is.

Questions, comments, concerns and criticisms always welcome,

John