Here’s the setup: A product or technology exec gets everyone energized about WebRTC.  It may be a contact center video chat experience added to a web commerce site, a media sharing mobile app, or other use case.  The executive is smart and driven and manages to push through a business case to get a new product launched. Great!

There was functional testing, and application load testing but WebRTC testing of media experience wasn’t covered. Why? Well, the QA team knows web app testing inside and out, but didn’t know how to really test WebRTC. Besides, the team thought, this is a new thing and we really don’t have a good way to predict customer adoption.  So, let’s assume moderate volume and see how it goes.

To some, this may seem ad hoc, but in reality it’s pragmatic when the team uses agile development, a DevOps model and scalable cloud hardware. They are watching the analytics. The team can react to scaling issues if the product takes off and quickly add features based on real life use instead of trying to guess at the beginning (which really doesn’t work).

So, now the product is in and it’s getting some great traction. The trouble is, the WebRTC video experience is bad.  There is excessive jitter, or the video start-up time is slow because it’s not efficiently connecting to the right TURN server.  Maybe someone connected a camera with an unexpected format or a user upgraded to a new browser.  Whatever the reason, the customers are not happy.  The app has analytics to track user flow, the servers are watched for CPU and memory. Even the log files are scanned but it’s all after-the-fact. Problems with the WebRTC experience are detected indirectly and slowly, or maybe not until the customer complains. Customers, of course, are a bad service assurance tool.

The piece missing is effective WebRTC testing.  WebRTC testing is unique and separate from web application testing, application performance management or network monitoring.  That’s the hole Mersoft test™ is designed to fill.

Here are three ways it can be used:

1. Proactive monitoring: Mersoft test™ can be configured to periodically create simulated clients that generate traffic and report issues.  If the product is geo-diverse, the clients can be created regionally or even globally to ensure that traffic is passed through specific load balancers or data centers.  Armed with PCAP files, log files and the ability to play back recorded video, the support team can find a root cause fast.  Problem solving accelerates when they can easily compare a WebRTC testing alert from Mersoft test™ with application performance monitoring data from other tools and quickly find a firewall problem, load balancer issue or server capacity issue.
2. Troubleshooting or Ad Hoc WebRTC Testing: The same scripts in the proactive monitoring or different scripts can be used to verify an application after a production event. It’s easy to see if a problem has been resolved or even to generate more troubleshooting details by running tests manually.
3. Continuous Integration: Include Mersoft test™ in the continuous integration process to execute WebRTC testing along with any other verifications before a new software build is deployed to production (or any other environment for that matter).

We recommend creating scripts for load testing or environment testing prior to production launch. It’s helpful to do it this way so the tests behave as intended before they hit production.  A blog on that topic is here. By using the configurable parameters in Mersoft test™, it’s easy to set up new environments to use with the same scripts. Consistent, efficient and proactive. Want to learn more? Let’s talk! Visit Mersoft.Com, email info@mersoft.com or call +1-913-871-6200.