The Impact of Testing in Software Teams - Wishevoke

The Impact of Testing in Software Teams

Communicating quality gaps, creating space for good testing, and writing automation are some of the ways testers contribute to software teams. According to Maaret Pyhäjärvi, we need to think about tests, not testers. Collaboration and conversations between team members can have valuable impacts that transform the product and our users’ experiences.

Maaret Pyhäjärvi gave a keynote on the impact of testers and testing on software teams HUSTEF 2023.

One way testers contribute to software teams is by identifying and communicating the quality gap, the concrete examples of things that exist between what we think we want, what we say we want, and what we have is missing, said Pyhäjärvi. “Some people call this bug reporting, but that ignores the really valuable part: the decision to have a conversation and choosing which conversation is timely and relevant,” she added.

Testers can create space for good testing in teams. Rather than pointing out problems, pairing and ensembling in particular can help software developers figure out that they can test, as Pyhäjärvi explained with an 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, “You want me to click here,” and I didn’t say anything, they clicked on things and picked what they thought I would do and found problems they missed.

“She didn’t realize that sometimes we should do less so that people can do more and just point out the pattern,” Pyhäjärvi said. Recognizing that she has more impact — in the moment 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 leave and does the work is also a valuable contribution from testers in software teams, as Pyhäjärvi explained:

Building up for ownership, building up for the time when I’m no longer there to test myself, and making sure my contribution isn’t just about fixing mistakes by finding them, but also about incorporating past lessons into an executable documentation format with test automation.

Pyhäjärvi mentioned that through testing we can change the product, change our users’ experiences and become better testers and programmers:

I like to think it’s about testing, not testers, and we need the courage to have conversations that create and support change.

“Very few of our meaningful impacts come from a single person,” Pyhäjärvi argued. It takes a village or a couple and a ladder effect where you no longer know exactly whose idea inspired the idea that was ultimately implemented. “Collaboration leads to great results,” said Pyhäjärvi. Collaborative recognition means recognizing all parties, not just the one who expressed the final form of the idea, she concluded.

InfoQ interviewed Maaret Pyhäjärvi about testing productivity and sharing stories.

InfoQ: How can we measure test productivity?

Maaret Pyhäjärvi: The work of testing is like a white paper with invisible ink; No one can tell you in advance exactly what you need to discover. I use all possible approximations in my projects. After testing a bit by taking a walk-through or overview of the application, I usually estimate how many bugs are hidden, set that as the budget I’m working against, and track our progress in uncovering those bugs . Based on a plan, this allows me to update the end goal as I learn but also show progress. In a similar way, but with more effort, I create reporting outlines.

However, I have to say that the testers’ lack of productivity shows up as noise (that disturbs others) and silence (the lack of relevant results). At best, tests provide information. In the worst case scenario, tests provide information that people don’t want or are not interested in. I call this kind of information noise, and noise disturbs others.

InfoQ: Why is it important for testers to share their stories?

Pyhäjärvi: Errors are irrelevant without their meaning. Meaning is conveyed with a story.

Improving over time, teaching our colleagues, learning from our colleagues – these are impacts best shared through stories.

InfoQ: What testing story would you like to share?

Pyhäjärvi: On one project, over the course of two years, it was a little stressful to go from planning test automation to implementing tiny parts of it and realizing that the time wasted warning about the limitations of automation, It takes time to be successful.

I’ve always said that automation can’t do everything. I have explained the limitations of automation again and again. And I automated less. Then I decided differently. Every time I wanted to warn about the limits, I decided to add valuable work. As a result, I got useful and improved automation. It’s still not perfect and requires more thought from me, but if I had spent time selling the idea that it could go wrong, I wouldn’t have learned how to make it go right.

I see this as a story about the choices we have, but I’m not aware that we have them, as it seems safer to persevere in times of great change than to change things. I don’t think we would have done a good job at testing without focusing on exploratory testing and documenting selected test automation lessons.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top