A brief summary of progress in increasing test maturity at National Grid can be found in this spark presentation
Agile Testing: A journey
Understanding how Agile can be introduced into a predominately Waterfall environment means learning. Learning from mistakes, learning from doing and learning from others. In producing a strategy, it became very clear that what we actually needed was a set of principles and guidance that could be adapted for each project within the Agency (Remember, Agile states working software over documentation and although that can be taken to mean ‘don’t write anything down’, I take that to mean ‘Only write it down if it adds value’ (and I know most others do too)). So let’s call this thing a Framework and make it much less dictatorial.
The point of the framework is to help the transition to Agile and bring people along on the journey of thinking about how to do testing in short two-week (or so) intervals and to promote collaboration, so let’s pull together a bunch of good practise and talk about it first… and do away with the MUSTs and the SHOULDs!
In some (more regular) posts, I will go about describing elements of testing and how I think they could be applied to Agile projects as a topic for discussion and refinement.
Agile Testing: A Strategy (2)
Strategies are difficult to write. An ethos is required in order to even begin to trigger the necessary thought processes and that ethos should be ‘simplicity’.
The first step in designing the Agile Test Strategy was to work out what could be improved compared to the previous version which, at ~110 pages was the very definition of shelf-ware. The wording was ambiguous and there was no obvious structure. As we’re concerned with a document that suppliers are expected to follow, clear, unambiguous language is a MUST, therefore the strategy will be written using terminology from RFC2119 and the appropriate references added to the introduction as detailed in the standard:
“The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are used within this document and are to be interpreted as described in standard RFC2119″
The next key item is to clearly define responsibilities in a multi-supplier environment as detailed in the Digital by Default approach from Government which mandates short contracts with multiple SMEs, therefore although “the supplier” will be used throughout the document, the introduction will state that this is to mean the Systems and Services Integrator (SSI) if one exists, else it will be the prime supplier, and it is their responsibility to ensure that any other suppliers involved are implementing and adhering to the processes as defined.
Next, we need an approach to follow. After some extensive research, Sogeti’s TMAP Next (r) in Scrum appeared to be a good fit with the standard Scrum model and although we’ll deviate from it as required, let’s use the diagram below as a start for referencing test activities in Scrum:
Finally, apart from referencing the background as detailed in my last post, as referenced above, there is a need to ensure maximum impact of the content without ‘waffle’, therefore I have decided to use advice as contained in the excellent book by A. Gawande, “The Checklist Manifesto” where complex tasks are simplified to ensure that processes are followed.
The next post will go into defining the test tasks involved in Sprint Planning and Sprint 0!
Agile Testing: A strategy (1)
Background: Government Digital Service (GDS) mandate that Government departments begin delivering projects using Agile in place of the traditional Waterfall approaches in line with the sixth action within the Government’s Digital Strategy (November 2012).
As an Agile Test Strategist, I have spent the past few months researching what this means to a large public sector organisation and how we make the transition to a Scrum approach compatible with The Scrum Guide. In this series of blog posts I will be breaking down the thought processes that went into the eventual creation of an Agile Test Strategy which will be provided to suppliers at procurement stage for projects.
Test automation – an update
Since posting in March, around 70% of the total Use Cases have been automated at a functional level. This automation framework has been successfully transitioned to our supplier who is actively using this for full project releases.
In addition to automating the User Interface, Web Services, Batch file upload and Databases are also automated. It is now possible to execute well over 30,000 individual Verification Points (VPs) in around 8 hours. When this is scheduled out of hours, you can see the power of the tests created.
What next?
The next project release will see a number of pages re-platformed from Java to .net. Due to the framework used, it is simply a case of creating new object maps in order to execute the full regression pack against the new system. This re-mapping is probably around a weeks effort which means the it will be ready well before the end of development and ready to start running in the integration phase, before functional testing begins.
As Webdriver (Selenium 2) has been around for a while now and Selenium 1 (RC) support can only go on for so long, it’s worth thinking about a migration plan to transition the actions used. As the framework separates out objects, actions, data, subtests and tests, this means the migration is isolated to a relatively small area. This thinking will be done this year with the aim of migrating early next year.
Transition of an automation framework
So, for the past few months, I’ve set up, installed, configured and documented an automated testing framework for the Skills Funding Agency using Axe (www.axetest.com), combined with Selenium RC and C# with the aim of automating 80% of the functional aspects of Use Cases. We have now got to the stage where the automation software has been approved to be included on the estate software list, which is no mean feat in the public sector! The plan is to transition this automation framework and the test artefacts into our supplier within the next month in order to save hundreds of thousands of pounds a year in testing costs, and increase regression testing such that testing identifies issues before they hit production.
New website
This is the second website I have created, having already created one for my brother www.garage-doorman.co.uk, which was created using Joomla and hosted with GoDaddy. This experience was enough to put me off for life. Despite having some technical skills, configuring php files and phoning the support team turned into a real pain. Coupled with this, the addin used for the contact page threw a whole load of errors. Anyway, it’s live but I’m not happy with it. This time, I used bluehost’s one click install of wordpress, and the experience has been completely different – it just works!