Developing a deployment test plan

checklist Developing a deployment test planWhen you are on-site at a customer’s location finishing up a deployment, its all too easy to make the common mistake of forgetting something. Many times we (myself included) overlook some detail that causes a frustrated phone call early the next morning that needs to be fixed immediately. A simple solution to avoid this common pitfall is to develop a deployment test plan.

What is a test plan?

Simply put, a test plan is a written set of steps that you will take to test the system at the end of the deployment to ensure that everything is working as planned. Does the dial plan work properly? Are calls getting routed properly? The nice thing about a good test plan is that once you have one that you are happy with, you will be able to reuse it on virtually every install with little to no modification. I would also encourage you to have a place at the bottom for the client to sign the test plan to show that they have agreed that the system is in complete working order.

checklist2 150x150 Developing a deployment test planWhat needs to be tested?

Well…everything. Fortunately, for most deployments, the entire test plan should be able to be run through in just a few minutes so long as the inbound call flow isn’t overly complicated, however, missing one thing on our list can be the one thing that can cause a client to be calling you in a panic. Let’s take a look at each piece of a typical test plan and how we can go about testing each one.

Extension to extension dialing

This is about as straight forward as it gets and is the simplest thing to test. Make sure each extension when it comes up can dial another extension that is online.

Voicemail

Testing voicemail should include the ability for the phones to have one-button access to the voicemail system as well as voicemail to email configurations to be working properly.

phone 216x142 custom Developing a deployment test plan

Local and Long Distance Calling

This test should ensure that calls to local and long distance numbers are working properly. Local numbers should be able to be called with seven digits and long distance numbers should be able to be dialed with 10 or eleven digits (with or without the preceding 1). Of course, the actual number of digits is determined by the country that you live in.

Test international calling

While not everyone will need to place international calls, its always a good idea to make sure that this works properly just in case. Find a couple of phone numbers for companies in other countries and make sure your dialplan allows for those numbers to be dialed.

Test toll free calling

Here in the US, we have several different area codes for toll free numbers, 877,800,888, you should make sure that calls to these types of toll free numbers can be called.

Test inbound calling

Often testing inbound calling will be the longest test of your entire plan. For this section I would suggest pasting in the flowcharts of the call flow that you used to program the system and ensure that calls are answered and routed to all of the destinations properly.

Test ring groups and call queues

This should be a subset of the previously mentioned test to ensure that calls go into and out of call queues and ring groups properly.

emergency Developing a deployment test planTest emergency services dialing

While you may think it is a little odd to dial your emergency services number (911 in the US) as part of the test plan, this is something that most certainly should be done. You do not want the liability on your hands should someone need to dial emergency services and the dialplan doesn’t work. The way I handle this is to simply call 911 and when the operator answers I quickly state “We are testing emergency dialing on a new phone system”, the operator will almost always simple say “Ok” and you are good to hang up the call. If you dial and just hang up, there are good chances the police will show up to make sure everything is alright.

Test paging and intercom

One of the final steps is to test your paging and/or intercom services to make sure it is all working properly. You may or may not have multiple zones to check, overhead systems, bullhorns, etc.

Get It In Writing!

At the simplest level a test plan simply ensures that everything is actually working properly. The benefits of a written test plan go well beyond that however. A test plan will increase the appearance of professionalism to your client and shows them that you really care about the success of their installation. By getting a client’s signature on the completed test plan assures your client the system is working properly but also gives you a recourse should they complain later on that some feature isn’t setup properly, this is especially important in situations where the client has administrative access to the system and has the ability to break something.

Summary

Most of this is most likely things you would have thought to test anyway, but creating a written test plan will ensure that everything actually IS tested and is working properly. It’s very easy to miss something simple when you are in a hurry, tired, or pressured to meet a schedule. No client is going to argue with walking through a written test plan to ensure that they are getting what they expected. If you have other suggestions for things to be included in a standard test plan, please leave some comments below.




Tags: , , ,

Similar Posts

This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.

Comments (3)

Trackback URL | Comments RSS Feed

  1. Paid online SUrveys says:

    I overlook some detail alot a test plan is a good idea i am going to start useing your info and make a test plan my self

  2. Verónica says:

    Very true, you tend to forget small things that after you finish the installation they come back to hunt you

  3. PJR says:

    You may also wish to test:

    * CLI’s are displaying correctly (if you have different CLI presentation setup from different extensions)

    * Internal to External transfers work (blind and attended)

    * Phones show correct date and time

    * Any call overflow and out of hours routing works as expected

    It’s also worth noting things like avg ping response times to your SIP trunk provider whilst installing onsite. That way you have a reference/benchmark to refer to if ever the site experience quality/latency issues further down the road?

Leave a Reply




If you want a picture to show with your comment, go get a Gravatar.