I’ve recently started in a new team at work, not only am I new to the team, but the team itself is forming from different people from across the org.
Of the 15+ people in the team (some are shared with other teams) across multiple roles, I’m the only Quality Engineer. So I wanted to understand where the team is now in terms of their understanding of testing and quality, and get some input to influence what I should focus on in Q1, and beyond.
So I built and questionnaire with Google Forms, and sent it round the team, and I’m very happy with some of the insights I’ve gained. For example, it was a surprise to me no one thought my highest priority should be writing automated tests. I was also very pleased to see a good amount of the team would be happy to join ensemble testing sessions, lead by someone else.
The experiment isn’t yet complete, I’ve only just written up the results and I’ve yet to fully share them back to the team. And I’m going to re-run the experiment in Q2, and see what has changed so I can see if we made progress.
Overall I’m very pleased with my approche, it feels much more deliberate and organised then I’ve been in the past when it comes to gathering and setting expectations with my team.
Have you run similar experiments with you team? How do you gather and manage expectations in your role? I’d love to hear from you!
Would you be open to sharing the contents of the form? As in, share the questions or at least a generalised version of it to respect privacy and remove context. Also, curious about what question types you used e.g. open, scales, multi-choice etc
As soon as you described your success I was instantly keen to see that questionnaire and I have a hunch others might too.
Totally understand if the content is not available for public consumption.
Interesting idea.
I gained my input from reactions to raised and missed bugs. It can tell you a lot about the team’s understanding of quality (“who cares about this little bug that will never happen in real life?!”) and the role of testers (“how could you have missed this?”).
Thank you for your input. Bugs and how the team treat them is important, and I’ve seen plenty of examples in every extreme. Even looking at my own past behaviour, I’ve matured (I hope for the better) the relationship I have with bugs.
I’m interested to know what insights you gain from your observations of bug-response behaviour, and how you use this to develop the team or your own practice?
I’m interested in what questions you used. Often the questions we ask guide the answers we’re looking for.
I don’t really do this (questionnaire), but finding ways to engage with folks more 1-on-1 let them talk to me about what they think testing means, and let me talk about what I do. It’s all part of the rapport building I do.
Everything seemed to be the testers fault and all bugs or rejected tickets were not welcome. So we had a culture issue. You don’t change that over night. It’s not like I a did an analysis or created a plan. I made adjustments to my behavior and tried different things to see what helped.
What helped (not necessarily recommended):
Instead of rejecting or raining new tickets acting like a confused tester that might have done something wrong and needs help (even when it’s clear that there is a bug). When they figure out that it’s wrong you can act with their approval.
If you raise a ticket make it perfect as there will be push back. Give as much detail as possible.
Be transparent in your actions and share what testers do to gain understanding.
As respect seemed to come from technical knowledge I tried to learn more and it also made me a better tester.
