One of the biggest divides you need to cross, even on agile teams, is the chasm between testers and developers. By the nature of their different roles there will always be tension with developers focusing on creation, change, and construction, and testers focusing on breaking, destructive, and exposing questionable system behaviours. It’s essential that both organisations and, in particular, individuals realise what they can do to ensure this tension doesn’t dissolve into an exclusively confrontational relationship.
Photo taken from Sephiroty’s Flickr stream under the Creative Commons licence
Recently, a new QA person highlighted this very issue for me. I’d finished some functionality with my pair and the QA had been testing it after we declared it ready to test. They came along to my desk and said, “I’ve found some defects with your code.” Internally I winced as I noticed myself wanting to say, “There’s nothing wrong with my code.” It got me thinking about why.
Evaluating people puts them on the defensive
Just as giving effective feedback should focus on behaviour, poor feedback makes a person feel criticised. When the QA said that there are some “defects”, it implied a broken state that you had to fix it. Made worse is the way that they said it made it feel like they were blaming you, and it’s very hard not to feel defensive in a situation like this. A very natural outcome is to pretty much deny the “evaluation” which I’m sure anyone in our industry would have witnessed at least once.
Avoid terms like “defect”, “broken”, “bugs”
One of the biggest differences working with agile testers versus testers who come from traditional backgrounds is the terms that they use. Traditional testers constantly use the words above. Agile testers focus on discussing the behaviour of the system and what expected behaviour they would see. They only use the words above once they have agreement on both of the both the current and expected behaviours. I definitely recommend you do not start a conversation with the words above as they all carry some connotation of “evaluation” and I’m yet to meet someone who truly feels comfortable being “evaluated”
Focus on Effective Feedback
Effective feedback follows a neat and simple pattern:
- What behaviour did you see?
- What impact did it have?
- What do we want to change?
Testers should use a similar series of questions (in order):
- What behaviour did you see?
- What behaviours did you expect to see?
- What are the consequences of the current system behaviour?
- Is that desired or undesired?
- Do we need to change it?
Apply the guideline above and watch the collaboration improve!
I agree,
I would add coo locate the teams (devs/qas) as much as possible, reducing the overhead of communication and, more importantly to make sure that the tester will feel himself as part of the team.
Fantastic!!! That’s exactly the problems that we have every day. Good advices, I’m gonna show it to my staff in the retrospective metting.
Avoid terms like “defect”, “broken”, “bugs” ……
I sometimes get extremely annoyed at all the idiotic foolishished sweetneess people and companies try to bring by these name changes and think it can cure all evil.
A defect is a defect (or a bug is a bug) and that’s it .. period.
Do all of us a favor and not try this. It helps ..
Dear Anonymous,
I’m sorry that you found this approach didn’t work for you. I would like to hear more about *why* it didn’t work for as I have no idea what your environment is like. I should also point out that simple changes to words such as this do not work for all teams or environments. Nor is it a panacea to fix all team problems.
I blogged about this because I worked with teams who built stronger relationships by understanding the impact of the words they used and agreeing to change them. It still surprises me how things that seem little make a big difference.