DepartmentsDepartmentsIn my former life I was a test engineer, and if you're involved in software testing you may have had experiences similar to mine. My company seemed to treat our test department like a loathsome brother-in-law, whom they could not be rid of but maybe could ignore if they tried really hard. I think it was because we told them things they didn't want to hear. Well, that is the essence of test work, isn't it? You're forever exposing flaws in your company's products, and that doesn't make you very popular.
I've been skimming a brochure from the U.S. Professional Development Institute (USPDI) for their 15th International Conference and Exposition on Testing Computer Software, which is to be held in Washington D.C., June 8-12. The theme this year is "Testing Under Pressure." I find that mildly amusing: when has testing not been done under pressure? Elizabeth Adams, a QA manager with the Lousiana Workers' Compensation Corp., is a presenter at the conference, and the subtitles in her course description echo my experiences in testing: "Who Died and Made Our Testing Team 'The Enemy?' "; and "Implementing CAAT: Corporate Attitude Adjustment Therapy." Ken Haubrock, an SQA manager at Capitol One, has a course entitled "Putting the Fires Out in Testing Hell: The Basics."
If you think those titles are too flip for something as serious as test work, rest assured there are more conservative ones, like "Overview of Software Metrics," and "Improved Testing Through Software Reliability Engineering (SRE)." Personally, though, metrics and SRE are not terms that make my heart beat a little faster. Instead, they make me wonder why there seems to be so much distance between the tester's world and the programmer's. Programmers know that the truly evil bugs obey no metrics. A single, well-placed bug can turn a $100 million satellite into an orbital boat anchor — and how do you assign a metric to that? On the other hand, QA people know that if programmers would give formal methods a fighting chance, they really would produce better code.
There ought to be a way to bring these two worlds closer together. If you can swing it with your company (and on such short notice) attending this conference might be one way to do that. Of course, the subject of this conference is one step removed from programming — but in a way, that is my point: should it be?
I've never had any dealings with USPDI, and I haven't attended any of their conferences, so I can't evaluate their courses. But if you're interested, you can find out more at http://www.uspdi.org/conference. This may be your big chance to become Most Unpopular Person in your organization.
Marc Briand
Editor-in-Chief