Cross functional agile teams mostly include developers and testers and collaboration is considered important for agile teams to become successful. At the same time there is a benefit of having independence for testers, so that they can report about the quality of the software without fear. How can you balance testers independence with collaboration in agile teams?
The article The dotted line in role delineation between a developer and a tester by Rajini Padmanaban on StickyMinds describes how striving for collaboration in teams can introduce ambiguity in the roles and responsibilities of team members. She explains that it is important for testers to remain Independent:
(…) in understanding the bounds of a tester’s role in a product team, it’s important to retain the independence factor. What this translates into is that when testers collaborate and share some responsibilities with the rest of the product team, they have to be very cautious not to assume work that conflicts with their core goals or independence.
Rajini states that the development team is responsible for unit testing, and warns against testers getting too much involved and risking their independence:
It is perfectly fine for testers to provide input to the developers on designing unit test cases, help them with any tool issues they face, and define parameters around exit criteria for a build to be released to test. These are scenarios where the tester is empowering the developer to focus on quality without losing his own independence factor in the test effort. If a tester were to extend this help to creating the unit tests himself, he may soon be tempted to touch the source code to fix any defects or bugs that the unit tests report. This is a clear case of trespassing into the developer’s boundary of operations.
She concludes her article by explaining that testers have to be independent and focus on their core tasks, and that collaboration with developers shouldn’t conflict with that:
Understanding both sides of the coin will help maintain a healthy balance between the roles of developer and tester with the two collaborating on the right set of areas to ship a product of exceptional quality.
Elisabeth Hendrickson wrote the blog post why I won’t go back, which includes a diagram showing about how test managers can become ineffectual:
She summarizes the problems she has seen in managing independent QA/Test groups and why she prefers testing to be engrained:
I’d much rather work with organizations to integrate testing activities throughout the cycle and across all roles. The traditional role of a test manager in organizations that practice test-last development is a miserable job. Add in a sprinkle of dysfunctional QA blaming while simultaneously undercutting any efforts the QA manager makes to increase quality? The job becomes a recipe for depression and substance abuse.
In the blog post agile vs fragile: The role of “independent” testing in the agile framework, Brian Copeland shares his view on how testers can collaborate and remain independent:
Testers have to understand that their job is to make an independent assessment that the developed solution meets the requirements. That doesn’t mean that they are recused from talking to developers or participating in project activities. Quite the opposite, they need to be highly involved and identify issues before they are even coded into the solution. They need to participate in design sessions, and look with an independent eye at what is being missed by the team.
His opinion is that “testing should be a continuously integrated part of every sprint”:
The testing activity needs to be planned as part of the sprint planning session. Testing costs story points, and the testing team needs to ensure they are presenting that as part of the overall cost of the sprint. Testing can’t be held until the end when the final piece of the puzzle is put in place.
Earlier this year InfoQ wrote about improving collaboration of testers and developers in agile teams, and gave some examples of what scrum masters can do to help testers and developers to work together in agile teams, and improve collaboration.
Test consultant Fiona Charles wrote an article on TechWell about the independent tester. She describes the negative consequences that can result from having organizational independent testing:
Too often, testers came to see themselves as the sole champions of quality in their organizations. Instead of working with the programmers and talking with them about what they were building, testers sat at their desks waiting for frozen requirements to come to them and then didn’t start testing until they got frozen systems. Many testers became gatekeepers—effectively, arbiters of quality—instead of development partners. In some organizations, the testers came to be viewed as obstacles, getting in the way of the development process while adding no real value. Rather than enhancing testers’ credibility, the combination of that view and those tester behaviors sabotaged it.
Organizations should recognize the value that testers deliver, encourage them to speak up, and help testers to develop their technical and communication skills. Independence of testers according to Fiona is a mindset made possible by the organizational culture:
If we don’t believe that separate test organizations are the solution, does that mean the concept of tester independence is no longer important? I think it is important. A tester needs to be both a full development partner and an independent observer—able to dive in and collaborate, and yet maintain his or her identity as a tester. That can be an extraordinarily difficult balancing act for anyone. If the whole culture doesn’t support it, the tester will fall off the wire.
