For the past six months I have transitioned into a new role at a new company. I am now a software tester. For the past eight years, I have spent all of it but six months developing software, writing code, and thinking testers were individuals who chose a comfortable, stress-free career path, where they might be found playing World of Warcraft or reading science fiction novels in between periods of pretending to do work.

There, I said it. Now the healing can begin.

What was I doing for those six months when I was not developing? I began my career as a tester fresh out of school. I worked closely with a developer, we all worked in pairs back then. I discovered the work he was doing in development was sexier than what I was doing in testing. The rest is history.

"Software testing is  process, or a series of processes, designed to make sure computer code does what it was designed to do and that it does not do anything unintended. Software should be predictable and consistent, offering no surprises."

Yawn.

If you are still awake, I appreciate that. If you share my sentiment about testing, I cannot fault you. For the same reasons I wanted to get out of testing and into development, I was hesitant to get back into it.

Sadly, I had preconceived notions of what testers do and what skills and career goals they possess based on previous organizations.  For example, it was easy for me to generalize that the testers with whom I encountered were not as technical as developers, they were not writing code nor had any desire, and they wanted to get into the technology field but did not want to earn a CS degree. It was an easy way in. These are all erroneous generalizations that I regret thinking at one point in time, and for the most part, they were geared towards black box testing.

With testing comes new challenges. What I have read, and what I am trying to apply to my work, is the idea that the "attitude of the software tester may be more important than the software process itself."

In a nutshell, what this implies is that testers should approach their craft by trying to uncover the errors and failures within the product, rather than trying to prove the product works as expected. A tester should be disappointed when he/she cannot find errors, failures, bugs, ect. The mentality has shifted from constructive to destruction by nature.

As developers, we focus on developing a product, creating or constructing something. The subconscious wants to see it succeed, if not willing it to succeed. The attitude is constructive. If we approach testing the product by proving it contains no errors, we may subconsciously be influenced to choose data proving no errors exist, ultimately reducing our chances of discovering failures and defects.

As testers, our attitudes need to become destructive. This transition is difficult for some, since most of us approach our work constructively, meaning, we are used to building or creating things, rather than destroying them. We need to destroy the product. Do what we can to break it, cause it to fail, and bring it to its knees exposing weaknesses, vulnerabilities, and the many errors and bugs that do exist.

As testers, we write tests, test cases, and we strive to automate as much of it as possible. We even strive to automate the creation of more test cases. If our tests fail, they are successful, because this means our tests prove errors exist. When errors exist, testers are happy - developers are not.

Much has changed with my perception of software testing, starting with a fresh, new outlook and an attitude adjustment. And oh yeah, I forgot to mention, all those core object-oriented principles, practices, patterns, and frameworks, those are equally important in the world of testing as they are in development.

I work for an organization where heavy emphasis is placed on testing. I now spend much of my time developing automation frameworks and controls used to author tests. In addition, I am tasked with building a system to implement and measure code coverage, and investigate fuzz testing and model-based testing. This is hopefully the first post of many pertaining to and influenced by testing. Read more about the SDET versus the SDE here.

References: