There is a distinction between “being a programmer” and “being a developer.” Yet those two terms get conflated in our industry quite a bit. The idea of a tester also gets conflated with … which? Programmer or Developer? That very much depends. Combine what I just said with the idea that many testers feel that DevOps has caused a decline in testing. Is there a correlation there? And should testers become developers? Let’s talk about this.

There has been a needed evolution in testing. However, far from any sort of decline, it’s something specialist testers can use to propel their career. But it does require us realizing that the term “developer” has, for too long, been an overly restrictive term. Certainly when it comes to testing.

So what I want to talk about here is a world where “Developer” is a broader term than it is now; one that includes specialist testers that are not enterprise developers. Everyone in this group has some foundational practice in programming. Everyone in this group has some foundational practice in testing. But there is still room for specialists that have particular skills and particular areas of activity.

Testers Get Lost in the Forces

I talked about project forces before and this is definitely an area where testers must have some understanding of the tensions of these forces. Those tensions impact external and internal qualities. As such, if you are poised — with your skill-set and mind-set — to help with these tensions, your career is in a potentially very good place.

Let’s consider an example of these forces in actions.

Project Forces Providing Tension

The business team wants to justify what they are doing. What does that mean? Ultimately they want profit. Why? Because profit is a great indicator that what the business is providing is what the market wants. Profit comes from what? Delivering valuable features to customers. And where do those valuable features come from? Developers have to create them.

Developers want to justify what they are doing. Developers want to provide those features. But to do that they have to understand the code they are working with and feel confident changing it. The problem there is that code often isn’t written in the best way at the start. Some of that is due to time pressure but a lot of it is just due to having to figure out what the best way is in the first place. Thus do developers, like screenwriters and fiction writers, need to edit their work periodically. That editing process is called refactoring.

So what naturally happens? The business often sees that the developers used to deliver features more quickly. But then there seems to be this slowdown overall. Or there seems to be more bugs. Sometimes both. And that’s often attributable to the fact that as everything evolves, it gets more complex. There are more interdependencies.

What I’m describing here is a force. It’s a project force. It’s a type of friction. We slow down as what we’re working on gets more complex. But there’s an opposite force in business, which is telling it to speed up. This is acceleration. Competitors are bumping into our market space. Customers are bumping into the limits of our application. These bumps force accelerations.

So we have an external project force that speeds things up and an internal project force that slows things down.

Approaches To Deal with Forces

Thus people touted approaches like Agile, Lean and various others. And now they tout DevOps. You might see a lot of testers, particularly those who have been in the discipline for awhile, speak out against DevOps as negatively impacting the testing industry. Well, I’m not here to speak out against DevOps. I like the mindset of agility and I like the DevOps movement.

But it’s very important to realize that Agile and DevOps have not really solved the above problem. One reason is that people have tended to focus on the tooling. Let’s stick with DevOps here and consider all that you might hear when it is being discussed:

• host-level monitoring (Nagios)
• configuration management (Ansible, Chef, or Puppet)
• resource isolation and resource abstraction (Docker and Apache Mesos)
• message brokering (Redis or RabbitMQ)
• messaging (Apache Kafka, Celery)
• service discovery (etcd, Consul, Hyperbahn, or ZooKeeper)
• load balancers (AWS Elastic Load Balancer, Netflix Eureka, HAProxy, Nginx)
• continuous integration, build, deploy (Jenkins, Hudson, TeamCity)

Lots of tools. But not as much on the social side of things. The dynamics of how all of this works together — a social discipline in a technology context — needs to be knitted together so that customer value can be provided via a complex system.

That kind of knitting is exactly what testing, as a communication mechanism and as a collaboration activity, can provide. This is a conversation that testers can have in a DevOps context while also having the knowledge of the tools that support the context. This should be an exciting time for testing as a discipline and specialist testers who carry out that discipline in skillful ways. Instead, you often hear doom and gloom regarding the “decline of testing” due to these very developments.

Tester? You There?

Where is the tester voice in all this?

I’m generalizing here but, in my experience, the vast majority of testers are rarely engaging with these approaches. They keep insisting on quoting Cem Kaner or James Bach or Michael Bolton or whatever other authority whose altar they worship at, generally losing more and more relevance.

