Why don't testers and programmers like each other? [closed]

Question

During my career as a programmer I've seen various programmers and testers, and many of them didn't/don't like each other. I mean, programmers think that the job of a tester is not a "real" job, and testers think that programmers are too "proud".

Is this the right decision made by me, why is it, and what can we do to avoid these kind problems?

Answer 1

I think that's a gross over generalization and over simplification.

I'm currently a tester, I write almost as much code as I wrote as a dev (depends on the test phase) and my best friend in the company is a dev and we all get along.

You might want to take a look at the corporate culture and the way in which the teams work with respect to eachother to find your answer. In my experience, if you have very reactionary workflows (ie. devs "throws a build over the wall to test" and test "throws bugs back") instead of working together, just from different focus points or "attack vectors" then you'll find that both departments in general, will dislike eachother.

Where I work, every feature team or design team has nearly as many testers as devs working together to produce output. That output is production code that meets the requirements set forth by the test code.

edit

Also note, that I think the onus is on the tester more than the dev to support the relationship between the two.

It's much easier for us to make the lives of dev better or worse, but the goal is to not simply "find bugs" but also to find potential solutions. If I can't, then I can't, and I will work with whomever gets assigned the bug at that point to find a solution. But if it's a simple solution then I'll provide what I believe to be a potential fix that would satisfy the various requirements and the eventual regression test that I'll write.

Answer 2

I LOVE my testers - they help me troubleshoot and spot things that I wouldn't think of as a problem, but our customers would. And most important to me, they help me make sure I don't kill someone with bad code.

Why do problems pop up?

• You are constantly judging each others work, and some people can't take any kind of critism
• Doing a bad job wastes your opposite's time
• You are both under pressure, at the same time, for the same thing and no one wants to be the one holding things up

The combination of the above along with the nature of the positions means it's really easy to take your current angers and frustrations out on each other, if you fall into that trap you stop working together and start working against each other. That's hard to break out of and it's not good for anyone.

Answer 3

I would guess it happens beause the programmers create a program, and they perceive that the testers then try to find flaws in it (even though the testers are actually a part of improving the final product). Whenever someone finds flaws in something you put lots of effort in, it's probably a natural reaction to react negatively towards them.

Ways to mitigate this would be to make the developers and testers view the finished product as the output of the whole team (including testers AND developers) and make them understand that testing is not a stand-alone fault-finding mission but an important part of the development process. And if the developers don't think testing is a real job, or that it's easy, have them write the test matrices, execute hundreds of test cases, document every single step and every single result.

Answer 4

I know of particular programmers and particular testers who don't like each other, but not for the reasons you stated but rather because they make work for each other.

It's the nature of the beast. Some of the particular testers I know of who didn't care for particular programmers because they felt their code was prone to errors through carelessness/laziness/etc. Some of the particular coders I know who didn't care for particular testers felt they used ridiculously contrived test conditions (picking nits) or would request revisions to code based on style.

I think keeping personalities out of it, and focusing on the task at hand goes a long way to reducing tensions. If an organization is large enough, double blind testing is a great idea.

A tester who can clearly express problems, and coders who clearly implement solutions are a great team.

Answer 5

In teams where I've worked closely with the testers, we've gotten along fantastically. Testers understand the decisions that went into various decisions made, they know what the dev's schedules are like, and a rapport is built between the two groups.

In teams where test is some amorphous entity offshore, this has not been the case. The testers' results are less relevant because they don't know as much about what's going on, the devs begin to dread the flood of what they consider to be inconsequential details that are in parts of the program that haven't been touched in two months, the test team gets annoyed that none of the filed bugs are being fixed (because the schedule is screwed up and the devs are busy getting ready for demos or adding requested features, etc), and in general both groups see each other as antagonistic "others" as opposed to team members.

Work closely and things will be fine. Somebody needs to make sure both teams are coordinated and on the same page. My best experience, the test team was invited to any high level meeting the dev team was invited to (all of them) and we all knew the schedule, we had a unified priority list, and devs and test both had the same (up-to-date) requirements document. My worst experience (other than no test) we basically packaged up our stuff, shipped it overseas to be looked at, then got everything back a month later with things marked as wrong that weren't even ours (3rd party plugin that met the new requirements, but not the test team's expectations).

Neither dev or test will succeed without the other. If you work like two halves of the same machine and respect the other side as much as you respect your more immediate team members, things will be fine. Behave like two separate machines and assume your machine is better, things will be terrible.

Answer 6

When programmers and testers don't like each other, often it's because they mistakenly imagine that their goals conflict.

Answer 7

I've found that these issues are greatly mitigated when testers and developers are on the same team, rather than a "test team" and a "development team". I think this is why, as a tester, I strongly prefer to work on Agile teams rather than waterfall development. There is more communication, turn-around is faster, and developers have a greater appreciation for the time and talent that go into testing when that work is more transparent.

Individually, there is a lot that can be done as well. As a tester, I find I am able to reduce this friction by providing positive feedback as well as finding bugs. I have yet to test for a dev who couldn't teach me a lot, and I find developers appreciate a tester who really works to understand the code. Developers are proud, like any good craftsman. It's important to let them know that having bugs doesn't make them less admirable

