The importance of cross-team communication in quality assurance: A developer’s perspective

At Lucidchart, we take quality seriously. Over the past few years, we’ve greatly improved our test automation frameworks, especially our JavaScript tests, for which we now use the Jasmine framework, and our selenium tests. Our Quality Assurance team has grown, and we’re catching a lot of bugs before they reach customers. But bugs are slippery, and sometimes they make it past these increased testing measures. When they do, we encourage cross-team communication to get fixes out to our customers as quickly as possible.

As our first line of defense, we have an awesome customer support team that is always happy to resolve issues, but if it’s an actual bug in the code, not a misunderstanding over a feature, there’s not much they can directly do. Sure, they can confirm the bug and send in a bug report on behalf of the customer. A product manager sees it eventually, and, not realizing the magnitude of poor experience caused by the bug, they might assign it to a sprint a month away or more. When the issue finally reaches the programmer, it might be as easy as a two-minute fix, or it might be more involved. Regardless, the customer has probably waited a month, if not more.

That’s where communication comes in. By talking directly to a product manager, the support team member can make sure the issue is prioritized correctly, and possibly taken the very next sprint. But the product manager doesn’t need to be the only decision maker on the bug’s relative importance and complexity. In fact, that forces them to make a decision without all the relevant facts.

When the product manager informs their team (at Lucid that’s made up of software engineers and a Quality Assurance Specialist) of the problem that’s happening right then, it’s an opportunity to gather information on how quickly a fix can make its way to the customer. Only someone familiar with all the ins and outs of the code base can give an accurate time estimate for an issue.

Customer issues fall into two categories: quick fixes and long-term adjustments. A developer can take a few minutes to let the product manager know where the current issue falls. If the issue is a quick fix, there’s no need to wait a full sprint cycle. I’ve had several issues pointed my way before they have made it onto a sprint, and I’ve been able to fix all but one of them in a few minutes and get a fix out to the customer almost as fast.

As an engineer, it’s easy to get accolades for writing new features, and it’s always fun to work with new languages and frameworks; however, when any part of your product has a bug, it’s the customers who suffer. Without regular communication with support and product management, it’s easy to see bugs as non-existent, or, at the very worst, not really affecting anyone. By having regular discussions with team members from different disciplines, it becomes easier to improve quality and internal understanding of the product.