QA and support are very different roles. But in many organizations, it’s not uncommon for QA and support to work together in some capacity. In fact, in smaller companies you might even find one person responsible for testing and support. This doesn’t scale very well, but I’ve definitely seen it happen. In fact, I’ve been that person.
There’s actually a direct correlation between QA and support. If things aren’t tested properly before they get released, customers will contact support to report bugs. When support becomes aware of issues, they might go to the QA team and ask them what’s up… “How’d this bug slip through?”.
When Support is QA
When Support is responsible for QA (and vice versa), there’s an immediate incentive to test thoroughly. For example, if I’m responsible for testing and support, you can bet I’m going to do my very best to ensure no major usability issues slip through the cracks.
QA and Support – Agile vs Waterfall
Traditionally, support and QA are separate roles. Also traditionally, there are often “walls” between the QA team and the rest of the company. This barrier, often referenced as “throwing code over the wall”, leads to silo-ed information. While you can get away with this using the waterfall methodology, this lack of cross-collaboration and communication is detrimental to agile teams. This, in fact, is not agile at all.
In agile settings, support and QA need to talk to each other. Here’s why/how.
1. The QA team can conduct feature handover for support.
When agile teams have a dedicated QA team, they are often the last ones to see the feature before it goes live. But that shouldn’t be the case. Releasing a feature without looping in the support team is like . This is where a support handover document can be valuable.
2. QA and support can do paired testing.
Pair testing can often replace the support handover document for smaller features. Sometimes a handover document might not be necessary for small changes.
3. Sometimes support needs to test hot-fixes.
By nature, support is very reactionary. They are constantly putting out fires. Sometimes this means dealing with bugs – and the angry customers who report them. This means support might take the role of QA for hot fixes.
There’s a cultural advantage to QA and support having a good relationship. I’ve worked at companies where developers and QA didn’t talk to anyone else. You know what that is? A toxic culture.
QA and support working together promotes a healthy, collaborative culture.