Now, an important point here: that’s not a knock on Kaner, Bach, Bolton or whomever. It’s a knock on the people who simply quote them religiously as if that somehow made an argument complete or even compelling. The only people immediately swayed by those arguments are generally the ones who already believe the arguments in the first place.

Meanwhile it could be argued that the industry is moving on without tester roles and many tester career prospects are being shortened because they insist on talking about “testing vs checking” or “test case vs test scenario” when business and developers are having an entirely different conversation about how to get value to customers sooner in a way that provides competitive advantage.

And, yes, testing is a key part of making sure that this competitive advantage exists. In fact, I would argue testability is one of the key qualities of concern to all groups. But it’s critical that testers tell the right stories, engage with people about what they are going to respond to, and figure out how to leverage their technical skills in a discipline but without allowing those technical skills to subsume critical thinking, investigation, exploration, and experimentation.

Too Harsh?

Am I being harsh with some of those above comments? I don’t know. Possibly. But here’s what I do know — and this is empirical.

The industry has, for the better part of a decade (if not longer), accelerated in terms of minimizing, dismissing or conflating testing and quality assurance. We have stories that are routinely quoted about how Facebook or Twitter or Microsoft got rid of all their “QA.” We hear stories about how companies have done away with “traditional QA” or “traditional testing”– whatever that may mean — and still develop the best inventions since sliced bread. We consistently hear about how “manual testing is dying” or has one foot in the grave or, in fact, died a long time ago and no one noticed (and even fewer cared). Well! Take that, testers! That’ll teach you to pick up such a dead-end career.

Am I right?

Well, no. That’s not right. Not really.

The Tester Reframing

Testers simply have to reframe themselves a bit. Just as developers have had to do and just as operations people have had to do. The challenge is that testers often don’t. They let the industry, particularly the development industry, do that reframing for them. That’s why many of the testing discussions that the industry responds to are happening with and among developers. That’s why tooling that supports testing activities is mostly provided by developers.

A few years ago I talked before about a powerful question, regarding “What if production code were the specification?” I then talked a little about driving design in that context.

I said all that then and say it again now because I do believe testers must have a better relationship with the code and the architecture and infrastructure that supports the code. That is, in part, what DevOps is about. We might notice it wasn’t called TestOps — nor was that even really a thought at the time — and that’s because, again, testers were largely not present for these discussions.

This is not saying that testers should become enterprise developers any more than I believe developers should become specialist testers.

But, without a doubt at all, code is the one thing that we know we must have. This is something that we must create and we must release. Thus it really is the ultimate specification of behavior in that sense. But that means we — collectively, as a team — want to avoid situations that make it more difficult to reason about the code, to find the source of a mistake, or to assess the impact of a change.

That means testability!

Increasing testability tends to improve design, and in particular, helps us deliver features less expensively and with more predictable cost. That’s a key aspect of tests. Tests are telling you how to improve your design. How? By putting pressure on your design. But there’s an interesting question there: is it possible to couple our tests too tightly to our design?

That takes us into the question of feedback. It’s really the feedback from the tests that puts the pressure on the design and thus drives the design. This can be a discussion about TDD and BDD if you want it to be. As long as we “uncomplicate” those things This can be a discussion about being agile as long as we “reframe” that a bit.

But, more importantly, I think this means we must have better discussions about what “being a developer” means. We shouldn’t equate that with just “being a programmer.”

What Next?

Originally I was going to title this post “Are testers developers?” But I realize that before I can talk about that, I need to frame some of my own thinking around what a developer actually is. But the current semantic debates we all have tend to miss the mark, I feel. We debate about “testing vs checking” and we debate about a “software engineer in test (set) vs software development engineer in test (sdet).”

At the risk of a bit of hyperbole, we fiddle while Rome burns.

I want us to stop doing that. I believe that this requires reframing the notion of what a developer is. I believe that discussion will situate specialist testers as a type of developer. And I firmly believe that if we can get to that point in the industry, so many of our unproductive or counter-productive discussions will be refocused along some common sight lines.