Sleeping With The “Enemy”
What do police officers, vultures, hunters, guards, predators, and cleaning people, have in common? And what they are all doing in my blog?
[Warning: not too good metaphor ahead] When I was a teenager, I thought all teachers have one purpose in life: to hunt me! And guess what, all my friends felt pretty much the same. Some of us were not-so-good students, and some of us were better. But none of us understood why all the teachers were constantly trying to find what we did wrong. They were always trying to find our mistakes — just waiting for us to slip. And surprisingly enough, they always managed to find something.
Now I understand, of course, that my teachers were in fact there for me. Their goal was not to hunt me, but to help me succeed. Some of them were better than others, but they all had the best intentions. Maybe, if my friends and I had been a little more cooperative, the results would have been much better. But we were teenagers, so what can you expect?
So, (back to the real world) now we are all grown-ups, and some of us are in the software development business. Some of us became software developers, while others became… the new enemy.
Here’s a little experiment you can do in your company. Take a group of testers and another group of developers. Ask each person to write down a metaphor describing his role and another metaphor describing the other group. Chances are that the most common metaphors relating to the testers group will resemble the list above. What’s even more striking is that both testers and developers see eye-to-eye when it comes to the tester’s role. The metaphors most of them choose are very emotional. The metaphors are also extremely negative. If a tester is a vulture, a police officer, or a cleaning person, what is the developer? Prey? A felon? Someone who produces garbage?
The way we see ourselves, and the way we see the people we work with, shapes what we do. If we, as developers, feel we are constantly being watched by people who are just waiting for us to make a mistake, being cooperative is the last thing we will do. If testers feel they are always cleaning up the mess developers leave behind, the last thing they want to do is hear what developers have to say. When the working relationships between us are that charged, we all waste valuable energy on “dealing with” the other person – energy that should have been invested in creating a better product.
Am I just being naive? Can testers and developers really work together? Well, it does happen — sometimes. Some testers and developers out there actually feel they are working together towards a joint goal. And you know what? They are actually doing a better job.
Can you imagine developers helping testers come up with innovative test scenarios? Can you imagine testers helping developers design unit tests? Can you see in your mind developers and testers openly talking about ways to deliver a better product? Believe me, it has been known to happen.
Developers are the best people to know their code. They usually know deep inside which parts of their code are likely to fail and in which cases. If testers are indeed the enemy, why on earth should developers share this intuition with them? But if testers and developers are both on the same side, this kind of information can help testers invest their effort where it can really make a difference.
Testers have the best knowledge when it comes to testing. If developers are “the people we always clean up after”, why on earth should testers try to communicate with them? But if testers and developers are both on the same side, helping developers design better unit tests will cause the product to be delivered to testing in a better condition.
Of course, testers should be independent. Testing should not be limited to what developers think should be tested. But open communication and constant information flow between developers and testers is the best way to optimize testing resources. Open communication with testers will also help developers improve their skills and do a better job to begin with. Developers will learn to see things from the testing perspective and, in some cases, even from the user’s perspective. How bad can that be?
When you come to think of it, managers and developers should feel they are on the same side too… but that’s for another post.
October 21st, 2006 at 9:11 am
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/
October 21st, 2006 at 12:20 pm
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.
October 22nd, 2006 at 3:59 am
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.
October 23rd, 2006 at 8:35 am
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.
October 26th, 2006 at 3:28 pm
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
October 27th, 2006 at 3:04 am
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