In a previous diary, I spoke a little bit about how testing looked before I moved into the development team room. “Throw it over the wall” was a pretty accurate description. A product spent months in development, sometimes over a year. Then, when it was getting close to ‘done’, the test team would get their first look. We’d install it, get acquainted with it, have a review session to learn what it was for, and then start asking questions. Once the review session was over, we picked through written user stories, trying to test them as best we could, and started writing defects.
New development continued while the testing group worked. We would pick up user stories, test them, and write defects. Development would continue working on new stories and the defects written by testers. Eventually, the list of issues became overwhelming, and time would have to be spent evaluating, fixing, and testing defects. Often, bugs were thrown out because they represented a misunderstanding of the intended behavior. Occasionally, a defect revealed a major flaw in how the feature was designed. As the deadline for the product release drew near, we’d have to drop scope, and that often meant shipping without features we had hoped to include and with a list of known defects.
The most important part of the story above isn’t that we shipped with defects or without features, or that we were working in silos. It isn’t that that we wrote lots of bugs, or that we didn’t see the product while it was being developed. The most important part is something that you know implicitly but isn’t stated at all: The testing group didn’t have a strong culture of communication with our development team.
Get TestRail FREE for 30 days!
Overcoming Fear
For most of the time on my current test team, each tester worked in a private office. Since each tester was in a private office, we didn’t speak to each other that often. We were such a small group when I started that we didn’t even have meetings. We just each walked into our respective offices each morning, did what we thought we needed to do, and left. If anyone had a question about what we were testing, we generally asked each other first. If we didn’t know the answer, we asked our boss, the product manager. If the product manager needed to, he would consult development and get back to us.
As our team grew larger, and management changed, we started hearing that we should talk with development ourselves in some situations, instead of going through the product manager. If a tester wanted to better understand the implications of a change, we were encouraged to ask the developers directly. If someone had questions about the user story and how it was addressed, we asked development.
We were just a few steps away from the development team room, so this should have been easy. I can’t speak to how the other testers felt, but to me, walking into the development team room was scary. Admittedly, I’m not the most socially comfortable person in any situation. Walking into the team room was different. I worried about being a disruption to the important things happening in that room. At some point during my onboarding, it had been made clear to me that the developers were to be disturbed as little as possible, and that really stuck with me despite the new mandate that we should be talking with them.
Breaking Barriers
As time went on, we recognized the benefit of having collaborating more closely with the developers. Testers were finding defects sooner, because we were asking more questions as we read user stories. We were writing fewer defects that would later be rejected, because we understood the expected and intended behavior through discussion.
It was difficult to break down the cultural barriers that had been created over time, and we were still having to begin discussions long after development was completed, making those discussions harder.
The development team was first to propose a solution: what if we had at least one tester start sitting in the development room?
As a result, at the start of our next product, I was asked to begin working in the development room. My work would still be separate from development, but in addition to being able to hear the conversations that were being had around new work, I was asked to participate in reviews for each user story. There would be a review both before work began and after work was ‘completed’ for each user story, and during each I am encouraged to ask questions.
Throughout product development, I have felt more comfortable in my understanding of the product. During each review, I’m able to ask questions that either improve my understanding of how features are supposed to work or generate discussion that reveals something that hadn’t been considered and could have produced bugs. I often ask questions during the final review of a user story that reveal some acceptance criteria that hadn’t been recorded. And best of all, when I’m testing, I’m able to just turn around and ask “Umm…is this doing what it’s supposed to?” directly to the developer that I know worked on that section. My testing still runs behind development, but generally the person I ask about a feature worked on it within the last couple weeks instead of months ago. Working so closely with development has improved our ability to collaborate deeply.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
A World of Difference
On our team, the movement toward collaboration came from development. But if I could go back and talk to myself four years ago, I would tell myself, “Don’t be afraid. Talk to the developers. Ask questions. You’re not wasting their time, because they want to help. Ask for reviews before the work is done so you can ask questions when they are most useful.”
This way of working is much closer what good testing looks like to me. Best of all, I feel really appreciated and fulfilled in my contributions to the team and to the product in a way that I didn’t before. It’s amazing what a difference collaboration and a culture of communication makes.
This is a guest posting by Carol Brands. Carol is a Software Tester at DNV GL Software. Originally from New Orleans, she is now based in Oregon and has lived there for about 13 years. Carol is also a volunteer at the Association for Software Testing.
