How an Agile environment can make testing more effective

As a tester I take great pride in knowing the work I do contributes to a client getting what they want. Yes you heard that right WHAT A CLIENT WANTS! Not what a long drawn out technical specification tells me they want, but actually what they want and need from their product. Is it really that hard to ask a client this simple question?

As a tester in a waterfall environment one of the most laborious and soul destroying tasks was writing the dreaded test script! Spending hours trawling through huge technical specifications and planning test routes, picking out holes in requirements, then spending days on end writing the script only to find you have to constantly have to re-write and update it. Then you still have to run all the tests! With all of this to do and deadlines looming you can see how QA always appears as a bottleneck in the development lifecycle.

“One small change” in a product can mean hours of re-work for something that is fundamentally quite small. In a waterfall environment the word “Change” sends shivers down a tester’s spine and is always met with resistance with the usual comeback of “That’s not what the spec says” as the tester knows this “One small change” always leads to huge amounts of work, updating scripts and regression testing. Why are testers so adverse to change as we are here to make sure the client gets what they want?

The reason behind this is we don’t like wasting our time as we always have deadline pressures being last in the chain. So how can a tester be more efficient and respond to change easily and ensure your client is happy? It’s pretty obvious that the easier it is to adapt to change and the more time testers spend actually testing the product, the better the quality of the product. The better quality product that meets the expectations of the client leads to you guessed it…… happier clients. So how can testers spend more time testing and adapting to change without missing deadlines? Be Agile and Innovative!

Ask yourself “WHAT IS MORE VALUABLE TO THE CUSTOMER?”, a product that has been thoroughly tested in all manner of scenarios and provides the customer with the functionality they require or a product that has been tested following a rigid test plan but does not fit the requirements of the user because you have not been able to adapt to changes that they require?

So how does an Agile approach help testers be more adaptive to change? Agile has provided a great platform for testers by providing them with a constant workflow of iterative chunks, these chunks can be thoroughly tested in isolation quickly and efficiently. Using an Agile approach, continuous feedback allows us to test little and often, making change simple and cost effective. By the time the work goes to UAT for final acceptance with the customer, most feedback has already been dealt with which mostly results in a simple confirmation of acceptance criteria. This provides QA a real opportunity to understand early on in the project the client needs and expectations and build a valuable relationship with the client which is crucial to the success of a project.

Using tools within an Agile environment to be more efficient is an excellent way to increase the team’s effectiveness and reduce the “QA bottleneck”. By working smarter you can relieve the test script burden. I am not saying you have to abandon test scripts they do have value in their own right as they provide anyone who cares to read them an insight into how the product should work and provide detailed information on legacy products, but you can be smart with how you document! For example creating automated test scripts that cover your essential tests provides anyone an insight into how the product should behave, but this script has more merit than a standard manual test script. So how does this magical time saving test script get created so quickly and easily? Adding automated tests to your script is not a long and boring task as it can be recorded whilst you are testing a new iterative chunk of functionality, as each iterative chunk is delivered to QA your script keeps evolving as each iteration passes until you have a fully automated regression script! Finally a document that actually helps people rather than hinders!

These simple changes make the life of a tester much more productive, reduces waste of resource by not having to sit around waiting for builds! It also provides better overall quality and happier clients. Not to mention make the life of a tester much more enjoyable and less stressful.

Using WatiN to automate Sitecore

As a tester, one aspect of my job that takes up a lot of my time is regression testing. This becomes even more of a problem when we have to upgrade Sitecore to a new version. This can often take days, so a way to automate Sitecore to complete basic tasks such as editing, saving and publishing content would save me a lot of time.

I had been using Selenium to automate all of my tests and most of the time I get exactly what I need from it, however when I tried to use Selenium to automate Sitecore I hit a brick wall.

The Selenium IDE uses CSS ID and class selectors to find elements on the web page. Sitecore generates different IDs for elements of its desktop every time you launch it so the Selenium selectors do not work as expected when you use the Selenium IDE recording functionality. This was really frustrating because I felt that automating Sitecore could save me a lot of time and effort, so after some googling I found out about WatiN, a powerful testing tool which enables you to automate your tests with Internet Explorer and Firefox using .Net.

After a bit research I finally found out how to write a test using the WatiN library to automate Sitecore. The test involves editing a content item, publishing it and then checking that the changes have been made on the front end.

To create your own WatiN test scripts you will need the following:

WatiN ( – Inspired by Watir development of WatiN started in December 2005 to make a similar kind of Web Application Testing possible for the .Net languages. Since then WatiN has grown into an easy to use, feature rich and stable framework.

There is a handy video on the WatiN website which will give you a step by step guide to setting up and creating your first WatiN test script.

NuGet ( – NuGet is a Visual Studio extension that makes it easy to install and update third-party libraries and tools in Visual Studio.

NUnit ( – NUnit is a unit-testing framework for all .Net languages. Initially ported from JUnit, the current production release, version 2.6, is the seventh major release of this xUnit based unit testing tool for Microsoft .NET. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages.

Here is an example of how to create a test script that will automate the Sitecore login process.

The first thing that we need to do is create a new project in Visual Studio and add the WatiN and NUnit packages using NuGet. We then need to add a reference to the WatiN.Core and the NUnit.Framework namespaces.

Now we have our test setup let’s write some code to demonstrate the API’s usage.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using WatiN.Core;
using NUnit.Framework;

namespace Test
    //These attributes mark the class as a NUnit test fixture

    public class EditContent
        public void Sitecore()
            //Create a new instance of IE and navigates to a specified URL
            using (var browser = new IE(""))
                //Finds the username field and types the text specified


                //Finds the password field and types the text specified


                //Finds and clicks the options link


                //Finds and clicks the desktop button


                //Finds and clicks the login buton


The example code above opens an Internet Explorer instance and points it to your specified URL, it then uses the method ”Find.ByName” to search for the text field with the name ‘Login$UserName”. Finally we add the “TypeText” command so that it types the text “username”. It does the same again for the “Login$Password” field but this time types the text “password”.

We then find the desktop and login buttons using “Find.ById” and then we perform a “Click()” event. At this point if you try to run this test using NUnit, the test will fail. This is because the file Interop.SHDocVw.dll is not found, we need to make a change to the properties of the refence in the solution so that this file is created. To do this find and select the reference, then set ‘Embed Interop Types’ to ‘False’.

If you want more information on this please visit:

Now we can build the solution and run our test in NUnit successfully!