The Developer’s Role in Testing and Quality
I recently moved into a development role after close to fifteen years in testing. One of the many questions I asked while working as a tester was what developers were doing to contribute to quality and test their code before it gets to a tester. I’m now in a position to answer that question—from my perspective, at least. In my developer role, I approach quality from the angles of risk reduction and test facilitation.
Every new code change introduces risk. There is risk that my code doesn’t work, risk that I break something else in the process of my change, and risk that I am building something that may not be useful to the customer. I try to reduce this risk by working in very small increments and by layering tests as much as I can. Rather than changing hundreds of lines of code at once, I try to work on changes that can be done in a day or so. This allows me to focus on one thing at a time in relative isolation, and to get that change into the product sooner to find out what I did wrong.
For each change I make, I like to layer tests. For any given change, this might mean there are unit, service, and browser tests. These are very low-level tests that help me to understand what I’m building, to design better code, and to assist others in discovering when they broke something.
These are code quality techniques. They help developers like me to write better code, to more thoroughly understand the changes we are making, and to hopefully avoid builds with lots of easy-to-find problems.
The other angle in my current approach to quality is facilitating testers by trying to make their job easier. A number of times when I was in a testing role, I’d ask a developer for some information on how to begin testing something. Sometimes the answer was “I don’t know.” Sometimes we were missing data, sometimes they didn’t know how a path worked through the user interface, and sometimes they never looked up past the lines of code they were writing to see what was going on. I don’t want to be that person.
I facilitate testers doing a better job by creating test data as part of my feature work when it is needed, by understanding the basic customer use cases well enough to perform them myself and explain them to other people, and by taking input from testers when I do things like build automation against the UI or build release smoke tests.
So, no, I’m generally not doing deep and rigorous exploration of the product, even though I have expertise in that task. The expectations of my current role as a developer are that I make the best code I can and then work with a tester to find ways I can make it better. Developers use a different approach from how a tester would do the work, but they still contribute to quality by testing.
