When QA testing fails, the help desk suffers

Contrary to what some managers like to think, the Help Desk is not an island.  A smart help desk manager doesn't (or shouldn't) sit around idly waiting for the Software Development teams to release new or upgraded applications.  If your team is expected to support users of an application, it is reasonable to expect that the application will be thoroughly tested and debugged before it goes into production. 

Sadly, too many organizations cut corners when it comes to quality assurance testing, and when users start uncovering bugs in the system, it puts an undue burden on the help desk. It's the help desk manager's job to make sure the analysts aren't expected to play the dual roles of support and quality assurance testers.

The case study

The reason I'm writing about this is I was working with a call center manager whose team fields thousands of calls per month from external customers.  The analysts use a home-grown application and their external customers use a Web-based interface.  (I was helping the manager create process documentation and teaching her how to write report specifications documents — exciting stuff.)  The manager was feeling serious pain because her customers were furious. "The Sales and Marketing people sent a new URL to our customers so they could go to our new Web site, but none of them could get to it, and they are livid."  I said, "Didn't anybody, oh I don't know, try the URL before it was sent out?"  Apparently everyone in the building was able to get to it, but there were some DNS changes that didn't get made, and the result was people outside the building couldn't get through.  Once the problem was diagnosed, was an easy fix, but the damage was done.  The call center manager and her team felt foolish and were getting beat up by their customers.

Why did this happen? Insufficient quality assurance testing.  No one on the software development team or the quality assurance testing team bothered to check the URL from outside the company, or the problem would have been discovered before the mass email announcement went out.

The call center manager went on to say that "This kind of thing happens all the time. They [software development] makes a change and they don't bother to tell us about it. They don't understand that if something breaks, we're the ones who take the heat from the customers."

"Does your team get to do any quality assurance testing or user acceptance testing?" I asked. That got me a nasty look from the manager, who quickly said "That's not our job. Our job is to support the application, not to test it."

The lesson learned

In hindsight, it seems to me that the call center manager should have been involved in the software development life cycle sometime BEFORE the updated or new application was released to production.  The manager should have been asking her peers in software development and QA, "Is this thing ready? Has everyone who needs to approve testing results signed off on them as complete and correct?"   If you don't get the right answers to those questions, you need to knock on someone's door and insist that the release be delayed until testing can be completed.

Help desk / call center analysts are talented people, but being qualified to work on the help desk doesn't automatically qualify someone to do quality assurance testing.  In this organization, senior management had cut the number of QA testers by not replacing employees who left.  That's being penny-wise and pound foolish in my book.  What they saved in QA salaries, they more than squandered in time wasted by help desk analysts trying to assuage upset customers and write bug reports for code that should have been tested before it was released.

Editor's Picks

Free Newsletters, In your Inbox