In May 2022, not sure if I would keep writing and posting blogs, I looked to LinkedIn for ideas. I asked if anybody who read my writing had ideas on what I should write about. I was very surprised by the number of responses I got. It turns out that, of itself, the feedback wasn’t the kick along I had hoped it might be. However, after barely writing for the past 18 months, or so, it finally feels like something I want to do again. So while the feeling, and enjoyment lasts, I guess I’m back to producing posts on a regular basis. To those who offered up topic ideas, thank you.
My current hope for this series of articles is to write from my experience, what has worked for me. When relevant expect stories of when an idea “crashed and burned” or reflections on how I could have changed things to improve outcomes in some respect. I’m going to try and avoid diving into books and extracting chunks of text or parading theory (note: I strongly suspect that at some point I’ll break those rules at least once).
I’m going to start this journey with 3 suggestions I received and see how things unfold.
Soft skills, negotiation skills and influencing skill as to how testing activities should be conducted. – Rajiv B
Being able to find defects is of course part of the trade, but being able to communicate your findings and create rapport with your peers is extremely important. So I’m in line with Rajiv, about having soft skills is key to being a good tester. – Juan M Tijerina
Communication – Saurabh Gulati
If you look through the suggestions you’ll note there is a lot going on. Way too much for a single post, but there is also a clear connection between all of the suggestions. Saurabh went straight to the point, Juan mentioned it as well and while Rajiv didn’t use the specific word – communication, his topics don’t exist healthily in a space where communication is sparse, poor or near extinct (a topic I should write on, I have stories). So, for this post the focus is, as a tester, how do I communicate? What is important to me in terms of both doing, and not doing, if I want to be effective at my job and add value.
Communication is interesting because it is so layered. Testers have internal stakeholders and external stakeholders. Some stakeholders need specific information, others want it to be more general. Some will seek information on a “need it now” basis others will simply wait for the communications to be issued on an agreed cadence. Some communication will happen daily or intra day. Other communication might be best accumulated over a longer period and then communicated. The communication can be oral, written or body language. I’m going to ignore body language for now, maybe something for another post.
As a tester have you ever asked yourself “who is my audience?” That’s an important question and you need to have a good idea of not only who they are but effective ways to communicate with them. You don’t ask a punk rock band to perform in front of a hard core opera audience because there would be a massive mismatch of desires and the performance message lost (and arguably not relevant to the interest of the patrons). In any given work day you get limited opportunities to tell your story, to get your view heard, to make an impression and help influence good outcomes. You want your performance to be received and listened to. This is not a simple task. Maybe you can be successful occasionally without planning, but, if you want to really have your messages cut through, you need to be practiced and prepared. Even those ad-hoc, on the spot requests, with some practice, can be made to look polished.
Rapport
a friendly, harmonious relationship especially : a relationship characterized by agreement, mutual understanding, or empathy that makes communication possible or easy
https://www.merriam-webster.com/dictionary/rapport
Rapport, a building block to effective communication, especially when working with internal stakeholders. If you deal directly with your external stakeholders then it’s as equally important to establish some level of rapport with them as well.
I work with an assumption that my colleagues are professionals that always do their best work, doing the best they can in any given moment. I have an interest in my colleagues welfare and happiness above concerns for their work. If people are having a bad day, my assumption is that they are doing the best they can under the circumstances and I’ll offer whatever support I can. I take every opportunity I can to let my team and colleagues know I appreciate their efforts and support.
My style has evolved over the years, guided by plenty of failures, into building rapport through trying to be light hearted in my approach when the context supports that. Solving problems and being creative just doesn’t work well when people are tense. Throwing in the occasional “Dad joke” or a “left field thought” at the right moment can help people relax. You need to develop a feel for the right timing but laughter can be a real “ice breaker” and a way to open a flow of collaborative discussion.
When people want information I try to focus my responses on the specific question and also throw in any side details that might be relevant. If I don’t know an answer to something that I’ve been connected to I’ll make a promise to find out and return with an answer. I encourage people to ask questions and challenge me and I make myself available to assist others resolve problems. In short, I work with people by doing things that shows I care about them and also about the software we are working on. I want to work with people that are collaborative and easy to get along with. My goal is to reciprocate with my colleagues. This approach seems to work for me, I think, because it’s based on me, it represents values I hold, so, hopefully, it comes through in my communication (whether that be written or spoken) that I’m a professional who cares about what is happening and I want to act in ways that demonstrate this.
Rapport is a building block to good communication but not the only one. However, as Juan specifically mentioned this, and I see it as really important when we are working with people (either in person or remote) I’ve spent a little bit of time on it. Maybe in a future post or two I’ll dig into aspects of establishing a communication foundation. So now it’s time to get specific in some aspects of communication within testing.
Communication
a process by which information is exchanged between individuals through a common system of symbols, signs, or behaviour
a technique for expressing ideas effectively
https://www.merriam-webster.com/dictionary/communication
I work with a specific principle guiding my communication – “no surprises”. I’ve worked in companies where important information is withheld or represented inaccurately until the last possible moment where the deception can no longer be continued. Imagine seeing a project status being represented as “green” right up until the meeting prior to release where it suddenly changes to “red”. I’ve seen this more than once and have no time for this type of approach. When you find important information as a tester, make it visible to those who need to know. This isn’t restricted to bad news, when things are going well, communicate that clearly as well. Provide balanced reports to those that need updates, make them relevant, make them easy to understand. For many testers that communication is quite likely in the form of test cases passed and failed. I’d really encourage you to work on changing that and instead talking about the risks you have found. Talk about the features that seem to be stable and ready for use, talk about bugs that are reported but not yet fixed and could be problematic if they are released to production. Talk about the bugs that need to be addressed now or very soon because the changes are potentially risky and will require some in-depth testing. Give people information that allows the construction of informed decisions. Your ability to communicate your testing accurately and clearly, will, like it or not, play a key role in how people perceive your credibility. To be really clear, make sure when you provide updates it is evidence based. Even when you use phrases like “my suspicion is that this change might be a problem” it is really important to be able to demonstrate why you have that suspicion. Be prepared for discussion. In my mind at least that just means being aware of the status of your testing (and the project) at any given time. I feel like that is something that, as a tester, you should always have in your mind as it should be influencing decisions around discussions you need to have and your next test to be executed. Communication is an important part of the discussion with Rapid Software Testing. I’d encourage you to check that out and to also examine the RST 3 part story model
It’s been around 2 months since I started writing this post (becoming unexpectedly unemployed moved my attention to other things) and I think this post is long enough. There are sub threads in this bit of writing that I may return to at some point and probably some parts of the initial questions that remain unanswered. What I have laid out is how I go about some specific facets of communication. The writing touches on themes but I hope it has enough information to be helpful. The thing is, it doesn’t matter how much I write about my take on communication, it is how YOU communicate. It is about how much you practice being able to deliver information well across different contexts. Enjoy the communication journey. I think it’s a fascinating ride.
@Beaglesays 
One thought on “Because you asked – Part 1”