Skip to main content

Why testing early and failing fast is no bad thing

I was very excited just before Christmas when the DWP Secure Communications team headed out into the big world to test our authentication service with real General Practitioners (GPs).

Rachel Woods - Product Owner
Rachel Woods - Product Owner

Our team is currently working hard to get our service into Private Beta. At that point the GPs who use our service will benefit from using a fast, easy service to provide patient medical reports and, because DWP will get the information it needs straight away, people will get their payments faster than ever.

Testing the service for real

Our service relies on 3 aspects to complete its goal. The first is an authentication service that can determine that a user is a GP, the second is a web based form where we can capture the information needed and the third is how we push that information into DWP.

Now, we could have waited until all 3 parts were ready and tested end to end but one of the reasons we chose micro-service architecture was that it allowed us to test and iterate components as they became available. The first component we’ve developed is the authentication service. We’ve worked really closely with our colleagues in Health on this part of the service, so we were confident about its success.

"Houston, we have a problem!"

thumb_secure comm pic_1024
DWP's Secure Communications team testing their authentication service for GPs

On the day, as GPs started trying to use the service the team were practically hugging the TV, watching the code like something from the Matrix.

As we were poised, all ready to cheer, it became clear that something wasn’t quite right. A small number of users were not getting through. And I don’t mean failing to use the service correctly - they were not even getting to the service. Oh, dear! A small piece of the puzzle wasn’t functioning correctly - something we needed to fix.

The value of working in an agile way

So I didn’t get to do the victory dance I was expecting and for that I expect the team are more than a little bit grateful - but on reflection so am I. If we had been a waterfall project this test would have been done once everything was ready to deploy. We might now be worried about a new risk to our ‘Go Live’ date. But after a slight sulk at the lack of dancing, a bit of reprioritising meant that we could identify, isolate and investigate this hiccup and work out the impact on delivery. We’ve now got a good idea of how to fix it and yes, that’s right – we’ll be back out in the real world, testing and improving as soon as we can. Cue dance music!

Sharing and comments

Share this page