Let me start by saying that normally I’m proud to be seen as a software tester. I understand how challenging, rewarding, and interesting this job is. However, there is a dark side to being seen as a tester. Testers can be treated differently by people who don’t understand or don’t see testing the same way I do. This disconnect can not only devalue the testing effort but at its worst it can put an entire project at risk.
Let’s start with how I want to be seen as a tester. I view software testing as a service, and I want to provide valuable feedback to my stakeholders in a timely manner. To do this I need to maintain a high level of project awareness and knowledge at all times. This means I need to be on the inside of a project actively participating in discussions and learning as I go. I want to be aware of what’s happening in development, marketing, customer care, and even sales. By being actively involved at this level I gain a greater understanding of the context I’m working in. I use this improved understanding to increase the value and effectiveness of the testing effort.
With that said, often people view software testing as an administrative task that happens toward the end of a project. In their minds, a tester makes sure the software works the way it was specified and fills out test documents to satisfy that expectation. A tester is typically given limited information about the project and is usually only included in discussions if it’s felt that they relevant to testing (by their definition). This draught of information leaves the tester with little to no context, which can lead to feedback that has little to no value, which results in reduced overall testing value and effectiveness.
So while I love being seen as a tester for the right reasons, I would rather not be seen as a tester for the wrong reasons. To combat this and add value to a project I need people to think of me as a developer, marketer, support representative, or sales person. This ensures that as conversations occur or information flows I’m included and privy to it. By being included I don’t miss out on critical project information that may not on the surface seem “tester appropriate.” My philosophy is I would rather have too much information then not enough, when doubt invite me or share, then I can decide if its “tester appropriate.”