Defining Your Role as a Tester
Recently, I have found myself focusing less on the quality of an organization’s products from a
tester’s perspective. At this point, I find myself more and more in the role of helping organizations see the larger picture: How are they set up? What causes conflicts? How does the structure of the organization help build better quality? Most recently, I came across the work from Frederic Laloux and his book titled “Reinventing Organizations“.
Laloux has observed several companies in various fields that have a different structure than more traditional companies. The fields he examines range from nursing to car parts manufacturing. One of the things Laloux found out while studying these companies was the practice of self-defined roles. The idea is this: As an employer, you find out where you passion lies, and what you are good at doing. Additionally, you find out how your skills and your passions can bring value to your team, and your company. Then you go out, take advice from your peers, in order to define the role that you want to fill.
Ever since I read this, I wondered whether a different definition for testers based on this practice might be useful, and where it might harm larger efforts. Let’s explore these ideas.
Do we need a new understanding of the tester’s role?
At least to me, I get the picture that the role of the tester has changed during the past forty years. At some point in the history of software development, it seems that we lost some of the lessons of the earlier pioneers. For example, the roots of test-driven development can be tracked back as far as John von Neumann. I often refer to this period (the 1970s and 1980s) as the “medieval period” of software development.
Unfortunately, that’s also the time period when many companies’ picture of what a software tester should be were shaped. Terms like quality gatekeepers, quality assurance, and aggressively testing to find bugs come to mind when I think about the medieval age of software development. But what has changed since these early days of software development?
For one, with the uprising of more and more agile software development shops, the more emphasis has been placed on team in the industry of software development. Laloux supports this more generally. He observed self-management with self-managed teams in the companies he visited as one of the breakthroughs of more modern organizations. How does this affect the role of testers?
Traditionally, developers and testers were set up in different places of the organization’s hierarchies, the prevalent argument being that a programmer faces cognitive dissonance if he is set out to test his own code, thereby producing substandard work. Folks in the medieval times of software development went further with this, and separated the departments altogether, since they assumed that a tester under a programmer superior would do a worse job.
Now, as the trend becomes to integrate testers more fully into the whole development team, the role of the tester certainly has to change. But how should it change? To build upon the work from Michael Bolton and James Bach, testers should become more of a quality assistant to the team, rather than the gatekeeper. For this assistant perspective to take hold, some testers certainly need to change some of their own personal behaviors. It’s no longer part of the role of the tester on a team to dominantly advocate for his own viewpoint. Certainly, an immature team might engage in this sort of practice, but over time when the team starts to jell, the bigger importance lies on the tester helping other team members reach an understanding on how they can more thoroughly test their code – not necessarily their own code. When more team members reach a basic skill-level of testing skills, the overall team’s quality of work will raise.
What about the drawbacks?
Cognitive dissonance surely is something to consider here. Also, peer-pressure among a team of six programmers can be intimidating. These factors come with the understanding that a tester also needs to be able to handle peer-pressure and cognitive dissonance well enough to not compromise their own work. So, the major drawback lies in their very own abilities to overcome these drawbacks, and unfortunately that’s certainly something that I have rarely seen being taught as a soft-skill to testers new in their job. Most job trainings for testers prefer to focus on techniques and best practices.
For other team members to know what to expect from a good tester, I think it’s mandatory to outline what you think you can do as a tester, where you think you can help the team to perform its work better, and set the right expectations. If your team colleagues know what they can expect from you – and what they can’t expect from you – they will have the chance to deal with the gaps. The whole team will have the chance to see how they can fill any gaps that occur. Therefore, I think, defining your very own role as a tester among your team is one of the best ways I know to do just that, and to excel in the new style in which many organizations have been structuring themselves.