The developers I've found easiest to work with appreciated good quality, and demonstrated it by making an effort to write high-quality code before the tester saw it, including doing preliminary testing (mainly automated unit testing and manual smoke testing). These devs also asked test to do code reviews for testability, and included testers in the process as soon as possible, including presenting designs to them early on (which lets testers start planning test strategies early, when test has a lighter load). Developers can help testers find weak areas in their code by telling them what areas were developed in a rush, or what areas were difficult to unit test. In general, anything developers can do to make a tester's job easier is appreciated, and shows that they value the tester's time as well as their own. When developers do this, a single tester can easily cover multiple developer's work (right now, I test for 4 devs, and work little to no overtime to do this).

Answer 8

Another problem is that QA is often an after thought by many companies. A lot of times it is told about projects at the last minute and is grossly understaffed compared to the development team. At some places the path to developer is tech support, QA, and then a developer. So sometimes it is staffed with people who wish they were developers... And then when they find a defect their attitude is how can that person be a developer and not me I would never make such an error, etc...

Overall I would love a QA team. Also I think too that unit testing should be a necessary part of software development separate from QA. So as QA finds bugs, the unit tests are changed to test for that. Additionally I think developers who unit test can better understand what QA is finding.

Additionally many QA teams have to do things manually, in which case it is a REALLY boring job. In some places QA writes scripts and uses automation programs that even allow scripting GUIs (through some sort of image recognition on the screen for buttons/etc.). Then it's still tough when major changes happen at first, but then everything is automated and it seems more fun...

Also some developers look down on QA. Still I'd much rather QA find a defect than the customer....

Answer 9

We love our testers here, but then many of us remember what it was like before we had them. It is oh so much better to have testers find problems than to have the client find them after you have gone to production. There is not a developer alive who hasn't created a bug or misinterpreted a requirement.

The key is to treat all professionals with politeness and respect whether they do what you do or not. Once you start thinking your job is better or more important than theirs then you have lost.

Based on this question: Software Testing Techniques I suspect you need an attitude adjustment towards testers and testing in general.

Answer 10

As a developer, I've experienced my share of tension with testers.

In one job, the testers would seldom be testing the "right thing". I'd implement a new feature for our product's server, and the testers would report a whole heap of errors about the user interface. Since, in that product, the user interface was configured not coded, the presence (or not) of problems in our development UI had absolutely no link to whether end users would have a UI with similar issues. The testers knew this, yet persisted in logging bugs about extraneous areas.

That said, good testers are worth their weight in gold - I'd trade a lousy developer for a good tester in an instant. A good tester is a partner in delivering a quality product.

I've also known some developers who treat the testers as the enemy - as though the testers are introducing the faults. It's important for developers to realise that testers never introduce the fault - they just uncover it.

Answer 11

How to avoid these problems? How about being nice to each other? One needs the other in order to get a quality software application out, so why not respect what each side needs to do in order to accomplish this? Get to know what each side does and you might actually appreciate the work involved.

Answer 12

Stubbornness on both sides of what is the correct interpretation of a requirement would be where I've tended to see the conflict between developers and testers generally. While there may be an appearance of snobbery or arrogance, it is just that each side sticks to their guns and wants to be right.

A good way to avoid this problem is to have 3 parties, the developer, the tester and some mediator either a business analyst or project manager work through how should various boundary cases be handled. Something to consider is what kind of egos may arise when there is a disagreement between developers and testers.

Answer 13

Bad feeling is usually the result of bad communication, which is usually the result of the programmers and the testers having different perspectives of the code. The programmer knows the bits he's been working on intimately, but may not know how they fit into the overall system (beyond what the specification tells him). Testers see the big picture, but don't know the code in detail. The groups may use different terminology and procedures for the same things.

This can lead to defects being filed against the wrong component (because the component is responding to a failure upstream), or developers closing legitimate defects because they can't reproduce the problem in their environment (because they don't really understand how to reproduce the problem correctly). If this happens a lot, it can strain relations between the groups.

Then there's the joy of getting a batch of defects at the 11th hour; deadlines are looming, pressure's coming at you from your immediate manager on up the chain, and you get a fresh batch of defects on a problem you know you've fixed already and you really don't want to have to take the time to go through the process to prove it.

One really good way to piss off your QA team is to summarily close several hundred legitimate but low-priority defects (mainly filed against ugly or inconsistent UIs that were otherwise functional) with the reasoning that your higher-priority defect backlog is so large that "we'll never get to those." You go from red to green on the program manager's spreadsheet and get an attaboy from higher management, while the QA team takes a hit on their metrics for filing a bunch of bogus defects.

Bad juju.

Answer 14

I think if this is really the case, it's a sign of immaturity. Sometimes you might talk about it as a joke. But if you (developers and testers working on the same project) don't feel like a team, the outcome would be a disaster.

Testing is a pretty important part of the software development life cycle ( be it agile or not). So you shouldn't be thinking of testers as people who live to bother you with bugs, but rather as a team mate that helps you ship quality software.

Answer 15

This often arises from three factors -

• Questions like these point to the existence of a 'folklore' in the industry that developers and testers don't like each other. People try to find aspects that reinforce this, even when such a feeling might not exist in their team.
• Incompetent project managers measuring progress by metrics like the number of bugs logged.
• A dysfunctional team (and a lack of leaders who care to enough to fix it).

Answer 16

I like testers, but two cases I have found conflict.

1. When management play testers and devs off each other.

2. When issues are constantly submitted that lack detail, ie "Screen x doesn't work".