Software Testing Certifications- Does the Industry need them?

I have been one of the testers who had got caught up with the Software Certifications trend early in my career and have also managed to "Pass" a few of them. As a general format, these certifications (provided by many private vendors) has its own Body of Knowledge for Software Testing and follow a certain format for evaluating candidates. Some of these certifications have been really popular among the testers as well as some of the big organizations. Some organizations even have these certifications as a part of their "must-have" or "good to have" skills for particular Software Testing jobs. I have even come to know of a few organizations in which one of the criteria for promoting the people to a new role is to successfully pass one or few of these certifications. All these signify the lack of standardization of education on Software testing. With no available benchmark to appropriately judge testers, the authorities providing these certifications have turned this situation to a successful business idea. These certification cost the applicants a few hundred dollars or thousands of Rupees and have thus turned out to be huge money spinners needed to sustain the profits of these organizations. Moreover, all these certifications comes with a certain Expiry date after which the candidate is required to "renew" the same (meaning spend more Dollars).If the applicant wants the additional study guide which incidentally is required to pass the certification exam, then one is required to shell hundreds of dollars again. Shelling money for a cause that helps you gain knowledge is good but over the years what I have found is that the whole process of gaining the Certification is no good than learning the skills required to pass the examination. There is a little one really gains about Software Testing in the whole process. I believe that all the people who have reached a stage in their lives to called as "Software Testing Engineer" would have already "passed" many examinations in the journey of being called the same and are smart enough to understand what is the difference between passing the exam and gaining the knowledge on the subject. In the current context, these are two different things. Being certified doesn’t not mean that one is an expert in the field. Being certified simply means that one has met all the defined criteria set by the Certification authority which incidentally is only passing the exam in most of the cases. The fact -of-the-matter is that there are many people who would struggle to define "Software Testing" or even present their perspective of Software testing even after being Certified. As the one who has worked at the ground level, there are few reasons that I could think of on why there is a mad rush among the people to be certified-
1. People perceive "being Certified" by a certain body as a means of being recognized in the profession.
2. The role models/Seniors in their respective organizations have got certain certifications, so people would want to emulate the role model.
3. Certifications are often seen as the Status Symbols. Some use it as a means to make their Signature more impressive.
4. Most organizations promote these certifications as a part of Continuous education of employees.
5. Managers put it as one of the goals for their subordinates to complete a certain certification in a review year.
6. Some junior testers would want to do the certifications to "improve" their job prospects.
7. Since most of the published jobs in the market today have a mention of some certifications as a required or desired skills, people opt for these.
8. People interested in going out of the country for the job perceive these certifications as important to have.
9. People want to learn something new, something meaningful that they can apply in their jobs.
10. Want to become experts in Software Testing.
These reasons are not cooked by me but are as result of opinion I have formed upon meeting the different people. The percentage of entire population that I have come across who wants to go for certification for the last reason (point#9, 10) is quite less.
Having being Certified myself, I can tell that personally I do have gained some good things from these certifications. Apart from knowledge, the concept of re-certification has helped me plan my career in some ways. Instead of going for exams for recertification I chose to collect the Credit points (honestly!) in different suggested areas. It really helped to broaden my horizons and helped me to take the road less travelled. But of course, one doesn't need to be certified to do such things; it can be a part of one's career planning only.

Further views on Software Testing certifications at- here

A perspective on Lesson# 67 and 75- Bug Advocacy

Yes, I am talking here about the book that must be on every Tester's desk for myriad of reasons. It's "Lessons learnt in Software Testing" by Cem Kaner, James Bach and Bret Pettichord. I have been following this book for a while now and have experienced that this book not only provides valuable Testing lessons by super experienced trio of authors but quite a few lessons in effective book writing.
This book is all about Context driven testing approach and summarizes valuable lessons in different areas. The best way that i have found to enhance learning from this book is to read a particular lesson and then close the book and co-relate the learnt lesson to your experience or context. Here's some of my comments (based on context of my experience)-
Lesson# 67: Report Defects Promptly
Lesson# 75: Do follow-up testing on seemingly minor coding errors
Both these lessons are self-explanatory as the title suggests but a particular thing that i wanted to highlight here is that in some of the situations that i have been-it is typically challenging to get both these lessons going together in a context. Take a look at following experience snippets-
1. In the past, i have been involved in testing a networking product that had a huge dependency on setup and at the same the product had a very short release cycles. In such a product, the testing involved used to be quite setup intensive and understandably it was very time consuming. Every bug found would involve a lot of investigation which would typically take a lot of time (running into hours and sometime a whole day). And since the release cycles were short, everyone expected test team to report bugs as early as possible to give development team ample time to fix it. And to further add to this situation, the development and test teams were located in separate location geographically (separated by almost 12 hours time zone wise).In this situation, following the above lessons(#67 and #75) used to be quite challenging. Some of the challenges include-
a. If a tester is new (i.e. hasn’t yet established a reputation with the developer), then it was imperative for him/her to write complete bug report with all the investigation. If he/she fails to do so, it would result in damaging the equation with developer who sits remotely. This is a typical issue with a "faceless culture" i.e. the organization culture in which you need to team up with people who you haven’t met or seen. In such a culture, a tester would be judged solely on the basis of his work products i.e. Defect report. So a new tester would typically need more time thereby, delaying the defect logging time.
b. Even for an experienced tester in such a situation, it would take more time if he/she comes across a non reproducible kind of a bug which would take a lot more Investigation.
In such situations, we found it to be typically wise to contact developer with all the details. This has a people management challenge as It definitely means the tester work late hours to contact with offshore development team and have a talk and get into agreement to report a bug with available information and continue with further Investigation the next day.
If the development team and testing team work in the same time zone, it becomes easier to collaborate in these situations.
2. There is one more situation in which i have found the follow-up testing to be typically time consuming. This situation occurred during the Internationalization testing of a Client/Server product in 5 languages. As a part of bug information, sometimes the developers would expect the testing team to report results of the bug in all the 5 languages. What this would mean for testing team is to prepare a setup in all the languages under test and reproduce the defect 5 times and report in the bug. Being a client/server product would make preparing such a setup even more time consuming, thereby increasing the bug
logging time. It is always good in these situations (typically Internationalization testing) to get in the agreement with developer during the planning phase to understand the expectations because such a testing is indeed time consuming and would have impact on test schedule.