Comments on: Sleeping With The “Enemy” http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/ Lidor Wyssocky's Blog on Optimizing Software Development Wed, 19 Nov 2008 04:03:42 +0000 http://wordpress.org/?v=1.5.2 Comment on Sleeping With The “Enemy” by: Lidor Wyssocky http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3305 Fri, 27 Oct 2006 11:04:26 +0000 http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3305 Thanks for all your comments. Just for the record, I have seen such good relationship even when testers and developers were not part of the same team administratively. They did feel however they were working together toward a joint goal. Lidor Thanks for all your comments. Just for the record, I have seen such good relationship even when testers and developers were not part of the same team administratively. They did feel however they were working together toward a joint goal.

Lidor

]]> Comment on Sleeping With The “Enemy” by: Tim King http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3295 Thu, 26 Oct 2006 23:28:56 +0000 http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3295 I've worked in teams where developers and testers worked well together. And I'll echo MikeyK's list about teams that worked well. And add two more: * Developers looked to testers to watch their back. Not to look over their shoulder, but to bring up the rear. * Testers treated developers as the people who completed their work and gave it meaning. Developers and testers can work together, but it has to be a symbiotic, complementary relationship. That's why it's important that they be one the same team, striving for the same goal, which is high-quality software. Otherwise, it's likely to be an antoganistic relationship. -TimK I’ve worked in teams where developers and testers worked well together. And I’ll echo MikeyK’s list about teams that worked well. And add two more:

* Developers looked to testers to watch their back. Not to look over their shoulder, but to bring up the rear.

* Testers treated developers as the people who completed their work and gave it meaning.

Developers and testers can work together, but it has to be a symbiotic, complementary relationship. That’s why it’s important that they be one the same team, striving for the same goal, which is high-quality software. Otherwise, it’s likely to be an antoganistic relationship.

-TimK

]]> Comment on Sleeping With The “Enemy” by: Ryan Cooper http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3182 Mon, 23 Oct 2006 16:35:33 +0000 http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3182 MikeyK makes some great points. In particular, I find having QA and programming personel work closely together (in the same room) helps build trust, which is essential to a co-operative relationship. MikeyK makes some great points.

In particular, I find having QA and programming personel work closely together (in the same room) helps build trust, which is essential to a co-operative relationship.

]]> Comment on Sleeping With The “Enemy” by: MikeyK http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3161 Sun, 22 Oct 2006 11:59:40 +0000 http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3161 I've worked in places where QA and developers worked well together and in places where the relationship between the teams was not very good. The team that worked well together has these attributes: * Testers and Developers were part of the same team. * Close physical proximity between testers and developers: no locked doors to go through * A quick turnaround time: The infrastructure was there to enable the developer to fix and deploy quickly and tester could often restest the same day. * Developers sometimes took on testing roles when there was a high volume of testing work. Teams didn't work well together when: * QA was a separate team and didn't 'field' testers to each of the development teams. * Number of testing iterations was limited - very limited number of oppurtunities to fix and retest before shipping. * Individual developers subjected to a lot of pressure to get the software out. * QA input at the design was not sought and dev team management let the dev team build products that even if perfectly done, didn't fit the company QA guidelines. * QA was under-resourced. I’ve worked in places where QA and developers worked well together and in places where the relationship between the teams was not very good. The team that worked well together has these attributes:
* Testers and Developers were part of the same team.
* Close physical proximity between testers and developers: no locked doors to go through
* A quick turnaround time: The infrastructure was there to enable the developer to fix and deploy quickly and tester could often restest the same day.
* Developers sometimes took on testing roles when there was a high volume of testing work.

Teams didn’t work well together when:
* QA was a separate team and didn’t ‘field’ testers to each of the development teams.
* Number of testing iterations was limited - very limited number of oppurtunities to fix and retest before shipping.
* Individual developers subjected to a lot of pressure to get the software out.
* QA input at the design was not sought and dev team management let the dev team build products that even if perfectly done, didn’t fit the company QA guidelines.
* QA was under-resourced.

]]> Comment on Sleeping With The “Enemy” by: Payton http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3139 Sat, 21 Oct 2006 20:20:46 +0000 http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3139 Dead on. The goal of both testers and developers is a bug-free product. When bugs get into production code, both of them have failed. The communication must be tight. Testers should have input on a design plan review, and designers should have input on a test plan review. If there are other ways to design things that are easier to test, it might make sense to do that. If there are items missing in a test plan, a developer should make sure those are added. And finding bugs during development isn't a shaming process. It's a sense of relief, because that's another bug that's not in the shipping product. Dead on. The goal of both testers and developers is a bug-free product. When bugs get into production code, both of them have failed.

The communication must be tight. Testers should have input on a design plan review, and designers should have input on a test plan review. If there are other ways to design things that are easier to test, it might make sense to do that. If there are items missing in a test plan, a developer should make sure those are added.

And finding bugs during development isn’t a shaming process. It’s a sense of relief, because that’s another bug that’s not in the shipping product.

]]> Comment on Sleeping With The “Enemy” by: Tom Harris http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3131 Sat, 21 Oct 2006 17:11:49 +0000 http://blog.qualityaspect.com/2006/10/20/sleeping-with-the-enemy/#comment-3131 Yes, feeling that everyone's on the same side certainly helps things work better, and we all have to make the effort to overcome the apparent conflicts between assigned roles. Here's an attitude which, if adopted, might help cooperation: http://talkaboutquality.wordpress.com/2006/07/02/work-to-learn/ Yes, feeling that everyone’s on the same side certainly helps things work better, and we all have to make the effort to overcome the apparent conflicts between assigned roles.

Here’s an attitude which, if adopted, might help cooperation:

http://talkaboutquality.wordpress.com/2006/07/02/work-to-learn/

]]>