Testing When There Are No Testers
I started a new job a couple of weeks ago. My new employer does long-term software development for companies that either don’t have product teams or need some help solving hard problems. We have a handful of testers on staff, but we are also a developer-centric culture.
The testers we have are generally people who want to flip to a dev role in six months. Part of my role, given my background in pairing with developers, has been to help spread some testing knowledge among the development staff.
I like to start this conversation by talking about different intents.
When at all possible, I generally start new code with a test, before I have implemented any of the actual changes I need to make. This helps me to understand how the product currently works, what data is expected, what data will break something, and the order I need to call things. If I understand the code well enough to build a test, I understand what I need to implement.
A pleasant side effect of this practice is that future developers can use my tests to understand how the code works, and there is a quick feedback loop when future changes affect that area of the code base.
These tests are an information service. They’re an immediate bit of information as I write them, and they’re a future source of information every time I need to revisit that part of the code base.
The work a tester does is more of a social science. When I work as a tester, I am spending time looking at the product as a whole: the people who will use the software, the organizations in which they work, the software itself, and the environment that software runs in. All of these factors matter to varying degrees when I am testing.
A large focus of my work as a tester was falsifying the idea that the product works. I wanted to find ways that the software, in all its context, might not help our customers do what they need to do. This is probably the biggest lesson I try to convey when developers need to do the work of a person in a testing role.
The key to testing when there are no testers around is to optimize efforts. Do your best to produce good code the first time around with tools like unit testing, code reviews, and code analysis tools running in your build tool. And then also have those same developers understand the fundamentals of testing like a tester would. They don’t need to be experts.
Development teams have multiple sources of information about product quality available to them. Unit tests and the information in a tester’s head are the most common. But if you don’t have any testers around, your developers probably need to pick up a little testing skill. The combination of good development practices and some basic tester skills might be enough.
