High-functioning Agile teams using the whole-team approach to development consistently deliver high-quality software to production. However, in some organizations, testers feel they are not given the same respect as developers. In this article, we hear from test managers about the importance of nurturing a culture in which all team members are respected and where quality is valued.
The perceived value of testers
Bernice Niel Ruhland, software testing manager for ValueCentric, LLC, located in Orchard Park, New York, talked with me about her experiences transitioning a test team to Agile:
There were learning curves about roles and responsibilities, but as the team worked together, each member found his or her place and appreciation for each other’s roles. In my overall experience, I find that testers’ contributions are valued equally to other team members.
Mike Talks, a senior tester with Kiwibank in New Zealand, told me that prior to joining Kiwibank, he’d worked on projects that were poor implementations of “Agile.” These fared no better than projects which poorly implemented “Waterfall.” In his experience:
Any project which undervalues testers is going to have problems because it doesn't take quality seriously, sees it as "an add-on." They deliver work late to testing, but then expect testing to "pick up the slack," but then act shocked that the quality isn't there.
Talks adds that in these troubled projects, “people with passion always shine through because they're always seeking to do things better next time.” Talks finds that in successful projects, testers are involved early. They participate in all meetings along with developers and other roles. They have a unique perspective. Talks asserts that “an engaged tester can prevent a project from starting off on the wrong foot.”
Andrew O’Gorman, QA manager, Paddy Power PLC in Ireland, works in an organization which is gradually implementing some Agile processes. Though the testers work in separate teams, rather than being integrated into cross-functional development teams, they are seen as contributing equal value. O’Gorman told me they’ve accomplished this by doing more than software testing:
Quite often, the test team has the most complete view of the system, and this knowledge allows us to review new designs at requirement/user story stage, detecting issues before they are even coded.
O’Gorman’s testers look back at the end of a project at problems they experienced, and suggest process improvements outside of testing. He helps them present these suggestions to the rest of the development organization, with relevant data to back them up.
How managers support testers
As in O’Gorman’s example, good test leadership involves making sure the rest of the organization sees and understands the value that the testers contribute.
O’Gorman elaborated on how his company’s testers help improve development processes:
The (test) team conducts test-specific retrospectives after each release. We have pushed for the introduction of numerous changes to process based on suggestions originating from the test team, such as extending user stories to adapt specification by example to minimize the gap between requirements and tests.
By ensuring that we are providing relevant data to senior management, we try to make it easy to adopt the changes suggested by the test team.
Ruhland also says that testers in her organization contribute in ways that go far beyond traditional testing activities. She shared her views on how to provide good leadership to gain respect for testers:
I believe you must first show respect to other people and as a manager that must start with me. It is important that I respect the work of the developers, project planners, and other team members. In turn, I can influence my testing team to show the same respect and to help them receive respect back.
From a broader perspective, it is important to show the testers’ areas of expertise and how they support product quality through their testing contribution. Their contribution is not limited to just finding bugs but also the information they provide to developers, product managers and other stakeholders.
I was particularly struck by a point that Talks made: “As a leader the challenge is not to just to position yourself on the good projects, but to really get involved on the bad ones.” As testers and testing managers, we might be able to help struggling projects start to build in better quality.
Building a culture that values quality
Many of us in the testing profession have shared the same sensation that Mike Talks described to me:
Sometimes in IT I feel we're right back at school, the desperate kid trying to rush homework and get "something" in on time, even though the teacher will get annoyed and make us do it again.
An organization’s culture starts at the top. How can upper management nurture an environment that fosters collaboration, where everyone, regardless of role, takes responsibility for building quality in to the product?
Placing more value on the quality of the product rather than just whether a particular feature was delivered on time could help development teams integrate testing more tightly with coding. Mike Talks suggests that “we need to challenge what we mean by ‘delivery.’ ‘Delivery of code’ should mean something suitable for production, not the latest untested build.”
A culture of blame works against a culture of quality. Ruhland noted that “at some companies, there is a reliance on the test team to be the gatekeepers of quality, rather than have it everyone’s responsibility.” How can we change this? Ruhland provided these ideas:
We should encourage reviewing problems and solutions from a holistic perspective. For example, when an important bug is missed, do not immediately blame the testing team. Instead spend time to understand what in the process contributed to the bug being missed and implement necessary changes.
As Ruhland pointed out to me, each team must agree on areas for improvement, and define common goals. She recommends an incremental approach, trying small pilot programs, continuously applying what is learned to make small improvements.
A focus on learning leads to a focus on quality. Many programmers have no experience with testing. They need time to learn practices that “bake quality in,” such as test-driven development and specification by example. People in different roles need time to learn good ways to collaborate with each other. When executives assure the development organization that they themselves value quality over speed, and budget the time to enable that to happen, teams can try experiments and pilot projects to improve their process and manage their technical debt. Programmers and testers can learn how to integrate testing with coding, and deliver the code their customers want.
It takes courage to be a change agent. As Bob Martin explains in his book The Clean Coder, telling management that your team will “try” to meet an impossible deadline does NOT equal being a “team player.” A team player does what is right to make the business succeed, and that includes being honest about the team’s capabilities, and the risks associated with poor software quality. O’Gorman shared his opinion with me:
My view is that upper management in our organization needs to continue adopting ‘Agile’ development approaches, to see a wider responsibility for quality.