Once Bitten, Twice Tested

Blake had recently been hired as a software tester, tasked with testing the company's product on the latest operating system, Windows 2000. After running through his battery of tests, he informed management that he hadn't encountered any issues, and the product was dubbed Windows 2000-ready. During the next several weeks, the product was smoothly deployed by customers—until an installer bug report came in.

"Did you test the desktop shortcut after installing on Windows 2000?" Blake's manager, Sammy, asked from the threshold of Blake's cube.

"Yeah, I'm sure I did," Blake replied.

"A customer emailed us to say that when he chooses to add the desktop shortcut while installing, it causes a Blue Screen of Death," Sammy explained. "It happens consistently for him. The only way he can install successfully is to not choose the desktop shortcut option, which he calls 'unacceptable from an IT security standpoint.'"

Blake frowned in confusion. "Security?"

"I know, it's weird," Sammy said. "I want to question him further on that point. In the meantime, I'd like for you to start looking into this."

The first step was to reproduce the problem in-house. Blake was sure he would fail; he was absolutely certain that he'd already tested what was allegedly crashing. His first move was to install the product on a fresh Windows 2000 box. He checked the "Add a desktop shortcut" option, and after a few moments, the installer completed with no errors. A shortcut to run the program now sat on the desktop. Double-clicking the icon opened the program flawlessly.

From there, Blake uninstalled and reinstalled the program. Yet again, no issues. Trying a different Windows 2000 PC was fruitless. Out of desperation, he even tried installing on Windows 98. In no case did a BSOD ever occur.

"I can't reproduce this bug," Blake told Sammy the next time the two were able to meet up in the latter's office. "The installer doesn't crash the system, and the desktop shortcut works fine. Is there something I'm missing?"

"Well, I just got some more info from the customer," Sammy said, with world-weariness bearing down upon him. "Did you try installing to the desktop?"

"Yes, I installed the desktop shortcut. Many, many times."

"No, not the shortcut. I mean, install to the desktop."

"To the desktop?" Blake repeated, frowning.

"The customer's corporate security policy considers program shortcuts untrustworthy. They fear they could be pointing to anything," Sammy explained. "To avoid any sort of issue along those lines, the customer is required to install all of his programs into separate folders on the desktop."

Blake's jaw fell. "What?!"

Sammy shrugged helplessly. "First they want to install shortcuts, now they don't trust shortcuts. I don't get it, either, but it doesn't matter. It should be possible to install our software into any valid folder without a BSOD. Go see if you can dupe this now."

Blake slinked back to his desk. Much to his chagrin, he was able to reproduce the crash. Upon further investigation, it was discovered that the installer could crash the OS if one tried to install to a new folder on the desktop or in the user's Documents folder. Blake received a scolding from Sammy for missing this the first time around.

It was a lesson well learned. In the years that followed, Blake strove to test every possible scenario, every fringe use case, every baffling type of input data that he could think of. Upon submitting his bug reports, he heard the occasional bemused comment from the developers: "Who in the real world would ever do that?"

Blake would merely chuckle to himself, remembering the desktop shortcut.

Featured Comments

Anonymouse (unregistered) 2019-10-29

Encountered similar problem once. We had hired a junior developer, given him a clean checkout of the code our flagship application from the repository, but he could not launch it from the very beginning, i.e. while compiling in Visual Studio went flawlessly, he could start neither in debug mode nor otherwise. A bunch of weird errors happened and the debugger could not go to wherever the errors came from because they were system level. For two days we tried to find the issue, until i found out this guy had saved the whole solution on his desktop. No one had noticed because he always had already opened VS when someone sat down with him to help. And no one had even suspected that a developer, junior or not, would come up with the idea to save a huge solution of over 8 GB of code on his desktop. BTW the actual reason is, the system DLLs .NET uses are saved in some folder very deep in Windows folder, where every other folder on the same machine has access rights except the desktop. So any project on desktop cannot use any method from the system namespace. I don't know why but it seems Microsoft deliberately did this. We just did not know because no one in the company had ever tried to run a solution including projects on the desktop before.