One of the things that testers in my classes on ATDD and Exploratory Testing struggle the most with is that programmers and testers appear to give up independence with this approach. My first reaction to this is often that I hear them asking to leave their testing silos in place, and start to convince them to collaborate more with the programmers. By hard I recently learned that the Helpful Model (“No matter how it looks, everyone is trying to be helpful.” Secrets of Consulting, page 101) and the Rule of Three Interpretations (“If I can’t think of at least three different interpretations of what I received, I haven’t thought enough about what it might mean.”, Quality Software Management Volume 2 First-order measurement, page 90) also applies to myself.

Let’s take a look at the problem first. For the past decades testers and programmers were taught to work independently from each other. If the tester knew the source code, then he would be spoiled. A tester who read and understood the code would suffer from Confirmation Bias – the deer belief that the code works. Even more if the programmer and tester start to interact with each other they build up a relation, and the tester can get biased by that same relationship.

This at least is a fear that circulates in tester circles. At some companies this fear goes as far as that no tester is allowed to speak to any programmer. Another extreme is to outsource testing completely to an independent company. These companies sometimes don’t even know the product, the service or even the customer. According to WikiPedia this requires a strong coordination with them.

Now, what happened in a recent class was that testers told me that they were used to poor requirements documents. If they had these at all, the documentation was in such a poor state that it was useless for their work. Over the past decade they had stood up from their desk and went over to the programmers to ask clarifying questions. “How did you implement this?” “How did you deal with this ambiguity?” had been phrases in their language for their daily work – even before any Agile adoption.

But then something bad must have happened, I hear you asking. No, they were completely used to collaboration. When I taught them about Exploratory Testing and Specification by Example the concepts were nothing new to them. Over the past ten to fifteen years they had found their natural way of collaborating with programmers. The impressive thing for me was that this company made the impression from the outside that they were using a highly stage-gated process with signed-off gates. I was amazed to find a testing team in that larger organization that was used to close collaboration.

Regarding Confirmation Bias, I think this has become a rule that is strongly followed without understanding the applicability and the context for the rule to follow. This often leads to teams following the rule of silo-thinking without understanding when and why to follow this rule.

As being taught by Jerry Weinberg in Becoming a Technical Leader I think we should start to transform this rule to a guide. I would like to kick off the discussion about this with the question if we should always separate testers from programmers? Are there circumstances where this separation doesn’t make sense?

One answer to this question is a cross-functional team. In a cross-functional team separating testers from programmers would take valuable feedback off from the team. Another setting would be a team consisting only of programmers. I visited a client in November who had no tester at all. These programmers were peer-testing each other’s code.

This brings me to the consideration what we could do in situations where a separation is not good. Part of Agile software development is a regular retrospective over the course of the development process in place. Given a team finds out that it has been flawed from confirmation bias resulting in code shipped that shouldn’t have been shipped, this will become the main theme in a retrospective. At this point the team will decide how to deal with this problem in the future. I have yet to see a team that will ask for a separation of testers and programmers in this case.

In brief, I think the demand for separating programming and testing to the degree that no one is allowed to talk to the other is the worst thing our industry has come up with so far. Even worse is the degree this sticks in the thinking of testers and managers around. Nearly all of the high-performing teams I have seen have abandoned this demand in first place – and they did this for the better.