Have you ever worked on a project and found yourself constantly shaking your head? I can say that 99% of the time that I experienced frustration, it was largely due to communication issues within a team. I’ve personally been on project teams and wondered if anyone there had ever taken a basic communications course and learned concepts like active listening, empathy, and being clear and concise. A team that can communicate will find success, but what about those who are not interacting well? Who can help your team get back on track? Believe it or not, your answer is the tester.
The Communication Breakdown
What exactly is keeping your team from communicating effectively? The answer may not be so obvious. In my experience, I’ve seen a few key contributors that include, but are not limited to:
The team does not own quality Of course life would be easier if we could say ‘Well, I did my job! I’m done! Time for the tester!” But how does that foster communication in a team if you just throw something over the proverbial fence? If you set out only to do your job and not to understand anyone else’s, are you really being part of a team? You know the saying — “There is no I in TEAM.” We usually hear that as kids when we first embark in sports, but it goes for software development projects, too!
Not seeing the big picture It is so easy to start looking in an Agile world at the small, granular user story level. But when you start to lose the big picture, the ability to communicate becomes more and more difficult. There have been projects I’ve worked on where I just didn’t understand the business reasons (and I wasn’t the only one). Can you guess how many of those projects succeeded?
Not knowing exactly what to build So many times, I’ve seen (and worked on) projects where a designer says “build this.” The engineer goes off and starts building, and the tester starts writing tests — presumably for the same feature. But if an engineer has a clarifying question and does not include the tester when asking the designer, or vice versa, then what? It’s an easy recipe that gets off track when you work in a silo.
Enter the Tester
Your tester can help alleviate many communication gaps. It just requires a different way of thinking. Take each of the breakdown factors I’ve mentioned, and let’s look at how this QA team member is uniquely positioned to enhance your team’s communication and collaboration.
Everyone owns quality! Yes, you too, engineers... Rather than creating a team that thinks QA alone is responsible for the quality of a product, what if everyone had skin in the game? Of course, part of that is understanding each other’s roles and what the value of testing is. A good tester will work with your team to decide what types of testing need to occur, who can take care of them, and free up those people to take on testing activities. One way to understand this is to take a look at the Agile Testing Quadrant.
If everyone is concerned about quality, and everyone starts talking about quality, and they aren’t just checking out as soon as their task is ‘complete’, you’re already on the path to improved communication. You take it to a whole new level when you get people INVOLVED in quality.
The 30,000 foot view I mentioned before that it’s very easy to get caught in the weeds looking at an individual user story. A tester should, however, know where that user story falls in the grand scheme of things — understanding the business value a feature brings, as well as the impacts it may have on other features. With teams I have worked with in the past, we have invested time in making sure any new QA team member learns the product — not just the one area they are working on. (To repeat, not just be the tester with the product knowledge.) It will be beneficial to anyone on the team, but your tester can help drive the conversations needed to understand the user story, taking a step back to see where it all fits in, and guide testing in a direction perhaps maybe not thought of before.
Everyone on the same page Let’s imagine a world where we all go about building and testing the same product, with the same vision. Is that possible when you work isolated from your team? Let’s look at a central testing practice for Agile teams called Specification by Example (also known as Acceptance Test-Driven Development, or ATDD). The key idea here is that your tester, engineer, and designer all work together BEFORE anything is built to understand the feature, write the tests (your acceptance criteria), and know exactly how the feature will be tested. It is done when all tests pass. Manual or automated, this practice gets everyone on the same page. Your tester can help drive these conversations (I have often gone in with a list of tests, but typically just to elicit more questions and answers with the engineers and designers to get clarity and walk away with more tests — or changed tests, and ensure that we all understand the acceptance criteria as we have now written the tests together).
What are you waiting for? I hope these concepts get you going in the right direction. Use your tester! QA is not just there to execute a test, but is uniquely structured to help foster communication and collaboration on your team, and make sure everyone is invested in quality.
Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.
T: @aahunsberger L: https://www.linkedin.com/in/ashleyhunsberger
