-Danny Faught
I got the certification back in 1996 when it first was made available. I actually drove to Dallas and paid for a hotel room so that I could take the test. I applied for the certification because I was focussing my career on software testing and thought that a certification would help define me as someone who was committed to the field. I also knew that Cem Kaner and James Bach had participated in defining the certification, so I figured it had their endorsement. Taking the test forced me to study several books that I might not otherwise have read, but have been useful. I have no regrets about taking the test. Indeed, I really think the test is pretty easy. Many of the questions came straight from the books on the recommended reading list. It's an open book test. I brought a book bag full of books to the test. For some, I simply had to know which book to find the answer in.
Around the same time as I got certified, I started presenting conference papers. I think the papers have done more for my career than the certification. Both impress employers, the papers probably more so. They can look over your paper and figure out what it says about you. Most don't know what the different certifications mean.
At one job, I got a new manager who wanted to change our QA department's focus from testing to inspections and process enforcement. He was in the process of getting his CSQE. When he learned that I was certified, he looked to me to back up his ideas, assuming that I shared his views. I didn't. I thought that they were inappropriate for the company, and I told him so. My position annoyed him, but he seemed to give it more credence because of my certification.
Every three years, you need to renew the CSQE certification. They require you provide evidence of continuing education. With all the workshops I hold, the seminars I teach and the conferences I speak at, I meet this requirement easily. It took me a couple days to collect the proof I needed the last time I renewed. And there is a nominal fee.
Certification is really about credibility. Now that I have a book out and am publishing a lot, the certification doesn't really give me much credibility. Actually, credibility works both ways. One of the reasons for my original interest was that Cem and James were associated with it. Since I took the exam, I've had a chance to discuss their association and learn that they have some serious reservations about the process used to define the certification. Indeed, I now have some reservations myself. Continuing to claim the certification may give others the impression that I endorse it.
My main issue with it is that it doesn't certify on the basis of skill, but rather on familiarity with a set of rules of questionable applicability. It takes a lot of material from the CMM and ISO 9000. The value of this material is debatable: I've seen it misused but also used well. The real problem is that the certification leads people to think that knowing these standards is the basis for competent work in quality engineering. I think that the very concept of software quality engineering is not well-defined and often not what industry is looking for.
I'm more comfortable with the certifications that focus on testing, because what employers want is really better testers, not quality engineers to second-guess the developers. But even the testing-focused certifications that I have seen test on the basis of familiarity with standards and the ability to regurgitate opinions about testing that the certifiers have.
We certify drivers based on their knowledge of the rules of the road and their demonstrated ability to safely drive a vehicle. You and I know that if all you know is the rules of the road and how drivers are *supposed* to drive, you're going to get into a wreck real fast. To drive safely, you need to be able to understand your driving context and know how to operate your vehicle in it.
It's the same with testing. But none of the certifications actually test for practical skills.
Another reason I'm allowing my certification to lapse is that as an independent consultant based in Texas, I can get in trouble if I publicly claim to be a software engineer. You know that Texas is one of the few states that licenses professional engineers in the area of software. Claiming to be a certified software quality engineer exposes me to potential malpractice claims. Because of this I've been removing references to it from my website and other publications. It's not worth the risk. You should talk to your lawyer before publicly claiming to be a CSQE.
First of all, I recommend that testers write articles or submit papers. For people who've already done that, I don't see that certification provides much additional value.
For testers who aren't inclined towards writing, I can see some value in certification. They do need to understand that all the certification bodies have their own agendas. Many are nothing more than incentives to take training from particular training providers. Others interested in pushing their own ideas about testing as accepted wisdom. I've found that good testers are skeptical and critical thinkers. None of the certifications encourage this.
An alternate is to build up a portfolio of work samples. If testers can't get permission to share test plans or bug reports from their projects, they might consider volunteering for an open source project. This may be the most impressive way for them to distinguish themselves.
-Bret
| Back to the August/September 2002 newsletter | Back to the home page |