4 Reasons Vendors Neglect Testing WebRTC Services

Testing WebRTC is tricky.

If there’s something I learned this past year from talking to companies when showcasing the testRTC service, is that vendors don’t really test their WebRTC products.

Not all of them don’t test, but most of them.

Why is that? Here are a few reasons that I think explain it.

#1 – WebRTC is a niche for them – an experiment

You’ve got a business to run. It does something. And then someone decided to add communications to it. With WebRTC no less.

So you let them play. It isn’t much of an effort anyway. Just a few engineers hammering away. Once you launch, you think, you’ll see adoption and then decide if it is worthwhile to upgrade it from a hobby to a full time business.

The thing is, there’s a chicken and egg thing going on here. If you don’t do it properly, how will adoption really look? Will it give you the KPIs you need to make a reasonable decision?

WebRTC is rather new. As an industry, we still don’t have best practices of how to develop, test and deploy such services.

#2 – It’s a startup. Features get priority over stability

Many of the vendors using WebRTC out there are startups. They need to get a product out the door.

It can be a proof of concept, a demo, an alpha version, a beta one or a production version. In all cases, there’s a lot of pressure to cram more features into the product and show its capabilities than there are complaints about its stability or bugs.

Once these companies start seeing customers, they tend to lean more towards stability – and testing.

As we are seeing ourselves by running testRTC (=startup), there’s always a balancing act you need to do between features and stability.

#3 – They just don’t know how

How do you test WebRTC anyway?

VoIP?

If you view it as a VoIP technology, then you are bound to fail – the VoIP testing tools out there don’t really have the mentality and mindset to help you:

• Testing browsers continuously because they get updated so frequently isn’t something they do
• They don’t really know how to handle the fact that there’s no signaling protocol defined

The flexibility and fast paced nature of the web and WebRTC aren’t ingrained into their DNA.

Web?

If you view this as a web technology, then you’ll miss all the real time and media aspects of it. The web testing tools are more interested in GUI variability across browsers than they are with latencies and packet loss.

• How do you different network configurations? Does a firewall affect your results?
• You do know that you need multiple browsers for the simplest use case testing with WebRTC. How do you synchronize them within the test?

While web tools are great for testing web apps, they don’t fit the VoIP nature that exist in WebRTC.

#4 – They don’t have the tools

You know, if you wanted to test WebRTC a year or two ago, your best alternative was to use QA teams that click manually on buttons – or build your own test infrastructure for it.

Both alternatives are wasteful in resources and time.

So people sidestepped the issue and waited.

These days, there are a few sporadic tools that can test WebRTC – changing the picture for those who want to be serious about testing their service.

Don’t take WebRTC testing lightly

I just did a webinar with Upperside Conferences. If you want to listen in on the recording, you can register to it online.

Whatever your decision ends up being – using testRTC or not – please don’t take testing WebRTC implementations lightly.