Hi

What's the Difference Between Testers and Developers?

#1: Curiosity

#2: Clear thinking skills

#3: Top flight reading speed and comprehension

#4: Attention to detail

#5: Quick learner outside of [testing]

See:

https://www.utest.com/articles/whats-the-difference-between-testers-and-developers

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

In simple words, developer is the one design and develop the software. He can do coding and some level of testing also. But generally developer do valid testing only. On the other hand tester is the person doesn't know how the software been developed and who did the development. His primary role is to as much invalid testing as there might be. Software had been released only if tester gives the clearance or pass certificate. There are many testing tools also available. But the quality of the final version majorly depends on how the tester performs the testing.

Hi

What's the Difference Between Testers and Developers?

#1: Curiosity

#2: Clear thinking skills

#3: Top flight reading speed and comprehension

#4: Attention to detail

#5: Quick learner outside of [testing]

See:

https://www.utest.com/articles/whats-the-difference-between-testers-and-developers

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