Post Made Community Wiki by Craig
2 deleted 4 characters in body
source | link

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 you'llto 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.

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 you'll 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.

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.

1
source | link

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 you'll 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.