Part of our work in the Domain Consulting team is to advise Cyara customers on their Agile/DevOps journeys. Through this process, we've identified a path to DevOps in the contact center that I'd like to explore in more detail.
In this first post of a three-part series, I will talk about putting in the guard rails with design-driven assurance. In part two, I'll talk about how to accelerate the delivery of value whether you're doing an automated deployment or configuration of off-the-shelf contact center software, or implementing cloud contact center software. In part three, I'll cover ways to reduce the cost of failure, whether through building solutions with testing and monitoring in mind, automated deployment and configuration, or using test data in production.
Putting in the Guard Rails
At Cyara Xchange 2018, we heard a great breakout presentation from Steve Hares at eBay about the importance of 'shifting left' and identifying defects as early as possible in the software development cycle. He and his team identified that there was a greater benefit to focusing on quality during the development phase — instead of focusing on it in the testing phase, where defects are much more costly to fix. To that end, they found they needed to create better requirements from the beginning. Steve's presentation reminded me of a basic concept in software testing: whether you're following an Agile, DevOps, or Waterfall model, you need to have strong foundations.
Design-Driven Testing and Assurance
Building and Implementing with Automated Testing and Monitoring in Mind
I've covered alignment and building quality in from the start, but when you're using automated testing and monitoring, you need to keep in mind that these systems don't deal well with variability. That means you need to plan for that in how your system behaves when you're testing it. For example, you may have a solution that says if you identify a call as a repeat caller, it will be handled differently from a first caller. However, you would not want that to be triggered when you're testing with Cyara — you don't want the first call of the day going one way and the second going another way. You want to know that first callers or repeat callers are consistently going one way or another.
Another scenario may be one where you want to test that your routing works without impacting agents. To do this, you would add logic that identifies synthetic testing or monitoring calls so they go to virtual agents that you've configured, not live agents. On the flipside, you may also want to make sure live calls don't go to virtual agents. And if you're making monitoring calls, you don't want them to be reflected in your reporting because that's going to impact your KPIs. You want to easily identify monitoring calls and exclude them from your reports. Those are two examples of where you need to implement the solution with automated testing in mind.
For more information on Velocity, watch the video.
To learn more about how Domain Consulting can help you, contact us, or get in touch with your Account Executive.