Tejas Software Consulting Newsletter

v2 #4, August/September 2002

I have the money and the taste to dress well, but I'm a prince from another country, so I don't have to.
I had the fortune of hearing Eric Raymond, the evangelist of the Open Source movement, speak at the Dallas/Fort Worth Unix Users Group. This quote related to his fashion advice for geeks who want to dress appropriately when they talk to executives about the benefits of Open Source. Another way he phrased it was "Dress like a high-ranking member of a social order they don't understand." He gave specific advice on how to do it, but I think I'll let your imagination run wild. :-)

Welcome to my soap box. If you've found this newsletter tacked to a wall, lying on a table, or handed to you enthusiastically by a prince from another country, please consider going to http://tejasconsulting.com/newsletter/ to sign up for a free subscription to the email edition.

-Danny Faught
faught@tejasconsulting.com
http://tejasconsulting.com/
817-294-3998
 

Contents

Tejas Newswire

A few people have told me that they didn't receive the June/July issue. If you didn't receive it, remember you can always get back issues at http://tejasconsulting.com/newsletter/. Also, to verify that you're still subscribed, you can re-enter your email address in the subscription form - you'll get an "Already Listed!" message if your address is in the database.

My conference presentations are all off to the printers now. Let me know if you'll be at Quality Week (San Francisco, September 3-6) where I'm presenting "A Survey of Freeware Test Tools" and "The Making of an Open Source Stress Test Tool" or the Software Test Automation Conference (Boston, September 24-27) where I'm giving the tutorial, "Perl Scripting: A Test Automation Task Master."

I have done the cleanup necessary for distributing the stress_driver tool (I managed to mention it in all three of my upcoming talks). I expect to post it on the web soon. In the meantime, let me know if you'd like a copy of the source.

Feedback on the June/July issue

Jeff Bay commented on my "Test-First Maintenance: A Diary" article:
The comment you made about XP testers not writing negative tests was not true in our case at least. About a fifth of our tests were code that executed in an eval and then checked various conditions on the resulting error message (primarily that there was one, sometimes that certain errors were returned).

re: testers having to ask for program modifications from the developers... I think you'll find that the agile philosophy doesn't typically work very well in an organization with a rigid test team/development team separation.

re: oops - as for deleting code that you've commented out - once you have worked with a source base for a while and have an extensive set of base tests, you can make almost *any* change more easily and with lower risk, including deleting code :) Also - not using source control? In the XP model we used, we did our development in very small bits with lots of checkins and integration.

arg! I was hurt to find that you stopped after only 12 tests! :) A program doesn't start getting really cool to work on until you have 10 tests per module!

You got me on the source control issue. I'll try to do more frequent checkins - especially before deleting code. Regarding the number of tests - I haven't stopped the work on stress_driver. You only got a snapshot in time. The diary continues to grow.

Jon Allen wrote about "What Flavor is Your Freeware?":

That's a great feature article.  You've given a very clear explanation of free/open source software that was succinct and still hit upon the nuances in free software licensing.

As an aside I think an automated testing solution would make a great open source project.  Something that can harness the power of perl or python and build an automated testing suite to rival the big boys.  That would be really cool.

Thanks Jon. I hope to spark enough interest in open source among the testing community so that we can make some cutting-edge tools available, and also increase awareness about the many tools that are already out there.

I should mention Jon's "Testing in the Bazaar" article that is posted on StickyMinds. It's a nice article about testing on an open source project.

I can always count on an insightful response from Robert Coutré:

I very much liked your distinctions from shareware: "That puts shareware into a category that I call 'cheapware.' A similar type of cheapware is adware, which is free to use if you don't mind the software displaying advertisements while you use it."

I was cringing at the thought of any type of payware or ad-laden-ware getting away with calling itself shareware--and I think your categories "cheapware" and "adware" are an excellent solution. Shareware is shareware, period. Payment is sometimes "suggested" but always optional (or should be).

