I’ve written about the many hats that testers wear, and the importance of collaboration between testers and engineers. My thinking in those articles focused mainly on the work that testers put into their teams, but lately I’ve been considering the other side - the effort that teams and companies put into their QA engineers and testers.
The “shift left” narrative is popular, and I think the underlying concept is important. But rather than focusing on testers shifting left, what happens if we refocus to teams and companies shifting their mindset and their process?
I’ve been on teams that understood and appreciated my involvement early on, and enthusiastically brought me into discoveries, architecture planning, client meetings and demos. I’ve been with companies who understood the benefit of the “extra” work I did beyond feature testing and release management, but didn’t appreciate it and didn’t offer the support I needed to work without burning out. I’ve been on teams who sequestered my role as “review and release”, and pushed back when I tried to do documentation, process improvements, or feature initiatives.
It’s not really about encouraging testers to get involved earlier in the SDLC. Most of the testers I know already want this, and understand the importance of it. We know that we bring skills and insights that will benefit the product and the team when we’re included from the beginning. Being involved earlier also benefits us as testers, because it gives us a better base of knowledge about the thing we’re testing, and we’re better equipped to understand and mitigate the risks.
When I’ve been part of a team or organization with a limited definition of the QA role, I’ve found that having a sponsor or advocate really makes a difference. When I’m trying to shift people’s mindset and expectations, it helps to have someone who supports the idea that testers on teams are part of the team, and need to be included as such. It helps if your advocate is a team lead or senior engineer, because their implicit leadership role gives credibility to their opinion. An advocate can call out the “glue work” and help make it visible to the rest of the team. They can explain from their engineering perspective why it’s useful to have someone with a testing mindset in planning meetings. They can support quality process suggestions, and give you feedback on how to roll it out.
I’m curious to hear how other testers have tackled this - how did you get buy-in from your team about shifting their expectations of your role? Did you tag someone to be an advocate, or did you find another way?
Top comments (0)