I shared the results of our experiment in my talk at TestBash in Brighton earlier in the year. For those who missed this presentation, this is a short written summary of the four main benefits that we observed from cross-team pair testing.
Visibility of other teams
Before we began the experiment I had received feedback from the testers that they felt siloed from their testing peers. At that stage we had 20 testers spread across 15 different agile teams, which meant that many were working as the only specialist tester in a cross-functional delivery team.
This isolation was starting to seed imposter syndrome. The testers were beginning to doubt their own abilities and feel uncertain about whether they were doing things right.
The proliferation of these tools meant that the testers were more productive. They were able to reduce the repetitive tasks in their workflow and use appropriate tools to support their test approach.
Happily, one of the strongest themes in the feedback about cross-team pairing was that it increased visibility of what was happening in other teams. The opportunity to understand how another team operated was described as interesting, eye opening and awesome. Seeing other practices and processes gave a degree of comfort to each tester that their own approach was appropriate.
Broader Scope
One of the challenges in being the only test specialist in a team is in generating testing ideas. It can be difficult to consider different perspectives when brainstorming as an individual.
Through pairing, the testers were able to see their application through fresh eyes by exploring with a tester from outside of their product. A different mindset helped them to identify gaps in the application and think of creative ideas to explore functionality. The opportunity to have deep discussions about testing led to the discovery of interesting problems on unexpected pathways.
The broader thinking demonstrated within a pairing session was then carried into future testing as each individual tester started to augment their own planning with ideas they had seen demonstrated by their peers.
Improve communication
Make fewer assumptions. Ask more questions. These are two central tenets of testing that most testers will believe they do. When compared to other disciplines, its often true that testers are asking more questions. Pairing highlighted situations where testers had started to relax these instincts.
The tester who was hosting a session would often make incorrect assumptions about the depth of their visitors knowledge. Their "simple" explanations were difficult for someone from outside of their delivery team to understand.
The presence of an outsider exposed the amount of assumed institutional knowledge in the business stories, test planning and informal communication of a team. The tester who was visiting a peer would have to ask a lot of questions in order to understand the application and how it would be tested.
Pairing caused the testers to question their own expectations of knowledge in the team. They started to make fewer assumptions about what had been left unstated in team documentation. By increasing the number of questions they asked, the testers began to interrogate whether there was truly shared understanding or instead shallow agreement.
New Approach
Every person will have a unique way of working. Not just in their thinking, but in the particular combination of tools that they use to capture, process and report information.
Pairing gave the testers the opportunity to observe and experience the work environment of a colleague. In many cases this first-hand experience led to the discovery of a new tool that could be adopted by the visiting tester in their own work. Through pairing we saw chrome extensions, excel macros and screenshot tools propagate across the department.
For more information about pairing, please refer to my previous posts:
Next month, our team is divided in two teams, so I think we are going to do also cross team testing. Nice to know that we are not the only ones and that cross team testing can be beneficial.
ReplyDeleteThanks so much for blogging about this! I hope to use your post to persuade my team to adopt more pairing and sharing across teams. I particularly like the distinction you made between 'shared understanding' and 'shallow agreement'. I look forward to catching up on some of your previous posts!
ReplyDeletePairing on the other hand gives opportunity for the testers to get the big picture surrounding the application which will help the project in analysing the impact at each layer. With careful analysis the code will be structured along with the reviews will be done. In agile the advantage with this approach is to reduce defect leakages at later stage.
ReplyDelete