That title is not the beginning of joke, although it certainly could be. Rather, it’s meant to touch upon the idea that testers and developers – often considered polar opposites in the tech world - will one day be the same. In other words, someday, all testers will be developers and vice versa. Sounds crazy, right?
According to a recent guest post, that’s where we’re headed. Here is the quote that got me thinking:
Software testing has been on a path toward convergence with programming for some time, especially when it comes to test automation. At the same time, many vendors have tried to create tools that allow non-programmers to exercise code in ways they would not know how to do by themselves. It’s surprising how slowly this discipline has evolved over the last two decades – often because it has all the overhead of code maintenance without any associated direct revenue. And yet, the benefits of having well-maintained automated tests in a continuous integration environment can’t be understated. At the same time, software testers provide much-needed input and perspective from exploratory testing and user acceptance testing. In my opinion, nothing can replace the “human perspective” as part of the quality assurance cycle.
Anyway, I started this post with the intent of highlighting the many glaring differences between testers and developers. No way could these two professions converge like I this, I thought. But after awhile, I started to think differently: They are more alike than I ever imagined. Take for the example the following traits of successful developers. Except for the sake of illustration, I’ve replaced the word “developer” with “tester.”
#1: Curiosity
Great [testers] never accept things “as is”; they need to poke deep inside something, even when it appears to be working fine, to learn more. This is how many problems are solved before they are problems, and it’s usually the quickest way to fix acute issues. A [tester] without this mentality will usually end up lacking the knowledge underlying why they are doing what they are doing, which means they’re working with blinders on. Unless candidates are very shy, their curiosity, if they have it, will show strongly during interviews.
#2: Clear thinking skills
It may sound obvious, but [testing] is an exercise in logic. People who can add 2 and 2 to get 4 are common, but people who can take “2 + x = 4″ and figure out that “x” is equal to 2 are much less common. This is why I have always preferred [testers] with strong math or science backgrounds. It makes them a bit better at [testing], but more important, it generally indicates good logic skills. When I discuss the job, I sometimes leave blanks in what I’m saying to see if the candidate can fill them in. In addition, if your hiring process includes formal testing, that’s a good time to test logic skills.
#3: Top flight reading speed and comprehension
Another “duh” when it comes to [tester] productivity is that most of their work is not the [testing] of the code. A significant portion of a [tester's] day is spent reading, whether it be other people’s code, Web sites with examples, documentation, or project specs. [Testers] who read slowly, or worse, don’t understand what they’re reading, will be inefficient at best, and dangerous at worst. You probably don’t want someone on staff who misreads the spec and spends three weeks doing the wrong thing; that’s just embarrassing when you need to explain the delay to the project sponsors. It’s really hard to gauge reading skills during the hiring process unless you use a formal testing process.
#4: Attention to detail
Attention to detail is a close cousin to curiosity. A [tester] who pays attention to detail will be significantly more productive than one who doesn’t, all else being equal. It is, unfortunately, extremely difficult to measure this quality during the hiring process. Still, sometimes things happen during the hiring process that show that a candidate has this trait. Maybe it’s a casual remark or just a minor incident that occurs during the interview.
#5: Quick learner outside of [testing]
Unless your company develops programming tools, like compilers and IDEs, your [testers] are working with projects outside the realm of [testing]. Just as journalists need to understand a little bit about the subjects of their stories and good teachers need a working knowledge of the field they’re teaching, good [testers] are able to learn about the environment their software will work within. Of course, you don’t need a CPA with a computer science degree to work on your accounting software, but a programmer who can’t understand the basics of the math and business rules involved is going to be a liability.
*******
So maybe testers and developers aren’t so different after all? Or maybe they are – you tell me. As testers, what do you consider to be the biggest difference between you and your developer colleagues? Be sure to let us know in the comments section.