What’s the Difference Between Testers and Developers?

yin_yang3That 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.

Essential Guide to Mobile App Testing

Comments

  1. says

    Thanks for all your labor on this website. My niece takes pleasure
    in carrying out investigation and it’s really easy to see why. Most people hear all relating to the powerful mode you create precious solutions via your website and as well as cause response from some other people about this matter while my princess has always been studying a lot. Enjoy the remaining portion of the year. You are performing a glorious job.

  2. Bryan Fisk says

    The “developers make / testers break” answer to ‘what does a tester do’ is gives the wrong focus of doing testing.

    Testers that focus on breaking a solution miss the point.

    There will always be something that can be found to be deficient in a solution if you try hard enough.
    Finding the important deficiencies is the key to giving value to having a tester.

    And by ‘important deficiencies’ I mean what the client thinks is important – not the developer; nor the tester.

    So …

    Developers TRY to develop a solution that does what they think the client wants.
    Developers SHOULD test their solution to ensure it actually does what they think it is supposed to do.

    Testers TRY to ensure that the solution does what the client actually wants and/or what the client will accept as a solution to their needs.

    Developer and Testers are similar in that they are looking to provide a client with value. Both test the solution – both have different view points as to what is value to the client. It is this different in view that finds defects worth the client’s money.

  3. says

    Hmm it seems like your website ate my first comment (it was
    super long) so I guess I’ll just sum it up what I had written and say, I’m thoroughly
    enjoying your blog. I as well am an aspiring blog writer but I’m still new to the whole thing. Do you have any points for inexperienced blog writers? I’d certainly appreciate it.

  4. says

    Nice explanation given on difference between developers and testers.Basically developers develop the code whereas testers try to break the code and find the loop hole in the applications developed.I think this helps in developing the quality products that is a flawless products.

  5. says

    Unless you’re using home grown stuff, you’re probably putting hundreds of chemicals into your body that can quite possibly lead to marijuana dispensary merchant account
    addictiveness becoming a real issue for you. It may have some medicinal
    benefits for certain individuals and may
    be permitted in your state, but don’t expose yourself to this drug. You can expect a sedative stone when using indica merchant account for medicinal marijuana dispensary.

  6. says

    If you find a consultant that’s affiliated with one or only a couple merchant service providers, or if one provider compensates them significantly more than others, there’s a
    good chance that they’ll be biased. Look for merchant account providers who provide go a step above the rest, providing valuable information and resources. Opening Google Accounts for Checkout – Before you can create Google Checkout sandbox and production environments, you need to open three new Google accounts as follows:.

  7. Warren says

    Testers that can develop and vice-versa eliminates a potential bottle-neck, or risk. I do not agree that testers try to break code. That mentality helps create an adversarial relationship between two group that need to have a good working rapport. Testers try to help developers create and produce the best product they possibly can.

    Also, as far as reading comprehension goes, if the requirements are clear, unambiguous, address one issue, traceable, and repeatable – to name a few characteristcs – there should be no issue with reader comprehension.

Leave a Reply

Your email address will not be published. Required fields are marked *