I just read a Twitter exchange between @michaelbolton and @adampknight where they mentioned that “testing” problems are often really communication problems. Personally, I find that a big part of my job as a tester is facilitating conversations between the development team and business experts.Different people may have different interpretations of the same set of requirements, but don’t realize they’re not all on the same page.When something like that happens, I try to get all interested parties together – preferably with a whiteboard – to talk about it.
Here’s a recent example. We had just started work on a new theme, and one of the user stories had particularly complicated and confusing requirements. A programmer came to tell me that he and another programmer felt that the story was unnecessary, as it was designed to capture information that wasn’t used anywhere else in the system. He said the story’s main stakeholder had agreed, though he hadn’t been able to talk to our product owner yet. I had a feeling that the stakeholder was forgetting something.
Our product owner is a busy person, but I finally tracked him down later that day. He still believed the story should be done, with the original requirements. I went and got the stakeholder and the two programmers, and we congregated in the product owner’s office to talk about it. After a ten-minute discussion, everyone understood that the user story was still needed, but the most complex part of the requirements could be dropped, and a much simpler solution implemented. This enabled us to finish the story in about one-third the time, while still satisfying the business needs.
Sometimes when I tell a story like this, people ask, “Is it really your job to call impromptu meetings? Shouldn’t the manager or ScrumMaster be in charge of that?” In my opinion, when you follow the whole-team approach to software quality, anyone should feel free to get all the right players together for a quick conversation whenever needed. Testers are always looking at the software from multiple points of view, thinking about the value each user story brings to the business, how end users will behave, and whether the technical implementation is appropriate. So, we often catch missed assumptions or incompatible requirements.
If I suspect miscommunication, I don’t start an email thread. I get up and go talk to people in all the different roles that need to have input. We gather together, draw on the whiteboard, video chat onSkype with any interested parties who aren’t physically in the office, and resolve the issues. Good communication early and often saves a lot of time and bug reports later!
Author Profile – Lisa Crispin
Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009). She has worked as a tester on agile teams for the past ten years, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine. For more about Lisa’s work, visit www.lisacrispin.com.
No comments yet.