When I started developing and testing software in the late 1970s, there were two kinds of technical staff: “hardware people” and “software people.” Perhaps we had a few other labels like hardware engineer, programmer, and software engineer, but in practice, there were only two kinds.

In my first job in computer programming and while I was still in school, I was a junior business analyst, systems person, programmer, data analyst, and tester. I did it all (under strict supervision and mentoring). We did not have titles and divisions, such as someone being referred to as a “tester.”

In my second “programming” job and after completing a degree, not quite two years later, I think I might have been called software engineer, but nobody was too sure what that was, and my main task was performing structural testing of code. I learned testing (and programming) from the first generation of software people. Most of us had college degrees, but not everyone had formally gone to school, and our degrees were in things like math and physics. We programmed. We tested. We learned. We read the few books on the subject (e.g., Elements of Style, Programming in FORTAN, and the Art of Software Testing). We did not worry about titles or labels—much.

In the thirty-plus years since, the industry has evolved. It is not clear to me if this evolution is entirely a good thing, but it probably contains a mix of both pluses and minuses. Overall, things have improved to some degree.

Enter Testing
The first generation of testers has retired; some are still alive. Those of us who became the second generation have aged and started thinking about how we can improve the pluses of our industry. We have worked to place more education into colleges and in our professions. Items like the IEEE SwEBOK (software engineering book of knowledge) appeared with defined terms for software testing. College programs in software engineering were developed, and during the 1990s and 2000s, hundreds of college classes on software testing became available.

Additionally, IEEE and ISO standards were created in software, systems, and testing, although companies used such standards with mixed results. The industry went from worrying about just creating software to producing “good enough” software. The standards that were developed recognize the value of testing.

Conferences in software testing appeared, some of which live on today, and education in software testing became readily available. We even have established associations, such as the Association of Software Testing (AST).

At the same time as these across-the-board improvements in information about testing, there has been a second track: an explosion in certificates, certification, and even college degrees with a focus on testing. I find that explosion surprising and, perhaps, a bit puzzling.

I have to ask “Does knowledge from a skill list (from a book or standard), degree, certificate, or certification mean that you are a good tester?”  “Does a well-practiced test skill mean that you are a good employee?”

Unfortunately, the answer to both of these questions are “no.” This has led to confusion and debate in the test industry with people expecting great things just because a person has one of these “pieces of paper.” A practiced skill should not be confused with a piece of paper. Pieces of paper come in a variety of forms, as defined here:

• Certification (including testing)
• Certificate (academic meaning you passed a specific class or test)
• Degree (academic meaning you passed a series of classes in a program of classes)

There is a debate, even a passionate argument, about these “pieces of paper” in software testing.

Does having any of these mean you have a skill? Pretty much anyone in any industry would answer “no,” since most of these are focused on knowledge. You must practice with knowledge to have skill. You must learn and grow. What these pieces of paper mean to me are that you have an interest and have shown some ability to learn. This is true in almost every profession and activity. For example, you can read books on snow skiing. You can pass tests of knowledge about skiing. But until you try to practice skiing, by doing it, you have no skiing skill. In fact, for most people skiing practice takes years or a life time to get to be a good (aka, expert) skier.

As a profession, we need to understand what these pieces of paper mean, the promises they can keep, what they may lead to, and what are some reasonable expectations for them. Each of these pieces of paper has a plus side and a minus side. For example, a degree means that you can learn to someone else’s expectations of knowledge, but on the minus side many people with degrees (some Ph.D. students that I’ve known) think they have skill and know it all.

A similar situation exists for people that get certifications or certificates. Further, each piece of paper may have the benefit of exposing the student to knowledge and learning. However, the bad side is this: once people think they know something, they often become close-minded, which is bad.

What to Do
As an industry, we should define the knowledge base, skills, styles, etc., as a move forward. These should be done by the different philosophies (aka, schools) of testing. These will become the basis for people to learn, practice, and develop. It is not good to call people “zombie” testers, say that a standard is “toxic,” or critique degree programs unless you have a solid alternative, can demonstrate with experimental information and data when these statements are true, and engage in meaningful dialog about improvement in the industry.

Next, just because a person has a certification, a certificate or degree, does not mean that I expect much from that person. For example, a person with a degree in massage therapy can help some minor medical ailments, but I am not going to expect of this person nor bash them because they cannot do brain surgery. I would not expect my son the medical student (with many degrees behind him) to be a brain surgeon either.

Each philosophy group in testing needs to work on a knowledge and skill list, a path of progression, specific development paths, as well as practice activities to get software testers to progress. As a hiring manager, I have used the pieces of paper as a quick filter on reading resumes. Once I found people I liked, I would talk to them and see where they were in their practice of software testing and where they wanted to go. If they had passion for the practice of testing and some skill, I’d hire them. If they told me they knew it all and what I was doing was somehow “wrong,” I usually did not hire them—but might have in some rare cases. If they did not want to practice and only wanted a job, I definitely did not hire them. For many companies and hiring managers, degrees, certificates, and certifications play a role in getting a job; so many testers may want to get such pieces of paper to aid themselves in finding gainful employment. However, I encourage you should not to read added value into a simple piece of paper, especially since testing is a professional practice to be worked on for many years.

My goal today was not to settle the discussion, but to stoke it while setting some expectations for civil discourse. Remember, our profession is maturing, but it is not mature. Let’s keep talking.