The Oxford English Dictionary defines soft skills this way: “personal attributes that enable someone to interact effectively and harmoniously with other people.” “Soft” seems to imply that these skills are easier to learn or less important than “hard” skills such as technical competencies. There’s a lot of debate over the best term to describe these abilities. Some like to call them people skills. We prefer the term thinking skills, because in addition to our relationships with people, these skills apply to other areas such as problem solving, understanding the business domain, using the right thinking style for a given testing activity, and organizing our time.
Thinking skills are not tangible in the sense that we can say, “I’ve learned that; I can practice it perfectly now.” Abilities such as communication, collaboration, facilitation, problem solving, and prioritization can be the most difficult to master, yet they are the most crucial for success in agile testing.
In many organizations, when testers are part of a separate team, they tend to talk only to other testers, possibly to programmers, but rarely to anyone on the customer team. On agile teams, however, testers and other team members work closely with business stakeholders and product owners and managers to elicit requirements and uncover hidden assumptions. Programmers, analysts, and team members in other roles also contribute to eliciting requirements, helping to address the impact of technical issues and dependencies. This is why concepts such as systems thinking—how we got here, and what changes impact other parts of the system—are so critical.
Testers and other team members engaged in testing and quality-focused activities can apply interpersonal and leadership skills to help the development and customer teams improve their software product and process.
Activities such as specification workshops (Adzic, 2009) work best when someone skilled in facilitating helps to guide the discussion. A facilitator (see Figure 4-1) who isn’t engaged in capturing the requirements would be ideal, but any team member who has key thinking skills, such as how to get people in different roles to work together and stay focused on a common objective, can step up if needed. Specification workshop facilitators help stakeholders set business goals and help both the development and customer team members collaboratively define the scope that will achieve those goals.
Similar skills help you facilitate informal brainstorming sessions, ensuring that each participant feels free to express ideas without being criticized. Working on acquiring these skills helps you find creative ways for your team to solve problems. See the bibliography for Part II, “Learning for Better Testing,” for more recommended books to help you hone your facilitation skills for gathering requirements and collaborating effectively.
When we talk about nontechnical skills, we don’t mean they are easy to master. For example, many of us continually work to improve our problem-solving skills; some university computer science or IT programs may teach skills like this, but often they aren’t in the curriculum. People generally need to acquire them on the job.
Janet’s Story
I remember when I first wrote my exam for the ASQ Certified Quality Manager, I failed the written part, which was how to address two specific problems. I believe I failed because I didn’t remember how to apply my problem-solving skills. I first learned those skills when I took Physics 101 at the University of Alberta, but I didn’t apply them on a regular basis. When I failed my exam, I sat back, figured out the root cause, and went back to basics by reviewing how to solve a problem. In physics, that started with drawing a picture. I rewrote my exam following the principles of problem solving and passed. I then presented what worked for me to the next group of people who wanted to write the exam, which reinforced what I had learned.
Problem solving is one of those transferable skills that can be applied to test design, debugging, coaching, or teaching. Perhaps the most useful thinking skill is to know how to help your team address its problems, rather than going in and fixing the symptoms. Courses such as Problem Solving Leadership (PSL) (Derby et al., 2014) are a good way to learn how your team can reframe problems, resolve conflicts, and communicate more effectively. You don’t have to be in a management position to provide leadership for your team and help them improve their problem-solving effectiveness.
Tools that help us visualize our thinking, such as mind mapping, impact mapping (see Chapter 9, “Are We Building the Right Thing?”), and root-cause analysis tools, are good additions to a toolkit for testing. The “5 Whys” (Wikipedia, 2014a) use an iterative question-asking technique to explore root causes of a problem. Fishbone or Ishikawa diagrams (Wikipedia, 2014h) can be used for defect prevention and for identifying risks and potential pitfalls. After generating ideas in a brainstorming session, use techniques such as affinity diagrams or impact maps (see Figure 4-2) to organize the insights and potential experiments. Try different thinking tools to help elicit requirements and examples from customers. Drawing on a physical or virtual whiteboard enhances communication and creativity. Try it the next time your team gets together to identify impediments and experiments to chip away at them.
Giving and receiving feedback is almost an art form. Ideally, the giver’s intention is to aid in the receiver’s learning and to grow the relationship between them. We learned from Ellen Gottesdiener that feedback may actually say more about the giver than the receiver. The person giving feedback is basing it on his or her perceptions, and it is shaped by the person’s emotions at the time of giving. Since we tend to give feedback about what matters to us, not what matters most to the other person, it is easy to miss context. Our tone, the words we choose, and our nonverbal communication may obscure our message.
Bear this in mind when you feel the urge to deliver your observations to another person. Think about how you’d want to receive the same feedback. Knowing how to keep the focus on the work, not on the person, is essential. Bug reporting is one way to provide feedback, but usually not the most effective. It takes time and practice to learn how to engage colleagues in a positive exchange when talking about negative issues. For example, “I read this to say . . . could it be changed to be more meaningful?” comes across better than, “You must change this. . . .”
Jurgen Appelo’s “Feedback Wrap” workout (Appelo, 2013) describes ways to give constructive feedback that helps build trust within the team. As Jurgen notes, giving feedback gets harder to do as so many teams have less face time with coworkers, due to distributed teams, remote working, and flexible hours. He points out that written feedback, done in an honest and friendly way, allows you to think more carefully and present observations and feelings in a more balanced way. It can be done fast and frequently. Experiment with different ways to provide timely feedback to team members, and keep inspecting and adapting your feedback process.
Empathy is essential for providing good feedback. Think about how you would want to receive unwelcome information. Toastmasters International, a nonprofit organization for public speaking, teaches skills for giving speech evaluations, and these are transferable to providing feedback on software teams. Giving feedback and providing information are part of testing, and there are many opportunities to practice. In collaboration with stakeholders, identify ways to measure how successful a new feature might be. Make testing visible and transparent. If your customers always know the team’s current status and trust that they’ll be told of any risks or issues, they’ll be more receptive to any news (good or bad) you have to deliver. Testers learn constructive ways to provide feedback, such as showing defects to programmers, without causing offense or hurt feelings. This sensitivity applies anytime you’re delivering feedback.
We’ve talked a lot about giving feedback. What about receiving it? Strive to understand what the message being delivered is about before you jump to conclusions. Thank the people who give you feedback for their honest input. Ask questions to clarify. Too often we, as receivers, take in the emotion and the delivery rather than the message. Receivers may also have previous experiences that could cause them to hear something different from what was actually said. Listen to learn. See the bibliography for Part II for recommended readings to learn good feedback techniques.
Domain knowledge is an example of a skill that may be either part of your broad set of skills or part of your specialty—deep and thorough. Teams with both a broad and deep understanding of the business can better help stakeholders prioritize features, simplify solutions, or even offer alternatives outside of new software to solve a problem.
Lisa’s Story
Learning firsthand how customers use a software product helps us do a better job of delivering the right value to them. On my current team, testers handle customer support via email, with help from the programmers. We also monitor our product’s community forum. We’ve had to practice our patience and tact so we can ask good questions, listen to the responses, and build a rapport with users so they feel free to share their feedback. We learn firsthand how our customers use our product and get valuable feedback on what features would provide the most value for them. We use our judgment to decide when an issue or feature request needs to be escalated. We often encounter scenarios that provide useful test cases or test charters for us to use while testing new features.
I’ve had a lot of experience working in customer support for a software product company. Understanding the product from the users’ perspective has proven valuable for helping to build in the quality they desire.
Knowing how the business operates allows you to explore the software in the same ways real end users will use it. Not only does this prevent bugs from going out to production, but testers and other team members with domain knowledge can also give business experts ideas for new features.
A team member with good coaching skills is better able to help less experienced team members. Since everyone on an agile team engages in testing activities, it’s much more valuable to guide others in solving their own testing and quality issues than to just give them the answers.
Telling stories from your own experience is a powerful way to demonstrate how something can be done. It depersonalizes criticism and allows people to remember how you handled a specific problem; they can learn to adapt your solution to their context. Think about how you have handled certain situations and how you can apply that experience to your current context. Storytelling doesn’t come naturally to many people; it takes practice. See the Part II bibliography for references on coaching.
Observing and listening (see Figure 4-3) are critical communication and collaboration skills. Is someone complaining? Maybe it’s a legitimate complaint. Does a teammate have an idea but feels too shy to speak up? Give her a comfortable opportunity to share with you over coffee. Knowing when and how to listen helps the team grow and improve. As Naomi Karten has pointed out (Karten, 2009), listening is a sometimes-overlooked component of being a good collaborator.
We’ve discussed several thinking skills that we find helpful as we engage in testing activities. Be conscious of the style of thinking you adopt for each situation. The next story explains some thinking tools and styles.
See the bibliography for Part II for references to learn more about the ideas Sharon mentions.
Time is always a constraint, so if we’re going to accomplish essential testing activities, good organizational skills are vital. Knowing how to plan and manage your time well, using approaches such as risk-based testing, can help you focus on the right tasks. With so many demands on time, including meetings, email, instant messages, planning, and tracking activities, it can be hard to do actual testing. It’s too easy to end up thrashing, repeating the same tests over and over. Knowing how to organize your time also helps ensure that you have time to learn any other skills your project may require.
Janet’s Story
In Chapter 3, “Roles and Competencies,” we talked about competencies and strengths. I’ll share a personal story about one of my strengths and how we incorporated it into the process of writing the book. We have deadlines that we agreed to with the publisher. Using my organizational skills, I created the release plan and kept it visible so Lisa and I could talk about risks and plan accordingly. I created the shared spreadsheet to keep track of who gave us stories and when they were updated. These simple tools helped to keep us on track; organization is essential in almost everything we do.
Of course, I have weaknesses, too. For example, wordsmithing is not my strength, so often when I have an idea, I convey it the best way I can and then have Lisa work her magic.
Be sensitive to the downsides of task switching as you plan each day. And if you’re feeling overwhelmed, don’t be afraid to ask for help. Agile testing needs to be a collaborative effort.
The collaborative sessions Sharon describes require competent facilitation. Even if your team has an experienced facilitator, understanding meeting dynamics and learning facilitation skills will help everyone on the team get more value from meetings and collaboration sessions.
Thinking skills play a big part in all aspects of software testing. Some of the most important ones to practice include
Thinking differently, and applying different styles of thinking to different testing activities
