In the current business environment, companies are looking for ways to run leaner and meaner, and sometimes this means some people are working multiple roles. The line between Developer and Tester has been thin in the past and nowadays the line is even thinner. It’s not uncommon for an applicant to show up for an interview of what appears to be a QA job and get tested on how much Java they know.  Historically, QA and testing work has been one path in to development and since automation work is a mini development project of its own, it’s easy to see how companies are blurring the lines even more these days.

The fact is, though, there is a difference between developers and testers, especially in how they approach a project and how they think about a project. Assuming a project starts with good requirements, a good developer will look at those requirements and start to think of how they would build the code and the functionality to meet them. A good tester, on the other hand, starts to think about the questions the requirements don’t answer, the “what if the user does this?” scenarios. A developer tends to look at the “happy path” of the code when testing it, and it’s easier for them to miss issues because they build the code based on what they expect to happen next. A tester tends to be more contrarian, watching for the unexpected—and trying to make the unexpected happen.

Generally we tend to be more suited to one role or the other, but there is some role crossover. A good developer needs to be able to test their work to a certain extent, and it helps a good tester to be able read code and step through it to find and debug an issue. It is pretty rare to find a really good developer who is also a really good tester. It happens, but it’s the exception, not the rule. Both roles are critical to a quality software project and it is important to make sure your project team has strengths in both roles.