Where to host your SharePoint Test Environment?

To test the UI of a new or existing SharePoint application you are going to need somewhere with the latest build on it. By 'build' we mean the code that your developers have written and compiled into something that can be installed, or deployed into SharePoint.

Let's assume you have a package of the 'latest change' in your hands and are ready to stick it somewhere. Where do you put it?

Where to host your environment?

When deciding on where and how to do your testing - there are a few options to choose from such as:

• An environment on-premise
• A virtual environment on-premise
• A cloud-based environment

This decision is very important, and a few factors need to be taken into account.

Cost. You need to think about how much 'kit' you need, software licence costs, costs of a server admin guy to set-up.

Reliability. Obviously, if you are testing throughout the life-cycle of a project the kit needs to be reliable.

Ability to base-line to 'live'+. This is THE main feature I would always want. Over the course of a project your testing team will test daily. As SharePoint is effectively a CMS - content can affect the tests. For example, you may have a test case that 'Adds XYZ Web Part to page', 'Check in' and the go delete some documents. This is fine the first time, but what happens the 2nd time? You now have a web part already added and have removed some documents. See section on 'Snapshots and Virtual Environments'.

Support. If something goes wrong with the environment (or SharePoint) who is there to help?

Time to set-up. I have worked in some orgs where it literally takes 6 months to build a farm out of VMs - can you wait this long?

Complexity of your application under test. We touch on this below, but there are a few reasons why Cloud may become trickier than on-premise, although not impossible.

Connection to the net. If you choose cloud - you will need a blistering fast connection, especially if you have a lot of automated tests. You may also need to upload huge test db's which will chargeable beyond the standard sizes.

A note on Snapshots and Virtual Environments

To test DocRead we create a 'demo environment' with all of the staging data we need. This includes these types of artefacts:

• Test Users - created in AD and assigned permissions in SharePoint
• Test Web Apps, Sites and Webs
• Test Lists libraries
• Test Pages
• Groups and Audiences
• Service App config

Once we have this all defined and setup in SharePoint, we document it in a spreadsheet and then create a snapshot. Once this snapshot is created, this means that at any point we can revert back to a base-line in minutes rather than weeks. This gives us the confidence that when our tests run and bugs are raised, it's very unlikely to be down to environmental issues. For this reason alone, I would never use a physical environment for testing, unless you are considering a load / performance test.

On-premise or in the Cloud (hosted)?

Everyone's circumstances are different, but we choose to host our test environments with CloudShare and here's why.

• We don't need to worry about physical environments or low-level networking - their guys do it.
• It's cheap. I think it currently runs at about $50 / month (and you get the required licenses).
• You can snapshot an entire environment in one go or on a machine by machine basis.
• You can share enviromental 'clones' with other users very easily.
• There are tons of starting points to build up from.
• This is their business and they know what they're doing.

If you need to know any more about how we test DocRead using Selenium and ShareTest at CloudShare please see our other blogs. UI Testing SharePoint

We'd also love to hear about your experiences.