Actually, I've seen several programs calling themselves "shareware" that require payment after a certain period of time. That type of software is squarely in the category of commercial software. I don't have enough data to judge whether this expanded definition of "shareware" is becoming widely accepted.

Feature Article
The Dark Underbelly of Certification

There's a new certificate up on my wall. It says in a properly officious tone that I am "certified by the Society as a Software Quality Engineer." The society it refers to is the American Society for Quality (ASQ), and the certification is commonly called the CSQE. You may have read papers with titles like "Certification: A win-win investment for employees and employers," by Eric Patel and Darin Kalashian (12th International Conference on Software Quality), some of which is reprinted in the book Systematic Software Testing (starting on page 326).

Certification is always a great thing, right? Yet I've had the certificate on my wall for more than a month now, and this is the first time I'm making a public announcement about it. I had to put a lot of thought into whether to announce it at all. I may have done a terrible thing. How could that be? Read on.

I was recently invited to attend a meeting at the STAR East conference to discuss the ISEB Software Testing Qualification that is sponsored by the British Computer Society. An international board is forming, and we were to discuss the best strategy for offering the ISEB certification in the United States. I was vaguely aware of some of the controversy surrounding certification, and it happens that I had signed up to take the next CSQE exam. However, I hadn't been following the debate very closely, and apparently neither had the people who organized the meeting. By the time the meeting concluded, the participants didn't even agree on whether certification is good in the first place. We scheduled another meeting a few days later, open to the whole conference.

"Cool!" I thought. "I have a chance to apply some of the skills I learned at the Problem-Solving Leadership Workshop." I talked with Dot Graham, one of the facilitators of the meeting, to see how we could have a more productive meeting the next time. And while there was still some controversy at the meeting, it was well-organized and we did make some progress. Maybe this stuff isn't so hard after all!

I left the meeting room, and there in the hotel lobby sat some of the people who had voiced the biggest concerns at the first meeting. They hadn't shown up at the second meeting. No wonder it went so smoothly! They told me that they felt that the meeting organizers assumed that the participants already agreed that certification is good. The people who were most concerned about certification didn't want to disrupt the meeting rehashing a subject that the organizers considered to be a foregone conclusion. Maybe that was the best choice, but I was very frustrated that I didn't get to hear the debate. So I've asked some pointed questions of some opinionated people.

The underbelly

Most of the people that I know who have a beef with certification are members of the Context-Driven Testing school of thought. Their principle #2 is "There are good practices in context, but there are no best practices." That sums up one big complaint about certification, because they see the bodies of knowledge for the certifications as necessarily establishing best practices. James Bach told me, "We don't yet know what practices work, why they work, and what skills make them work." James is also concerned that a body of knowledge tries to unify the different communities of practitioners. But different communities can have vastly different processes, for example, embedded military software development and web site development. The different software communities aren't all trying to unify their processes. Should certification be the primary vehicle for doing this?

Bret Pettichord agrees with James on another point. Bret says "None of the certifications actually test for practical skills." James wants to see a skills-based certification modeled after the way pilots and doctors are certified. So what do the certifications prove? Jerry Weinberg says, "In the case of test-based certifications, many, if not most of them, have a 'course of study' that if you show up for it and have a minimum of brains and attention, you can easily pass. They are not performance based..." Jerry says that certification only predicts that you'll have a good attendance record, because you were able to show up for the course.

Bret does say that certification can add credibility, and he mentioned a specific case where his certification seemed to give him more credibility when he had a disagreement with his manager. But now that he has published articles and conference papers, he feels that they are much more effective at building credibility than certification. He is letting his CSQE certification lapse when it comes up for renewal. Another reason he cites for letting his certification lapse is his reservations about the process that was used to create the CSQE; he doesn't want to endorse the certification by continuing to claim that he is certified. Yet another reason is his concerns about the "engineer" terminology. State law restricts certain types of engineering practices to those who hold a Professional Engineer (PE) license. As far as I know, no one has tested in any state court whether it's legal to claim to be a Certified Software Quality Engineer without holding a PE license.

