I believe there’s an interesting parallax effect that happens in conversations around testing and the implementation of testing ideas. This is an area I want to investigate a bit more so I’ll start off as I usually do: with my half-formed ideas as the basis for discussion, elaboration and possible refutation. In his book Surpassing Wonder, Donald Akenson says:

“We are now where we can pinpoint the major difficulty in reading the Hebrew scriptures: such reading almost inevitably suffers from a major parallax effect. The nature of the documents makes it easy to read them from a misleading angle. An apparent displacement of the religious history we are observing occurs because of the misaligned position we assume when we view it. Things seem to be where they aren’t. The difficulty is entirely one of historical perspective.”

The parallax he refers to here is that much of the narrative of the Hebrew scriptures was likely put in place from 587 to 330 BCE, not before that time. Yet the vast majority of that narrative describes events well before that time. So we get a parallax effect when we read, essentially treating the time the books talk about and the time the books were written as the same — when, in fact, they were not. That parallax can fundamentally alter how we choose to interpret the texts, what we come to believe about the authors and the time they lived in, the reasons we might imagine for why the texts were written, and so forth.

Expensive Construction

So now let’s take a somewhat obvious example of this in software development. There really is no “expensive construction phase,” as some still like to think. The construction itself is very cheap. Essentially running the compiler and/or the build process. In fact, there’s only an expensive, design phase. That’s where the inefficiencies creep in. But the reason this viewpoint was so prevalent for so long is because we got a type of parallax. Since coding is one of the things that makes the ideas manifest, we treat flaws in the design process as flaws in the construction process.

The Checking Distinction

Here’s another example that I believe is accurate, but I’m still investigating my thinking on this. The “checking” distinction that some testers like to adhere to seems to be necessary to them because they feel that it has to do with how the industry is conflating “testing” with tools. However, if you look a bit deeper, that’s often not the case. That’s the parallax. The problem manifests, ultimately, as or during the use of the tools so that’s where our eye is drawn and then people talk about “checking” for what the tool does but “testing” for what the human does. But, again, that’s not the problem. Which is why, I believe, this distinction — in place since 2009 — has done nothing appreciable industry-wise. The problem being dealt with is much more fundamental: it’s a disconnect about testing itself, regardless of the use of tools.

The Behavior Distinction

Consider BDD. Many BDD pundits — including its creator, Dan North — will tell you that the approach replaced the word ‘test’ with ‘behavior’ because apparently it was too difficult to get people to think in terms of tests. Even though it’s really not that hard. The idea of “testing” is something that is hard-wired into the human brain due to its evolution. But that was a parallax effect. It was just that the problems in thinking manifested the most when they dealt with testing primarily as an execution activity. What they didn’t apparently do is consider testing as a design activity. This is perhaps a bit odd because BDD is an outgrowth of TDD which absolutely does think of testing as a design activity and did not feel the need to replace the word ‘test’. The fact is, from my perspective, tests demonstrate behavior. Tests elaborate behavior. Tests clarify behavior. Behavior is how something is; tests are a process of discovering various ways that something was (history), is (present) or can be (future). Tests are about investigation, exploration, and experimentation. What BDD pundits should have been doing was using tests as being a way to think more broadly about behavior. Instead, they saw it as an impediment and had to do a name change. And that was due to the parallax.

The Point?

The point is this: consider the many misunderstandings you’ve seen about testing. Think about how you needed people to understanding testing at a better, more substantive level. Think about those posts or articles or conversations where it was clear to you that testing, as a practice and discipline, was largely being dismissed. Or if not the practice and discipline, the very idea of a tester role was being dismissed. Are you thinking about those? Okay, now in those cases, let’s say you responded with arguments around “expensive construction”, or “testing vs checking”, or “it’s behavior, not tests.” Would that have really made any sort of substantive difference in the perception problems you were hearing? Would those responses have changed minds? Expanded horizons? In my experience, not at all. And while my experience is just one data point, we have an entire industry we can look at that has often marginalized, conflated, or done away with specialist testing.

The Parallax Effect is Real

The reason these distinctions don’t help in the grander scheme, I believe, is because of the parallax effect: it’s looking where something isn’t. It’s solving a problem that you think is there because of where it manifests but not where it actually is. This is why, in my opinion, approaches like BDD — promoted since 2006 — keep getting conflated with tools like Cucumber or structuring languages like Gherkin. It’s why “checking” — promoted since 2009 — has done nothing to foster better discussions with developers and business and it’s arguable if it’s even fostered better discussions among testers. The only area that we’ve made some progress in among the three I’ve mentioned is the expensive construction phase idea — and that’s mostly been by developers taking a better look at testing, particularly in its design-based form. Testers have had practically no role in the emergence of ideas like Agile, test-driven development, putting pressure on design, and so on. Testers have also had little impact on the development of practical approaches based on those ideas, like contract tests, property tests, in-process component tests, persistence integration tests, and so forth. And when testers finally caught up, their value is still questioned because they were, after all, late to the game. And often aren’t (perceived as) offering much now that they are finally in the game. That, to me, is just another example of parallax: testers looking at the wrongs things at the wrong times, until others provided them with the approaches, the terminology, and the tooling.

The Parallax is Forcing Evolution

I believe in this parallax effect. We see it in perceptions of testing, including in widespread hiring disparities compared to other roles. We see it as a belief that testers do so little that is uniquely human, that companies feel they can rely on automation for what testers do and leave the human parts to business and developers. I believe this parallax effect is magnifying and being amplified as the industry evolves. I further believe that testers need to do some evolving as well. And the specialists among us need to be directing that evolution, rather than having it dictated to us.