Bobbing for Embedded Apples
How does having a software tester in a team impact quality?
One of my first recollections of physics is the image of Archimedes running down the street, dripping wet from his bath and shouting: “Eureka I found it!” on discovering his principle of fluid displacement to measure the force.
Add to that Isaac Newton who quietly sat under an apple tree, musing the day away until he discovered his laws of motion, one which states;
For every action there is an equal and opposite reaction..
Many companies want to improve their testing, particularly if that improvement is translated into reduced time or cost.
To achieve this, there’s a big trend to embed testers into development teams. There’s no longer ‘us’ and ‘them’ but a harmonious ‘we’. The wall of independence is torn down and replaced by a gleaming whiteboard emblazoned with the banner ‘Quality is a team responsibility.
The reality though is that just like Archimedes in his bath, embedding testers into a team of developers are going to create displacement and cause a reaction.
This is common sense. Put one tester into a team of multiple developers and it’s going to change the team dynamics. Add to the mix, that the tester will most likely become a point of constraint disrupting what was perhaps a seamless flow of stories into the Done column and it’s no wonder the apple cart gets upset.
For example, developers discover they need to get more involved in testing and decision-making. That can be a big mindset change if traditionally developers are used to handing work over to testers (as opposed to receiving it from them).
Testers need to change and adapt too. They have to let go of control over all the testing and entrust the developers to help them test. Again big mindset change for testers who traditionally rely on empirical evidence than a developer's word to evaluate quality.
Why then, do we seem surprised when we face resistance and/or confusion when these changes are attempted?
This is our brave new world. I wonder where we will all end up? Whether a team develops a true and meaningful relationship or simply an uneasy alliance is I guess up to how much both testers and developers are prepared to appreciate each other’s challenges.
One way we can help each other out is to be supportive as opposed to defensive when people face the impact of changes and perhaps feel displaced and confused. How much we are prepared to let go of our assumptions and prejudices about each other will also play a big part in how ‘successful’ these experiments are deemed to be.
Exciting times indeed!