Operating as a Developer In Test

Developer In Test

A recent project gave Box UK the perfect opportunity to trial the increasingly popular Developer In Test role so I volunteered to operate in this capacity. In this post, I look at what the role is and how we used it, and get some feedback from across the company about what the experience taught us.

What is a Developer In Test?

Definitions of the role vary, and indeed there are similar positions with different titles (such as Software Development Engineer in Test, or SDET), but at Box UK a Developer In Test is a developer who is focused on making sure products meet their specifications through functional testing, integration and quality analysis. The Developer In Test does not generally produce any functionality, but writes integration tests, ensures builds are done correctly, improves Continuous Integration, and works to produce repeatable automated functional tests for user stories.

The project

The project brief was to produce an API that worked in both SOAP and JSON. As the project was produced with Test Driven Development (TDD) it had high unit test coverage (well over 90%), but we also needed functional and integration testing. Usually, this task falls to our Quality Assurance (QA) department but in the case of an API with no browser-based front end we decided that using a Developer In Test would be a good way to ensure high quality.

How did we use a Developer In Test in a scrum team?

I joined a project team which contained a specification writer, two coders and a project manager, working alongside them, in the same room, to produce automated functional tests. I was part of the sprint planning, daily scrums, Skype conversation and a handover meeting to the client at the end of the sprint when we delivered.

What was the Developer In Test doing?

This post isn’t about technology specifically, but suffice to say I I worked primarily with the fantastic Soap UI to produce integration tests, working through the endpoints and building tests for each user story. I set up a build on Jenkins to be triggered by the main project build to run all these tests, so I would know if any commits had broken anything. I was also responsible for reviewing commits and making sure the code was fit for purpose.

How was the experience?

As we went on, the tests I was writing got more and more fine grained and focused, and I found that writing automated tests helped to find bugs and inconsistencies in the project. Adding edge cases and deliberate error cases meant that we were able to build confidence in the product as we went forward. Every time I found a problem, I raised a ticket and the developers worked to resolve it in our regular workflow; at Box UK, anyone can raise tickets on projects – we track everything through tickets – so it wasn’t unusual for me to raise issues.

Essentially I was acting as QA/automation engineer, and 10+ years commercial experience as a coder meant I was well positioned to write tests against an API. Because it wasn’t my code, I didn’t feel precious about it and was able to be quite aggressive with my testing strategies. It’s often said that the cheapest place to catch bugs is in development, and for me it was great to be part of such a tight feedback loop. I think it worked well because we had two devs so when one was working on new functionality, the other could address issues I was adding so we could keep building our “safety net” of functional tests as we went along.

Writing the tests required a lot of thought and consideration of the data I was generating, the assertions I was making, and the repeatability and atomicity of my tests. This was only my second project operating as Developer In Test, and I think that my years of writing unit tests and functional tests prepared me well. To have it known that I was actually there to write integration tests and not to have the burden of producing functionality meant I could really give the necessary attention to the tests I was writing and ensure they were in no way an afterthought – my time didn’t get siphoned off into producing functionality or fixing bugs. I think therefore that utilising a Developer In Test really shows a commitment to quality, and I am convinced that in this instance it saved us time, and therefore money, as bugs were caught early.

Other perspectives

So that’s what I did on my not-holidays! Here is what some of the people involved in the project thought about working with a Developer In Test. I assure you it is merely coincidence that we all have the surname Davi[e]s!

Project Manager’s perspective

Pete Davis: Utilising a Developer In Test role played an important part in ensuring a successful API project. The nature of the project meant having an independent member of the team reviewing at code level was vital in guaranteeing the quality of work that we produced met the high standards we always set ourselves at Box UK.

We involved the Developer In Test in the daily scrums and sprint planning meetings; this gave the development team confidence that the work produced each day was vigorously checked and tested during the development phase, rather than at the end of the project. This meant that everything from minor issues, differences in development versus specification to major project blockers could be raised quickly but also, importantly, fixed and re-checked swiftly during the sprints.

Programmer’s perspective

Ben Davies: Working with a Developer In Test on this project was an excellent experience. With the project being a web service (no front end) this project was ideally suited to a Developer In Test, who was able to analyse our written code and produce tests in such a way that a normal tester may not be able to do. The Developer In Test could draw on his developer skills to gain a very quick understanding of what should be tested to fulfil the requirement of the web service being “robust”, as well as being able to easily understand and even diagnose errors when they occurred.

Having access to the source code allowed the Developer In Test to understand how the code worked, and what parts of the project needed a higher level of testing than others, effectively white-box testing the API. The Developer In Test could not only provide the steps to reproduce the problem in question, but regularly diagnose and provide us with the core cause of the issue. This saved the developers lots of time when tickets were raised.

Wrap up

For this project, a Developer In Test proved to be an extremely valuable role. Some projects would naturally be harder to automate – browser automation, for example, is much more difficult than API automation – but I feel having a developer dedicated to testing is a huge commitment to quality and robustness. It is no substitute for traditional QA, but rather alleviates some of the burden of repetition from the QA team and allows them to be more focused on the user experience.

At Box UK we have a strong team of bespoke software consultants with more than two decades of bespoke software development and software testing experience. If you’re interested in finding out more about how we can help you, contact us on +44 (0)20 7439 1900 or email info@boxuk.com.