Test-Infected Developers

This article was originally published in the June edition of Testing Trapeze

At my workplace there is a culture of shared ownership in software delivery. We develop our products in cross-functional agile teams who work together to achieve a common business goal. However it’s still relatively rare for specialists to be proactive about picking up work in areas outside of their own discipline. For example, you don’t often see business analysts seeking out test execution tasks and prioritising those above work to refine stories in the product backlog.

That said, I’ve recently noticed an increase in the number of developers who are voluntarily engaging in test-related activities. They’re not jumping forward to think about test planning or getting excited about exploring the application. But they are diving into our automation by helping the testers to improve the coverage it provides, or working to enhance the framework on which our tests run.

As a coach part of my role is to foster cross-discipline collaboration. I confess that I haven’t been putting any active focus on the relationships between developers and testers. It is something that has changed as a byproduct of other activities that I’ve been part of. I’ve been reflecting on what’s behind this shift and the reasons why I believe the developers are getting more involved.

Better Test Code

In the past our test code has occupied a dark corner of our collective psyche. Everyone knows that it is there, but most people don’t want to engage with it directly. In particular, I have felt that developers were reluctant to get involved in a code base that was littered with poor coding practices and questionable implementation decisions. In instances where a developer did contribute, it was often a cause of frustration rather than satisfaction.

The test team have recently undertaken a lot of work to improve the quality of code that runs our automation. In one product we started the year with a major refactoring exercise that allowed us to run tests in parallel, which more than halved our execution time. In another we’ve launched a brand new suite with agreed coding standards from the beginning.

The experience for a developer who opens our automation is a lot less jarring than perhaps it has been in the past. As the skills of the testers improve, and the approach that we take to writing code becomes closely aligned with the way that developers are used to working, it’s no longer traumatic for a developer to delve into the test suites.

In addition, all of the changes to the test code now go through the same peer review process as the application code. We use pull requests to facilitate discussion on new code. There is a level of expectation: it’s not “just test code”. We want to write automation that is as maintainable as our application.

The developers have started to participate more in peer review of test code. There’s a two-way exchange of information in asking a developer to review the automation. The tester gains a lot of instruction on their coding practices. However the developer will also gain by having to completely understand the test coverage in order to offer their feedback on it.

Imperfect Test Framework

On the flip side of the previous point, there are still a number of very clear opportunities for enhancing our automation frameworks and extending the coverage that they offer. The testers don’t always have the capacity, skills or inclination to undertake this work.

I can think of a few occasions where a developer has been hooked into the test automation by an interesting problem in the supporting structure that needed a solution. Specific technical jobs like setting up an automated script for post-release database changes or tweaking configuration in the continuous integration builds. These tasks improve their understanding of the framework and may mean that the developer ends up contributing to the test code too.

Within the tests, there are application behaviours that are challenging to check automatically. Particularly in our JavaScript-heavy applications we often have to wait for different aspects of the screen to update during a sequence of user actions. Developers who contribute by writing the helper methods required for testing in these areas will often end up having a deeper understanding and closer involvement in all of the associated test code.

I believe the key here is providing specific tasks where the developers can engage in the test code with a clear purpose and feel a sense of accomplishment at their conclusion. In some instances, the developer will complete a single task then withdraw from the testing realm. In others, it’s a first step towards a deeper involvement in the test code and subsequently testing.

Embedded In Development

In almost every instance, a developer who is making a change to one of our applications will need raise a pull request to have their code merged back to our master branch for release. As part of the process enforced by our tools, the code to be merged must have passed all of our automated checks. Every change. All of the automation.

We’ve always run our automation regularly, but its relatively recent that it has it become mandated on every merge. This change has largely been driven by the developers themselves who are keen to improve the quality of code prior to testing the integrated code base.

Now that our automation runs many times per day it is in the best interests of the developers to be engaged in improving the framework. If it is unreliable or the tests are slow to execute, it has an immediate negative impact on the developers as they are unable to deliver changes to our applications. They want our automation to be robust and speedy.

The new build schedule has helped to flush out pain points in the test code and engaged a wider audience in fixing the root causes of these issues by necessity. Now most of the developers have experienced a failing build and had to personally debug one or more of the tests to fix the problem. The developers are actively monitoring test results and analysing failures, which means that they are a lot more familiar with the test code.

Conclusion

I see automation as a gateway to getting developers engaged in testing more broadly. When collaborating on coverage in automation, there is the opportunity to discuss the testing that will occur outside of the coded checks. The conversation about what to automate vs. what to explore is a valuable one for both disciplines to engage in.

We’ve taken three steps down the path to having our developers excited about picking up tasks in our test automation. We’ve made the suites a pleasant place to spend time by applying coding standards and ensuring that changes are peer reviewed. We’ve provided opportunities for developers to contribute to the framework or helper methods instead of asking them to write the tests themselves. And we’ve the automation in the development process to create a vested interest in rapid and reliable test execution.

Developers can become test-infected. I am seeing evidence of this in the collaborative environment that is continuing to evolve in my organisation.