VoIP Beta Testing Blues

Points of View

I’d bet you love Beta testing new calling features for your favorite hosted pbx service provider.

No?

I want YOU for some VoIP BETA testing

What am I thinking! Of course – who in their right mind would Beta test a phone service? After all, telephones are the veins of your business, a vital part of its organism. And how would you report a problem if your phone service goes down?

So when your VoIP service provider asked if you would be interested in becoming an important part of their field beta testing program for a brand new set of features in a new release of a product that can still be littered with bugs you firmly said “No, thanks”.

You are not eager to jump on an opportunity to provide that important input, make user interface more friendly, participate in development and even sneak in a feature request that your business will benefit from the most!?. Your business is too good to be running some untested Beta software?

Well, maybe another customer is willing… No? Anyone? Someone?

Fine! You just left your phone service provider no choice! How do you think they are going to conduct field beta of their hosted VoIP service?

They have done all the testing they could in the lab. In absence of Beta volunteers, the next, and hopefully final, stop of our development train will be called “production release”.

That’s right. Some providers will release VoIP services and software, bypassing Beta testing phase altogether. This practice can turn each subsequent software update into a disaster.

VoIP Service Providers Need Beta Testers

Listen, Beta testing is incredibly important. To begin with, Unified Communications are all about software. And VoIP service providers are locked in a race to release more vital phone features to their clients as quickly as possible.

A service provider can test a new product or program all they want in the lab, they can run all the quality assurance experiments and try to iron out all the kinks and attempt to mitigate all the potential worst-case-scenario software-apocalypse scenarios they can think up within the confines of their office, but at the end of the day all this testing will do nothing more than remove the most obvious and apparent problems within their upcoming release.

Clients have the nasty habit of finding a ton of novel bugs within products and programs over the course of everyday in-field use, bugs that never showed their face during controlled lab tests. Service providers understand this bleak reality and find themselves left with two options:

  • Service providers can stealthily unleash an unfinished product or program on their clients and then hustle to quickly handle every unexpected problem to crop up in the first couple of weeks.
  • Service providers can try to implement a fully disclosed Beta test program using clients who are in dire need of new features in exchange for some sort of previously agreed upon benefit.

In an absence of volunteers, most service providers follow the stealth route, the cross-your-fingers-and-hope-it’s-not-too-bad philosophy, the first of these two options. They release a product or program that hasn’t undertaken an official Beta testing period, essentially turning their “early adopter” clients into unwitting Beta testers, which, when you come to think about it, is pretty messed up!

Other service providers may be forced to take a chance with their most loyal clients or the clients who need their new product or program the most, hoping their loyalty or their need will be strong enough to smooth over the fact they’ve just received an unfinished release. ‘

Ethical Beta Testing

So if Beta testing is necessary, and if most clients wouldn’t willingly submit to Beta testing a new product or program for a service provider, then how can a hosted voice service provider complete crucial in-field examination of their software before dropping it on the market?

Well, they may start with putting the software through test themselves. The fact that they opt to use their own software is not only an indication of their confidence in product development team but is also a sign of confidence in their lab testing process. Nevertheless it is still a Beta and the stakes are high. Just imagine a customer calling to inquire about hosted pbx service who suddenly hears choppy audio while on a call! “That’s a bad day, Harry!”

The next step is to put out a call for Beta testers and hope that some of the VoIP clients share their confidence and are willing to try out a new product. After all, some clients may be happy to consciously Beta test a new product or program or even a new feature simply because they want to get their hands on it as quickly as possible and they’re willing to accept its unfinished state or do whatever possible to expedite its release. An iron-clad guarantee of a quick roll-back if their new software performs disastrously will help find Beta testers. However if a client has to go through a rollback at least once, there is a slim chance that this client will ever participate in your Beta again.

Another nice tactic is to employ staged rollouts and minimalistic approach to releases: At first, service becomes available to customers who use minimal set of features. Then, after a period of time the next group that uses broader range and so on.

Dear VoIP Clients…

The next time you decide to look for new business VoIP service, don’t rush to judgement if you suddenly hear something odd on the phone. Give your provider a chance to explain and don’t be shy to ask some basic questions about their development and testing process. If they have confidence in their product or service, they will have nothing to hide.

If you believe in your service provider’s practices, give VoIP Beta testing some consideration at least once in a long while. It is a necessary evil and it will help make your voice product better.