Focus on the Issues, not the People: 99 Ways Workshop #63

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 

Suggestion #63: When reporting, try not to be seen as the enemy; assign blame to systems and applications rather than individuals and stick to the facts. Equally, emphasize the positives, and the efforts made to correct issues; this time ignore the systems and applications and focus on the individuals who got the defects fixed. - Joseph Brannan

This is an aspect of everyday life, not just software testing. As has been mentioned previously, software is written by humans, for humans, and ultimately is human. We all share the processes of getting software that is useful, usable, and defect free as possible. We can be effective and we can also do so in a way that focuses on the fact and the issues, and minimizes getting personal.

Workshop #63: Use the paradigm of the journalist/beat reporter. Make each story relevant to the community you are reporting to. Be an ethical reporter, and keep the editorializing to a minimum.

Jon Bach, through his writing over the years, was the one that first cemented in my head the idea that software testers were being mis-cast in their roles as "guardians of the code".  For many years, I was taught that there was a focus on breaking the software; we had to find the problems made by those "lazy developers who didn't know better". We had to protect our customers from "shoddy code and practices".  This was also fostered during an era or very separate development and testing organizations. Jon helped me see that this was a bad focus, and an improper use of all of our time. Instead, a better metaphor for us was that we were journalists. We were interviewers, and we were developing stories to share in the local paper for our community. In this case, the local paper was our organization, and the readers were all of the engineers, testers, senior management, etc.

With that in mind, think about how you would write a front page story for your community.

- How you'd you craft the headline?
- What would be your lead paragraph?
- How far into the details would you go?
- Is your story front page news, or is it something for one of the special sections of the paper? 

Additionally, imagine that you are also potentially going to read about your own actions in this paper.

- What you would want to see people write about you?
- How would that level of exposure make you feel?
- What information would you want to have public, and which would you prefer to remain private?

The metaphor for telling stories and using a newspaper as the medium is a strong one, and it really brings home to me the value of what we do. Yes, we test, and yes, we look for problems, but we don't do that in isolation. We do that as part of a broader community, and in this case, that community is the people we work with everyday, and by extension the customers that we serve. Our "reporting" needs to focus on the most important details, which should be "what information will I find that will be the most informative and helpful to my community? What kind of a reporter do I want to be?"

Personally, I do not want to be seen as a gossip columnist. I don't want to be seen as a partisan. I don't want to be seen as vengeful or mean spirited. I don't want to be considered a "Papparazzi". I want to be seen as one who provides good reporting, solid information and gets to the heart of the matter in a way that will help the most people. Take the time to show what the questions are, and also show how we asked them. In a literal news report, that is easy. In a software testing framework, we need to balance the test reporting with the issues we have discovered, and help make a narrative that will either give those who make the decisions the confidence to move forward, or the willingness to stop and focus attention on fixing the issues that need to be fixed. 

Bottom Line:

The job of software quality is shared by the entire team. As such, we all share in shaping the narrative and telling the story of what the product will ultimately be. We provide information for the organization so that the ones responsible for making decisions can do so with the best insights possible. We are much more likely to be effective if, in this process, we focus on the issues, and leave the personal or the political out of the mix, as much as possible.