As a group of testers, over the past year or so we have been assessing, discussing, researching, learning and refining how we transition from a traditional waterfall approach, to providing an agile service.
As with most organisations, we used to have an organisation test strategy to support waterfall delivery and it was long… over 100 pages, it was also overly-complex and had become shelf-ware. The general heavyweight, document-centric approach lent itself to defined sequential phases and late testing which found problems, some of which involved rework at requirements level and projects entering inefficient defect management cycles and either a compromise on quality, release date or both.
We have produced an Agile Test Framework, which is a set of guidance and principles which we adapt and apply to each project. Its contents are based on learning in-situ, GDS guidance and also research into good practice, techniques and tools being used globally. As we are constantly learning, this framework is frequently updated. The framework suggests a number of approaches and tools, and provides checklists to help reduce complexity as demonstrated in the excellent book, The Checklist Manifesto by Atul Gawande, a surgeon who saw how complexity meant that simple but critical things can often be missed.
Our testers are now embedded within teams, working with developers, coaching in test techniques, reviewing unit test coverage and discussing approaches, tools and techniques with other testers across projects using our Testing Clan, which is similar to Spotify’s guilds.
Processes are much simpler and are collaborative as, in line with the Agile manifesto statement, we favour individuals and interactions over processes and tools. For example:
- We try not to formally log defects, but discuss, fix and retest them with developers. Why do we fix bugs as soon as we find them?
- We rely on a lot of exploratory testing using test charters and checklists rather than lengthy, difficult-to-maintain test scripts.
- We automate as a principle, using either the Axe framework, or whatever works best for the team but leaning on open-source solutions such as Selenium.
- We execute security testing within sprints to quickly find and fix issues within sprints and reduce the number of issues found by formal IT Health Checks, or Penetration Tests (required for accreditation)
- Other Non-functional testing, such as Accessibility, Cross-browser and device and Performance testing is completed within sprints
- Our documentation is lightweight and only produced if it adds value to the team
It’s been hard to summarise our journey in a short blog, but we’re very excited about this transformation and we would like to share and discuss our framework with others to help teams within government, so please speak to us.
You can follow Mark on Twitter: @MarkWinspear
We'll soon be looking for more Test Managers to join our team. Check our jobs page to stay up-to-date on our vacancies.