Testing Archives - Collaboris https://www.collaboris.com/category/testing/ We make compliance simple Wed, 12 Oct 2022 16:10:06 +0000 en-GB hourly 1 https://www.collaboris.com/wp-content/uploads/2016/07/collaboris_favicon.png Testing Archives - Collaboris https://www.collaboris.com/category/testing/ 32 32 Where to host your SharePoint Test Environment? https://www.collaboris.com/where-to-host-your-sharepoint-test-environment/ Wed, 21 Mar 2012 13:06:24 +0000 http://collaboriscom.wpengine.com/?p=76 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 […]

The post Where to host your SharePoint Test Environment? appeared first on Collaboris.

]]>

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.

The post Where to host your SharePoint Test Environment? appeared first on Collaboris.

]]>
What is Selenium and how can it help me test SharePoint? https://www.collaboris.com/what-is-selenium-and-how-can-it-help-me-test-sharepoint/ Wed, 21 Mar 2012 05:58:34 +0000 http://collaboriscom.wpengine.com/?p=90 What is Selenium and how can it help me test SharePoint?I don’t want to give a full blow account of what Selenium is because it’s very well documented at Selenium HQ, however, I do want to give a quick insight into how it can help you test the UI of a SharePoint application. Quick overview […]

The post What is Selenium and how can it help me test SharePoint? appeared first on Collaboris.

]]>

What is Selenium and how can it help me test SharePoint?

I don’t want to give a full blow account of what Selenium is because it’s very well documented at Selenium HQ, however, I do want to give a quick insight into how it can help you test the UI of a SharePoint application.

Quick overview of Selenium

Firstly, Selenium is an open source testing framework that allows you to emulate the actions of a user when navigating and interacting with a web site through standard browsers (such as IE, Firefox or Chrome). When your scripts are running your chosen browser pops up and can be watched as your steps are replayed back at you. It’s just like watching a user use the application in exactly the same way every time.

Does Selenium have a GUI?

Yes. Selenium has a GUI called the Selenium IDE and will actually record you interacting with a web site. Once you have completed those actions they can then be exported to your chosen programming language. In a SharePoint persons case, this is likely to be C# however you can choose what you want.

Do I use the GUI?

Not much – but it’s very cool. However, very quickly you will find that the GUI approach (in SharePoint) just wont cut it for the more complicated pages. The scripts quite often don’t replay how you want them to, and the XPath statements it produces are too brittle. What do I mean by brittle? Instead of identifying a particular HTML element (TD, Div, Table, etc) via name, id or some more stable selector, the GUI will often derive it based on XPath statements using indexes. If you are going to use Selenium I would strongly recommend you dive in and learn how to programmatically configure it. It’s NOT hard to understand – I picked it up in a day. The GUI is very useful when you are first learning Selenium  as you can record something then see what it outputs.

Does Selenium support SharePoint?

Yes and no. Selenium can test any HTML based web site and as SharePoint is based on HTML this also means you can use Selenium with it. (Although, it won’t help you test any Silverlight components such as the Organization Browser).

Even though Selenium has no problems dealing with SharePoint’s pages and elements it’s a bit of a pain. Most of the major SharePoint pages and objects such as the Document Library page, Ribbon control, Site Actions Menu and Web Part picker use Javascript heavily. You need to know what you are doing and make sure you are clicking on the correct elements at the correct time. The good news is, once someone has been through the pain of ‘mapping’ the elements of SharePoint pages into something that can be tested – we can all benefit. This is where the ShareTest idea came from.

ShareTest and SharePoint

ShareTest is a lightweight framework written in C# that follows the Page Object pattern. The main goal for ShareTest is to provide a ‘page object’ for each commonly used SharePoint page. In the example below, we are returning a list of documents from a SharePoint document library called ‘Healthcare Documents’. Once they are returned (as a list of documents) we are then simply asserting that various values exist. The  ‘SPTDocumentLibraryPage’ has been developed so you can use it with any standard document library.

If we didn’t use page objects, then you would find yourself writing many tests that ‘speak HTML’ making them less readable and more error prone when mark-up changes. Doing it this way – with page objects – we are able to map the page onceand supply a nice abstracted page object to the tester.

