A Case for Support

A Case for Support

After the first AQA presentation I ever gave I was approached by a member of our Support team. He asked a simple question: “How can QA and Support work together to better enable customer success?”. I paused, as I suddenly realized that as simple as the question was, it had never been asked in any organization I’d been apart of before.

While Developers often see the product at it’s best, Support sees it at its worst. Support knows where your product breaks. All the time. Every deploy. And there’s an angry customer who delights in pointing this out on the phone every two weeks. This is an invaluable perspective for QA who often also only see things in an ‘ideal’  working environment devoid of real-world data.

As software becomes more complex and is pushed to market ever faster, bugs are as likely as ever to slip through the watchful eye of QA even with fancy AQA. And as the quote goes, “if you don't test your software, your customers will.” Like QA, Support catches bugs - they just catch them after the customer finds them. So it makes sense that there should be some crossover right? But when’s the last time you heard of a bug from Support?

DevOpS - Increasing the Visibility of Support

For most people on a development team, Support is something ‘other’ - it’s some nebulous team that deals with customer complaints and implements mini-patches to fix customer-specific issues. Support, I’ve found, has about the same opinion on Developers - that they are some nebulous team that makes broken software that customers complain about. Never the twain shall meet. With this kind of structure, how can Support and QA work together? As a QA, I don't even know how to get in contact with my Support team. Even if I did, would they know what to do with my presence? Probably not.

This needs to change at a fundamental level. Just as QA was subsumed as part of Development many years ago, and Operations became more integrated as part of the development process as part of DevOps, now I believe it’s time to make the S stand for Support and integrate them as well.

Open a Link

The first step is creating a link between your development team and Support. Send a ping, reach out and let them know you exist and that you want to work together. Maybe there’s larger organizational or process barriers preventing this from happening - break down those silos, they’re not doing anyone any good. Once that barrier is gone, you can begin putting faces to names and start sharing information.

Opening the Backlog

A major problem we found was access to the backlog. As Support, they had no access to our backlog or bug reports or even our internal documentation - no way to know if what they was seeing at a customer site was an already logged bug and no way to log the bugs they found. This created frustration out of the needless back-and-forth with the Development team and slowed the resolution process with the customer.

From a QA perspective, this is silly. Support can have valuable insight into a bug. They may find totally new bugs we missed. They may be able to see a bigger picture of how an existing bug manifests. They may find workarounds that the development team can use to fix it in the future. This is all extremely valuable information - and perhaps more importantly it’s wasted work if it’s not visible outside of the Support person that did it.

Opening the backlog, combined with regular communication, lets the Support team know what’s coming down the pipeline, what bugs have already been logged (and their resolution status) and gives them the capacity to raise new issues.

A Place at the Table

Just as QA has a voice at the table to state how severe a bug is and advocate for how critical it is to fix, Support should be a allowed the same. They find bugs too - often bugs that transcend product versions and plague a specific segment of customers for years.

You may be amazed at how small quality of life improvements can do wonders for the customer  - one bug I heard about that was well known in Support involved how the project packaged base data. The data included special characters and there was one customer that could not consume it properly, so every time a new release went out Support knew they had to go in and alter that data file or it would not deploy properly - which caused delays for the customer. A simple change in that base data file eliminated a huge headache for everyone involved.


AQA can play a role for Support as well. AQA creates a number of automated scripts that can load and manipulate data throughout the system. Of course, AQA uses that to test the system, but there's no reason Support can't use them as setup or teardown scripts to clean client sites (or teaching them how to develop their own based on your framework). By making the time to help work with Support, you can make everyone's lives easier - especially the clients.  

Everyone’s on the Same Team

Remember, and this is key. At the end of the day, we all want to see a functioning product. Maybe because we have pride in our work, maybe because we care about the project or the people that will use it, maybe only because someone is paying us and if it doesn't work we won't get paid. Reasons may differ, but the end goal is the same.

Engaging Support as part of your development process can help drive a higher quality product. At the very least, it certainly won't make it any worse. So have you talked to your Support this week?

Vermont Code Camp 2018

Vermont Code Camp 2018

AQA Classes and Certifications

AQA Classes and Certifications