How DVLA Automates

When we started our SDET programme in 2018, we had no automation testing at the DVLA. We were beginning our transformation programme and knew we needed enterprise-wide changes to the way we were building and shipping software and our SDETs, and the automation they build, proved to be fundamental in allowing us to release software safely and quickly.

We have lots of very different products. These range from the services used by the public to access and transact with their information, products used by the motoring industry, and those used by other government departments. All of these must comply with legislation and often has immovable deadlines. We’ve grown our SDET capability into a fundamental part of how we construct our software. We’ve taken software engineers and testers and learned from each other to build a group who can confidently set our testing standards and make sure they are conformed to. We have a hugely successful development programme which builds SDETs from scratch.

We value our automated test code as highly as our production code, authoring it on the same branch, in the same repo, as our production code. We have the most brilliant Community of Practice which meets each month and is overflowing with demos and ideas for all the common problems we share. We generate a huge amount of internal libraries, increasingly making these public open-source.

In this talk, we are going to share how our SDET community automates functional testing and how it meshes with our four principles of testing early and often, integrating to avoid stubs, generating test data to avoid fixtures and making each test its own island. We’ll also talk about some of the challenges we have overcome, such as building an effective community, and the improvements we are looking to make in the future, like our exploration of model-based testing.