Stupid Silos

Division is part of identity. Finding a group of people to belong to, who share distinctive characteristics or thinking, helps to shape our view of our selves. But I get frustrated by the repercussions of how we group ourselves as testers.

Functional vs. Technical

A pet peeve of mine is the division creeping in to the New Zealand testing community between a test analyst and a test engineer, where the latter is used to distinguish those who are capable of writing automated checks or using automated tools. It annoys me because I feel the industry is lowering its expectations of testers. A test analyst is given permission to be "non-technical". A test engineer is given permission to switch off their brain; no analysis required, just code what you're told to!

Why has this distinction arisen? Because organisations place higher value on the automated checks produced by an engineer than they do on the information available from an analyst. How is this possible? Because many engineers genuinely believe that their checks are testing and many analysts are producing terrible information. How depressing.

I wish we hadn't created this divide. A tester should know the value and the limits of an automated suite, be capable of test analysis and provide quality information to the business for their decision making. A tester should be encouraged to have a breadth of skill. The silos created by our titles are preventing these type of people from developing.

Attaching the blinders

Similarly, I am annoyed by job titles that add specificity on the type of test activity occurring; security analyst, performance engineer, usability analyst, etc. Certainly these activities require specialist skill. But in deploying someone in to a project specifically to test one aspect of the application, you give them permission to ignore all others. Mandated inattentional blindness; count those passes!

All of these specialists will interact with the application in creative ways, which may result in execution of different functionality. If the tester is looking specifically at how fast the application responds or how usable the interface is, they may miss functional issues that their activities reveal. And even if they do see something strange, often these specialists are given little opportunity to understand how the application should behave, so they may not even understand that what they observe is a problem.

Barriers to collaboration

At CITCON in Sydney earlier this year, Jeff challenged us to think about whether we are truly collaborative in our agile teams; particularly across the traditional boundaries of developer, tester, operations and management. People rarely question the thinking of team members outside their role, because titles give people ownership of a particular aspect of the project. The challenge to establishing collaboration is in changing the professional identity of these people from the individual focus to the collective.

At the same conference, Rene shared a story about a team deployed to resolve high priority production issues. They were known as ‘the red team’ and included people from multiple professional disciplines; development, testing, etc. This team was focused on finding a solution and their collaboration was excellent. When asked about their role in the organisation, members of this team would proudly identify as being “on the red team”. This is a shift from how people usually identify themselves, by claiming a role within a group; “I’m a test analyst on Project Z”.

Testing is testing

Our challenge is to take the change in identity that occurs in this single focus, high pressure situation and apply it to our testing teams. By populating a team with people who have different skills, but asking them to think together, we can achieve better collaboration and create testers who have a broader skill set.

An engineer should not be permitted to build a fortress of checks that is indecipherable to other testers in the team. Analysts should be interrogating what is being coded, offering suggestions on what is included and demanding transparency in reporting. Similarly an analyst should not be allowed to befuddle with analysis and bamboozle with metrics without an engineer calling their purpose and statistics to account. Performance, security and usability specialists will all benefit from exposure to a broader set of interactions with the application, so that they can help the team by identifying issues they observe that our outside their traditional remit. Challenging each other allows transfer of knowledge, making us all better testers.

Titles acknowledge that we are different and that we have strengths in a particular area. But we should all try to identify as being part of a testing team rather than claiming an individual role within it. We should not allow a label to prevent us from delivering a good testing outcome to our client. We should not allow our titles to silo our thinking.