by Joseph Pescatello

Created on: August 16, 2008

IT professionals, software developers, support analysts, quality engineers, and their managers virtually anyone who works professionally with software will eventually, if not frequently, have to submit a defect or software problem report. When software acts unexpectedly, you'll have to determine if the problem is your own or someone else's; if it is environmental, or user error; if it is even a problem at all. This ability to winnow out the root of a problem and report it accurately is a rare and valuable skill. Making sure that the cause is treated and not the symptom will save time, effort and money

Be sure it's a bug

Is it functioning as-designed?

Software development is a relatively young and amorphous endeavor. As such, there are few standards to proscribe the way any given program should act. Developers build what they understand to be the correct solution to a particular problem, but what they build isn't always what users of the program expect.

When users attempt to perform an operation, they expect a certain outcome. If the program doesn't produce that outcome the person using it might naturally presume the program has a bug. While this is sometimes the case, the program may be doing what the developer designed it to do. In this case, the program is said to be functioning as-designed'.

If you file a defect or software problem report (SPR) on a program that is functioning as-designed, you may receive a note from the developer describing the intricacies of the particular operation. Hopefully, you're working with an articulate developer who has patience and a good sense of humor. If so, the information you get from him or her will be enlightening and useful. If your developer friend is having a bad day/week/year, you may get a less-than erudite explanation as to why your SPR is not worth the paper it's written on.

In either case, it's best to avoid writing SPR's on features that are functioning as-designed. To that end, be as certain as you can be that you understand the functionality in-question. Read the documentation, talk to other users and use tech support to make sure that the program is designed to do what you're expecting. You should even talk to the developer if you have access. A quick discussion can save a lot of emails, memos and erroneous SPR filings.

If you file an SPR that comes back as functioning-as-designed', you might want to have the documentation team make note of the behavior somewhere in the user manual. After all, if you a seasoned software

• 1
• 2
• 3
• 4
• 5
• Next Page >>