Previously I had talked about valuing the “modern” tester as well as a possible defocusing of test practices. What a lot of these kinds of discussions swirl around is how much, and to what extent, testers are generalists or specialists. So let’s talk about that a bit.
Robert Heinlein had a famous quote that most people in the software development and testing profession have heard at one point or another:
“A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.”
It sounds clever but what really stuck with me was something I read on Sean Carroll’s The Particle at the End of the Universe, where he says this:
“In the specialized world of modern science, the roles of ‘experimentalists’ and ‘theorists’ have become quite distinct, especially in particle physics. Gone are the days — as recent as the first half of the twentieth century — when a genius like Italian physicist Enrico Fermi could propose a new theory of the weak interactions, then turn around and guide the construction of the first self-sustained artificial nuclear chain reaction. Today, particle theorists scribble equations on blackboards, which ultimately become specific models, which are tested by experimentalists who gather data from exquisitely precise machines. The best theorists keep close tabs on experiments and vice versa, but no one person is a master of both.”
The “no one is a master of both” comment is what interested me because, often, in this industry we see expectations about people “mastering” both development and testing. Maybe even a little business analysis as well, if they can fit it in. Not to mention good design practices as well as some UX knowledge. And so on. And so forth. Much like how the roles of experimentalists and theorists had to part ways a bit, I do believe there is benefit in the tester not having the same specialist skills as a developer.
I do understand why developers have had to specialize in many cases. If you are writing enterprise application software in Java, a developer who has heavily focused his career on the Java ecosystem (i.e., the JVM and supporting technologies) is likely going to bring a broader array of abilities within that specialization. This is as opposed, perhaps, to the developer who has dabbled in lots of languages to different degrees.
Couldn’t someone claim the same for testers?
In my view, the notion of the “technical Test Engineer (TE)” (Microsoft), the SDET (popularized most famously, but not exclusively, by Google) have done much, in my opinion, to harm the industry. This is part of what has led to the back and forth about approaches like TDD, BDD, ATDD and then the inevitable backlash against those approaches and then the numerous claims of how those who misunderstand it all are simply “doing it wrong.” This has led to companies hiring “test engineers” who must have, say, Java (or whatever language) but are excluded if they don’t have that particular language, but they do have many others.
The problem, at least in broad terms, is the conflation of testing activities with development activities. Yes, there is some overlap and I do agree that we want developers to have some testing knowledge just as we want some testers to have programming knowledge. But testers, particularly those that automate, aren’t building the product. They are in effect building a test service that consumes the product, exercises the product, and communicates findings in a way that various audiences can understand. For testers it is thus, by definition, not all about the code. And that’s even moreso the case when the testers focus on automation.
A Generalist Who Specializes
In the context of testing in particular, my view is that most companies need to be looking for the generalist who can specialize to a certain extent. But that generalist also is someone who can demonstrate and breadth and depth of experience in investigation, curiosity, and innovation across a broad array of topics, some of which have led them to explore and practice with development related activities.
This is much, much harder to interview for and that’s probably why so few places do it well, assuming they attempt it at all.
What does it mean practically, though? Well, I talked about interviewing “technical” testers already so I don’t want to repeat that here. What I will say is this: when I’ve been on the hiring side of the desk, I’m looking for someone who can deal with change and someone who can initiate responsible change. Change is the most important factor there. The only thing we know with reasonably certainty is that change will be faster. Knowledge doubles every two to three years. That means much of the knowledge you have now is becoming obsolete.
This leads to an interesting point: you have to update your knowledge and information at the same or a greater rate than that at which the knowledge is becoming obsolete. Otherwise you fall behind.
Now consider that technology multiplies times itself. Each time a new piece of technology is invented, it creates more opportunities and possibilities for the invention of more technology. Combine that with the knowledge rate and you have a serious recipe for continuous change. And that requires continuous learning.
But that also means you are not going to be the master or the expert at all times in all things.
A Sustainable Strategy of Generalization
Jack Welch said that if the rate of change outside of you, or your organization, is greater than the rate of change inside, the end is in sight. If you’re not moving at the rate of change, or slightly ahead of it, you’re probably in trouble. Knowledge and know-how are critical not just for success but also survival. Continuous learning is the only sustainable source of competitive advantage. In the business context, this means you have to learn and apply new techniques and skills faster than your competitors.
In the testing world, this means you have to learn a broad array of testing skills and how to implement them in a variety of possible test tools that run under a variety of different programming languages. All the while making sure that you can align business communication with developers so that the tests are an accurate reflection of the business domain and an accurate execution model for the programmatic implementation.
The problem there, of course, is that the pile marked “things to learn” will grow beyond our ability to cope with it. Everything is in flux. This requires us to constantly read, study, learn and evaluate. None of us will ever master all the aspects of the discipline that we’d like. I can tell you that nobody I know is managing this weight of information any better than you. That said, the smartest folks look at it more positively, learning to embrace this flux, and manipulate it as best they can.
This gets into the distinctions people make between terms like “proficient”, “expertise”, “mastery”, etc. I’m fine with people using those words on their resumes for the most part. Regardless of what words someone uses to describe their abilities, I’m looking for how you utilize those abilities.
You have to be a person that picks the right problem to solve. You have to pick the right way to solve it. You need to know when to revise that plan, and understand the constraints that inform that revision. You need both large scale and small scale intuitions. And you need to be at least good enough at the details of programming or testing in that environment that you don’t get overwhelmed with the “easy” stuff, so you have mental energy to spare on the big stuff.
The Modern Generalist
There is a difference between a “generalist” that can do many things (if directed) versus the more valuable and modern definition of “generalist” that can drive initiatives around many different business areas, has the empathy and perspective to understand what multiple business functional areas affected are really dealing with and want/need, and guide others to outcomes no matter what the org chart around them happens to be.
That’s critical for testers, and most certainly quality assurance, because their domain touches more than just programmatic elements. It touches the domain of the business analysts as well as the designers and developers. It involves discussion of high-level concepts in natural human language and low-level details of programmatic code.
What the most effective generalists often bring is a broad range of skills, with perhaps a few deep experience areas. Further, the effective generalist has a feedback loop between the broad skill and experience areas, such that both consistently inform each other of possible approaches to take given the context at hand.
That is what I’m looking for in a tester. If I happen to find someone that can truly claim “expertise” or “mastery” of some approach, technique, or tool solution, then fine. Great. Love it. But only if that vaunted knowledge sphere has not come at the expense of being able to think around and outside of that sphere. And most certainly not if that knowledge of tech and tools has come at the expense of learning how to communicate and collaborate at different levels of abstraction.