To err is human, or so the saying goes.
Who can’t relate to this? We’ve all been there. We’ve all made mistakes. However, despite the universality of the experience we all still seem to be afraid of it. We hate making mistakes and doing the wrong things.
In thinking about this natural propensity, many have pointed out the importance of embracing mistakes as a way of learning, and so in the software industry, we have tried to do this. We realize that if we let a fear of mistakes paralyze us, we won’t try new things and we’ll short-circuit the learning process. If everything we do revolves around protection and perfection, we won’t stand out and make the jump to the next level.
But what if you’re a software tester?
Preventing mistakes and risk mitigation – isn’t that why companies hire testers and create QA teams? Isn’t this part of our mission? It’s built right into the very heart of what being a tester is. It’s part our DNA and core make up. We of all people don’t make mistakes, do we? In fact, this is exactly what we are good at – finding mistakes, pointing them out, and making sure our customers aren’t exposed to them. We’re in the mistake prevention business, so should we be OK with messing up?
Making Mistakes
Let’s remind ourselves again: to err is human. We need to be OK with messing up and making mistakes because it will happen. Believe it or not, testers are human too. We are going to make mistakes and mess things up. And the reality is if we spend too much time and energy on trying to prevent mistakes, we aren’t going to have the time to do other valuable work. Let me give an example of what can happen when we get too focused on mistake prevention.
We recently integrated a couple of teams together, and as part of that process, we consolidated automated tests from different teams. One of the most interesting parts of that was how many checks some of the teams were doing for things that were not in their own area. There were a lot of tests that seemed to be about making sure teams weren’t the ones that ‘broke the build.’ Now breaking the build isn’t a good thing. It’s a mistake we don’t want to keep making. But there is a difference between adding integration coverage in a smart way that responds to the realities of what causes the builds to break, and having every team cover their butts in a way that adds excessive coverage. When we reviewed the tests from the different systems, we found many tests that were redundant or duplicated simply because teams wanted to be sure that if anyone broke the build it wasn’t going to be them.
An undue emphasis on preventing mistakes led to an inefficient approach to testing and also prevented some learning opportunities. Each team was so worried about preventing mistakes from their team that they became siloed. Instead of looking at the problem holistically, they were looking at in terms ensuring their specific team didn’t get embarrassed. This reduced very important cross-team collaboration and prevented many learning opportunities. Don’t be too afraid of making mistakes!
Not Making Mistakes
Being OK with making mistakes isn’t the whole picture though. It is true that testers are usually hired to help prevent mistakes. So what kind of mistakes to we need to prevent? What kind of things do we need to make sure don’t happen? Let me give a couple of examples of mistakes you don’t want to make.
Shipping with test data
This is one mistake you really don’t want to make. Don’t ship with a test database or some dummy data. Don’t ship with testing and debug flags on. These are the kinds of mistakes that make a big expensive mess and let’s be honest, it should be pretty easy to automate some quick checks that act as a safety net on the last deploy step. Be careful with this one. The point of having test data is to help you better prevent errors and mistakes. You really don’t want it to be a cause of errors.
Losing private customer data
Our customers give us a lot of private data that they rely on us to protect. Treasure that trust. Trust is easy to lose and hard to get back, so make sure you are being very very careful about the way you treat sensitive or confidential data. I’m usually not a big process guy, but when it comes to confidential customer data you might just want to have some extra process safeguards in place. Don’t be lax on this one!
Destroying customer property or data
I remember a time in our company when someone accidentally committed a change that could call sudo rm -rf in the root directory. If you don’t speak Linux, that is basically saying ‘force a delete of everything on my computer (including the OS itself).’ As you can imagine, this was a not a good place to be. Thankfully we caught the problem after a couple of our test machines had everything deleted, but imagine if we had released with that bug! That isn’t the way to keep customers or make your company money. Pay close attention to the kinds of things that can delete data or cause hardware failures. Your customers will forgive a lot of silliness in your app but they will have a much harder time forgiving you if you mess up data from other apps or systems.
Conclusion
In conclusion, don’t let the fear of making a mistake hinder your progress and productivity, but as a tester remember that you are still in the mistake prevention business. Take the time to think about what kind of mistakes you don’t want to make. It is OK to make mistakes – except for when it isn’t.
About the Author: Dave Westerveld has been testing software since 2008. He’s worked on projects ranging from well-establish products to being involved in the early stages of major new initiatives, and he’s passionate about helping teams efficiently produce high-value software. Dave will also be speaking at the upcoming KWSQA Targeting Quality and Better Sofware East Conferences. To learn more about him, you can check out his blog or follow him on Twitter.