Maybe certification isn't all it's cracked up to be. After all, it's a standardized test, and standardized tests have long been a source of controversy in our school systems. But can it be harmful to hold a certification? James Bach says that it could come to that:

This is a fight, in the sense that I think there will be real consequences for people on either side of the debate. I think, as time goes on, I will not be able to take a colleague seriously if he or she feels the need to be "certified." It will be as if a delegate to a meeting of top astronomers announces that they use Tarot cards to discover the age of the universe.
Jerry says that certification is a clue that someone might not have a lot of confidence in themselves. And others have told me that they would hesitate to hire someone who holds a certification, because they would be afraid that the candidate believes that there is only one proper way to approach the job.

Where do I stand?

That's what other people think. Here's what I think. I felt a desire to take the CSQE exam as soon as I was eligible. Mostly, I think I saw it as another merit badge. As I was growing up, I got many tangible tokens of my accomplishments. I hadn't earned many merit badges lately, so I think I subconsciously wanted to fill that void. I did not expect an immediate promotion or raise when I got certified, and partly for that reason, it took me a while to get around to applying to take the exam. I don't believe the implications of the salary surveys that organizations use to try to show that people who get certified will get paid more because of the certification. I believe that the people who are able to qualify for and pass a certification exam are likely to have above-average salaries regardless of whether they are certified.

After I became an independent consultant, I felt a stronger urge to get certified - to help build trust in potential clients. Having a certification would also open up a marketing opportunity for doing training to prepare other people for the exam. In this economy, we need all the opportunities we can get. My expectations were even lower than before, though, because I saw that few managers knew anything about software certifications. I was starting to see some of the negative opinions about certification, but to be able to form my own opinion, I wanted to experience the process first-hand. After all, it seemed strange to be a senior member of the ASQ but not hold any certifications. I finally took and passed the exam this June.

I watched for questions on the exam that weren't put into proper context. I don't remember seeing very many blatant over-generalizations. Maybe I missed some because I'm so used to automatically evaluating the context of a question. I did, however, make good use of the feedback form to complain about several ambiguous questions, including one that presupposes that we all agree on what the definition of "quality" is.

Now that I have the certification, what do I do with it, besides writing about the experience? This was a very difficult decision. As much as it irritates my colleagues like James, I've chosen a moderate position. I've decided that I will mention the certification on my resume. It won't be particularly prominent, and I won't even spell out the "CSQE" abbreviation, in hopes of reducing the chance of being accused of falsely claiming to be a Professional Engineer. I don't believe that it will have much impact on my business, but I believe that the likelihood of it being an asset slightly outweighs the prospects of it hurting my business. I will not mention the certification on my business card, nor will I include it in the biographical sketches that I'm frequently asked to write. To use Bret's logic, having written this article itself is at least as beneficial as having the certification, and the article will be displayed more prominently.

When I evaluate someone else's ability to do a job, if they are certified, I intend to probe further. Do they appreciate the context-driven testing school of thought? Have they actually applied the skills that are in the body of knowledge? Only by talking with someone will I know whether the certification is a hollow confidence-booster or a sign of someone with above-average initiative and abilities.

Jerry puts it into perspective for us -

I've been hearing this argument for over 40 years. It's all been wasted breath. We had the same percentage of ardent opponents and advocates as we have today, and still the vast majority is indifferent.
If you casually read the latest buzz about certification, you might get the impression that it's a win-win situation. At a minimum, it looks like a win for training providers, because they seem to be able to generate a demand for certification and for the training services that go with it. If I've been able to enlighten any of you about the dark underbelly, hopefully my breath/keystrokes will not have been wasted.

James and Bret both gave me thorough comments about their positions on certification, and I've only been able to touch on some of their points here. Follow these links to read their complete statements - Bret Pettichord, James Bach. What do you think about certification? I'd really like to hear from you.

Copyright 2002, Danny R. Faught
#####


  Back to the newsletter index    Back to the home page