In this interview, Matthew Bissett, the test manager responsible for the integration and testing of his area's flagship system for Her Majesty's Government, shares his thoughts with us on the importance of early testing in order to rapidly speed up software releases.
Mathew Bissett has been working for Her Majesty’s Government for more than six years, having been recruited straight from university. Currently the test manager responsible for the integration and testing of his area’s flagship system, he has driven through delivery process improvements to enable weekly deliveries.
Noel: How has testing's role or purpose changed over the years, and where do you see it going in the future?
Matthew: In my experience, testing's role has changed from being there to stop software from being delivered until all the risks had been tested and has become an information provider to the product owner. At the end of the day it is the product owner who is taking the risk and it is up to the test team to ensure that he/she knows what risk they are taking by saying 'ship it' - because more often than not they will!
In the future I see testing becoming more embedded in the whole lifecycle, not just from a personnel point of view. Mature teams realize that there is nothing to be gained by not testing risk at the earliest possibility regardless of whether their job title has the word test in it. I also believe that systems will become more resilient when failure happens rather than fail less often as teams rush software to market as soon as they can.
Noel: Why is it so important is it to identify risks early?
Matthew: I think this is fundamental to releasing good software in a timely manner. Saving up risk is like buying your weekly groceries on credit - you've still got to pay for it at the end of the month. Since we introduced our weekly delivery cycle process in my organization, it has been more important than ever to identify and assess risks as early as possible - so much so that I do not allow any software into our delivery cycle if there are important outstanding risks that have not been tested. Software should not fail in the last stages of your delivery cycle - if is does then you have done something wrong along the way.
Noel: What are the pressures commonly felt at the end of the delivery cycle, and how are those relieved by drastically reducing release cycle time?
Matthew: We realized that when we were trying to deliver 6 weeks worth of work the delivery became "too big to fail." After all we had 30+ people working on it for 6 weeks. Our customers were also very demanding on which delivery their feature would be in because they did not want to wait another 6 weeks. Both of these reasons can be alleviated by reducing your release cycle time.
A smaller cycle time means that your increments are typically smaller, which in turn carry less risk and should be easier to test. Also, if your customer's feature fails or is not ready, then they are far happier to wait for the next release. A smaller cycle time is not the only thing to take into account though. If you are not mature enough to introduce quality gates and enforce them then you can still have the same problems. Stick to your guns!
Noel: How does the introduction of CI remove team independence?
Matthew: Integration is the biggest risk of the system I deliver for many reasons, not least the ingrained culture of my area. Introducing CI and making sure that the component systems are integrated as soon as feasible has made a big difference to the quality and speed of our delivery. Also, when you integrate a system incrementally then there is nowhere for developers to hide - their change was the last and it did not work, so go and fix it.
Noel: What do you hope you hope attendees to your session are able to take back home to their own projects?
Matthew: I hope that attendees to my session will take home some ideas on how they can change their delivery processes for the better, whether it is reducing release cycles, assessing risks earlier or enforcing quality gates. I'm not selling anything in my talk, I'm delivering a case study based on a real system, which we have been continually developing and improving for over 5 years.
I was in a fortunate enough position to be able to change our delivery processes for the better (and we're not finished yet!). I've attended enough conferences to know that not everything that worked for me will work for everyone else but I believe that everyone should be able to take something useful back to their organizations and if anyone thinks that none of it would work then I'd be happy to discuss it with them any time throughout the conference.
