In my last post I talked about coding productivity being one of the considerations for deciding what automation to keep. I want to dig into this a little more as I’m not sure that it’s something we as testers think about a lot. We think about things like making sure we don’t let bad builds get out or about “finding all the bugs.” We think about making sure we have good coverage or large automated regression testing suites. We think about a lot of different things, but in many cases it seems that the stuff we think about is related to ‘test only’ activities.
But aren’t we supposed to be system’s thinkers? Aren’t we supposed to looking at things from a holistic point of view? Think about it. Someone needs to do that right? In most companies testers are hired to help mitigate risk.1 Companies pay good money to testers because they want some assurances that the code being released is going to be valuable to their customers. However, this isn’t something testers can do on their own. Creating valuable code is a team based activity. Are we thinking about things in a holistic team based way?
One of the most important things we as testers can do is to help improve coding productivity. I repeat myself here: the reality is, creating valuable software is a team activity. Testers need to think about how their actions impact and influence the team. If we spend too much time find bugs and no time thinking about how to work with the team to introduce less bugs, are we really helping the team? If we think about getting good coverage of the features and not about how we can figure out what kinds of issues and interactions our customers actually use, are we really helping the team? If we think about preventing bad builds from getting through the pipeline and not about about how to change our build and deployment process so that the builds don’t get mangled in the first place, are we really helping the team?
We need to think big picture. Don’t get so caught up in the official tester activities that you forget to look at what is going on. Where are the pain points in getting the code out the door? What things can you do to help make developers more productive? How can we as testers reduce the time it takes to get good quality code shipped?
Hint: it probably isn’t by running more regression tests.
Look for things that are slowing down the release of code. There are many things that need fixing. Some of them you can do something about and some of them you can’t. Find one that you can and start chipping away at it. Don’t get so caught up on the hamster wheel of running and maintaining tests and flinging bugs over the cubicle wall that you forget to come up for air and look around. There are pearls to be found, but if the current has pulled you away from the reef, you might need to spend some time swimming back into position. Be a systems thinker. Zoom out a bit and tackle the problems that are slowing down the system.
1. Whether you agree with this being what testing is about or not, I think the reality is that for many companies this why they hire testers.