Are you launching a new contact center and thinking of running a load test to make sure it works? Load Testing is not just about throwing 100 or 1,000 or even 10,000 calls at a solution to see what happens. That's taking the "let's see if this breaks it!" approach, and like I've mentioned before, that becomes a self-fulfilling prophecy.
Many of our customers have been surprised to find that preparing for "the dreaded load testing event" can actually help everyone, employees and vendors alike. Everyone benefits (including end-user customers) when you approach testing as a team effort instead of a series of isolated exercises to generate reports, which can be used to beat up vendors & colleagues later.
(Warning … necessary plug approaching) Telnet Networks works with Integrated Research who pioneered the team testing approach for contact center load testing. So we know from experience that a successful contact center launch starts with common objectives and widespread, shared understanding. This doesn't happen by luck – it takes effort & guidance (and the earlier you start the better). It is still exciting for us to see how the techniques we use to prepare for a load test also encourage everyone on our customer's team to invest some skin in the game. Talking through what's supposed to happen – from the end-user customer's perspective – really helps the team get their collective head screwed on straight. It's all about the customer experience, not just the CPU consumption or the routing plan or the VLAN partitions. If it doesn't all work together when hundreds or thousands of customers each try to do their own thing, it really doesn't matter if the web services building block works in isolation or under twice the load as expected. You can't imagine how many times we've been in the early stages of a test engagement and heard astonished customer team members say to each other "You expect it to do what?!?"
No, really.
But that's great news! Because it happens during a test planning session, not at 10:30 AM on the morning the system goes live.
One of the key items we review (which seems so obvious to the team after the fact) is the list of who's responsible for everything – internal and vendor – and making sure each person is plugged into their piece of the action when we start to light up the test. For example, routing and hunting are huge, whether you're doing it yourself or counting on a toll-free network services provider. You want those resources online & participating during the test activity – not just available by pager or cell phone. Because if there's an issue and Theo isn't available to (1) dump the logs before they roll over, (2) interpret the results, and then (3) fix the translations right now, you might have to bring down the curtain. Then you'll be making plans to do it all over again tomorrow night or next week or probably when you've promised to chaperone your kid's traveling soccer tournament.
By preparing for contact center load testing early in the process, you start considering critical questions that can impact everyone on the team but that might not otherwise be discussed. Which applications are the riskiest, which data feeds the most tenuous? How are the various sites supposed to function, individually and collectively? Caching? Record locking? How do we find out if the SIP trunks really can handle the same burst rates that PRIs dealt with? Early contact center load test discussions seem to help everyone:
- Stay focused on the real business objectives
- Have a keen understanding of their role/their components role in meeting those objectives
- Clearly see where responsibility for any issues lie
- Pitch in where possible to get things resolved and working so testing can continue
- Have a shared understanding of what a successful launch will look like
Go through the load test planning and setup process in a methodical fashion. It gets your team on board, you're prepared to handle just about everything and you've probably addressed a myriad of issues before you've even launched the first test call!