Communicating quality defects, keeping room for good testing, and automating writing are some of the ways testers contribute to software teams. According to Maaret Pyhäjärvi, we need to think about testing, not testers. Collaboration and conversations between team members can result in valuable impact that changes the product and experiences of our users.
Maaret Pyhäjärvi gave a keynote on the impact of testers and testing in software teams at HUSTEF 2023.
The way testers contribute to software teams is by identifying and communicating quality gaps, concrete examples of things missing between what we think we want, what we say we want, and what we have, Pyhäjärvi said. Some people call it bug reporting, but that misses the really valuable part, picking and choosing conversations that are timely and relevant, she added.
Testers can keep room for good testing in teams. Instead of pointing out problems, special matching and collapsing can help software developers discover that they can do testing, as Pyhäjärvi explained in the example:
I was working with a developer who was testing his own feature and one day I decided not to say what to test and do. They looked at me and said “Would you like me to click here” and I didn’t say anything, they clicked things choosing what they thought I would do and found problems they missed.
She didn’t realize that sometimes we need to do less to enable people to do more, and just point to a pattern, Pyhäjärvi mentioned. Realizing that she has a greater impact—both now and in the long term—by leading developers to discovery, rather than discovering for them, is an unusual but valuable contribution, she added.
Writing automation that stays behind when you go and do the work is also a valuable contribution of testers in software teams, as Pyhäjärvi explained:
Building for ownership, building for when I’m no longer around to test, and ensuring my input isn’t just about fixing bugs by finding them, but also tracking past lessons in an executable format, with test automation.
Pyhäjärvi mentioned that through testing we can change the product, change the experiences of our users and become better testers and developers:
I like to think that it’s about the testing, not the testers, and we need the courage to start the conversations that create and support change.
Very few of our significant influences come from one person, Pyhäjärvi claims. It takes a village, or couple and a scale effect where you no longer know exactly whose idea fed the final implemented idea. Cooperation creates great results, said Pyhäjärvi. Collaborative credit is a recognition of all parties, not just the one who expressed the final form of the idea, she concluded.
InfoQ interviewed Maaret Pyhäjärvi about productivity testing and sharing stories.
InfoQ: How can we measure testing productivity?
Maaret Pyhäjärvi: Working on testing is like having white paper with invisible ink; no one can tell you in advance exactly what you will have to discover. I use all kinds of approximations in my projects. After I’ve done a bit of testing, walking around or looking at the app, I usually guess how many bugs are hidden and set that as a budget to work towards and track our progress in uncovering them. By working according to a plan, this allows me to update the end goal as I learn, but also shows progress steps. Similarly, but with more effort, I create coverage outlines.
However, I must say that the tester’s lack of productivity manifests itself as noise (disturbing others) and as silence (missing relevant results). Testing is informative at best. At worst, testing provides information that people don’t want or care about. I call that information noise, and noise bothers others.
InfoQ: Why is it important for testers to share their stories?
Pyhäjärvi: Errors are not relevant without their meaning. Meaning is conveyed through story.
Improvements over time, teaching our colleagues something, learning from our colleagues – these are effects that are best shared with stories.
InfoQ: What testing story would you like to share?
Pyhäjärvi: In one project, it took some effort over two years to go from planning test automation to implementing the nitty gritty of it, and realizing that time spent being aware of automation’s limitations was time spent succeeding with it.
I was saying that automation can’t do everything. I have explained the limitations of automation time and time again. And I did less automation. Then I chose differently. Every time I wanted to point out its limitations, I decided to add some valuable work to it. As a result, I got useful and improved automation. It’s still not perfect and needs more thinking, but if I had decided to spend time selling the idea that it could go wrong, I wouldn’t have learned how it could go right.
I think of this as a story about the choices we have but don’t admit we have, since pushing through a time of great change seems safer than changing things. I don’t think we would do a good job of testing without centering exploratory testing and documenting selected lessons in test automation.