[Test]
public void Test_Documents_Are_Displayed()
{
    // defines the path to an Auto It exe that logins.
    this.UserLoginExeName = TestHelper.GetFileNameFromUserType(TypeOfUser.DocReadAdmin);

    // Get all the documents from the library on first page
    SPTDocumentLibraryPage<DocReadDocItem> documentLibraryPage =
        new SPTDocumentLibraryPage<DocReadDocItem>(
            this.driver,
            Urls.Default.SiteUrl + Urls.Default.HealthCareDemoDocuments,
            null,
            this.UserLoginExeName);

    // Returns a list of documents (you can also supply your own entity).
    List<DocReadDocItem> documents = documentLibraryPage.GetDocuments();

    // Normal NUnit test assertions - but now we are testing strongly typed objects
    Assert.That(documents[0].Title == "Alcohol and drug abuse policy");
    Assert.That(documents[2].Editor == @"AD2008R2\administrator");
    Assert.That(documents.Count == 10);
}

Want to contribute to ShareTest?

ShareTest is still young and needs support from others to provide support for other types of pages and objects in SharePoint. Once we get the big hitters well covered, I truly believe that automating UI testing in SharePoint is well and truly on the cards.

The post What is Selenium and how can it help me test SharePoint? appeared first on Collaboris.

]]>
UI Testing SharePoint https://www.collaboris.com/ui-testing-sharepoint/ Mon, 19 Mar 2012 05:58:49 +0000 http://collaboriscom.wpengine.com/?p=83 UI Testing SharePointAs part of an on-going series of ‘Testing SharePoint‘ we intend to share some of what we have learnt when trying to automate the testing of a SharePoint add-on called DocRead. These posts will specifically cover functional and integration testing – not unit testing (which is worth a whole conversation on it’s own). To get […]

The post UI Testing SharePoint appeared first on Collaboris.

]]>

UI Testing SharePoint

As part of an on-going series of ‘Testing SharePoint‘ we intend to share some of what we have learnt when trying to automate the testing of a SharePoint add-on called DocRead. These posts will specifically cover functional and integration testing – not unit testing (which is worth a whole conversation on it’s own).

To get started, I want to tell a story about how I have come to love Selenium, but first a bit of history about who I am. I have used SharePoint seriously since beta 1 of SharePoint 2007 and worked as a developer or architect for organisations such as Collaboris, NHS, Tarmac, BT, Lloyds of London, Lloyds Tsb, Capita, O2 on both versions. I have tried – like lots of other devs – to make unit tests useful and still get the product out on time. I have done lots of performance testing using visual studio web performance tests in my time and actually quite enjoyed it.

Having said that, I have never done functional testing apart from to help out here and there. However, as DocRead is really starting to become the success we hoped for I have found myself looking for ways to get new versions out of the door much faster, cheaper and more efficiently! One area that’s been burning our development teams time is testing. It’s all very organized but very manual. We have really good test coverage, but to run though one set of tests for one version takes 4-5 days. If you think that DocRead ships on SharePoint 2007 (32 and 64) and SharePoint 2010 that’s 15 man days to get a version out! This also assumes that we only have to go through the test cycle once – which never happens. There are always a few iterations of re-testing for either all or part of your applicaiton.

Note. for those of you that don’t know – DocRead is an add-on for SharePoint that allows you to require or recommend that groups of users read a document by a deadline. It has it’s own databases, reporting application, web parts, application pages and features to activate at all levels in SharePoint. It solves a simple problem, but actually requires a very robust solution and has tons of different test scenarios to cater for.

When trying to help the testers come up with an automated solution, my first reaction was to dive in and use Visual Studio Web Tests, but I soon realized that they weren’t going to fulfill our needs. DocRead uses tons of client side code and Ajax calls to make the experience as responsive and smooth as possible. We needed an approach beyond ‘record and play’ that worked at the browser level, not at the http level like web tests do. Enter Selenium.

Firstly, I can honestly say that I have never touched Selenium until 3 weeks ago. I knew a couple of testers that had and only 1 that had used it seriously with SharePoint. In fact, if you Google ‘Selenium and SharePoint’ you very quickly run out of decent results. Why is this ? Let’s think about it. For a tester to automate SharePoint testing they need to know…

  1. SharePoint – this in itself is huge!
  2. How to code – testing has to be automated in some language.
  3. How to test – testing is a real skill, knowing how to structure your tests is very important.
  4. A testing Framework/Tool – Selenium, Visual Studio Test, etc.

That’s one hefty skillset – finding testers with these skills is very tough!  In my opinion, testers also get a rough deal. Developers only consider them when they have time, usually as the first bugs come in. Developers don’t write code that easy to test, (e.g. nice use of CSS, ID’s). And all too often with SharePoint, releases are late due to deployment headaches.

The following sections offer some guidance and help explain the problems we had to tackle along the way – (as I write them I will link them!)

 

The post UI Testing SharePoint appeared first on Collaboris.

]]>