One of the hardest parts of being a (test/IT) consultant is that clients expect you to know everything about every topic there is. It sometimes truly feels like mission impossible. In this blog post, I want to explain how I handle this by telling a story of such a challenge.
One of the things I know (knew?) very little about is unit testing. I always figured it to be more of a developer task, but that changed when I was asked to help a team of developers with their unit tests. They had a set of unit tests, but they took too long (15 minutes) to run. That resulted in the developers not running the unit tests at each commit, taking away the reason for the unit tests being there in the first place. So, how could I help them?
The cool thing about being a consultant is that you are not supposed to solve the problem for others. You are merely trying to nudge people in the right direction so they solve the problem themselves. Isn’t that beautiful? In order to achieve this, you have a couple of options at your disposal even if the topic is unfamiliar to you. Let’s go over them.
First, it’s okay to admit to yourself and to others that you are not an expert in that area, in my case unit testing. Lying doesn’t help anyone. Yes, you may feel uneasy (I certainly did), but that’s okay. Of course, I started reading blog posts about unit tests, fiddled around with them myself with the help of some book and talked to people whom I considered experts in that area. You need at least a bit of knowledge in order to understand vocabulary and purpose of the specific topic. Don’t be afraid to take some time for that. Then, I invited the developers to explain to me what they wanted from their unit tests, what the problem was in detail and how much it bothered them. It’s also good to know how much time they are willing to invest into improving the situation (it’s hard to talk about specific solutions at this point). This first session served as a starting point to get to know each other and for me to get a feeling of how each developer valued testing.
Second, it’s important to take a step back in your thinking and go from the specific level to a more abstract level. You will get to a point where you DO know what you’re talking about. That is to say, I went from thinking about ‘unit testing’ to ‘testing’ as a whole.
I started thinking about which testing ‘truths’ that I know, apply to the level of unit testing. For example, testing techniques are important everywhere, so did the developers use them in their existing unit test set? Could they explain to me why they wrote their current tests and what their value was? And in the case of automated (unit) tests, did they set them up in a way so that the tests could run independently from one another?
By going to this more general testing level, I was able to ask the right questions to the developers so we had starting points for the improvement phase.
From here on, the task gets easier. We had broken it down together and we had practical points to start from. I paired up with one developer and we went over the existing tests, improving them where we could. After this first afternoon together, we made an agreement that the developer would go on by himself and I would merely review what he did and be available for questions. I had a different task and that was documenting what we did in this team, so other teams could also start improving their unit tests if they wanted to.
To sum it up: if you are faced with a challenge and you are not an expert, don’t panic. Learn the basics, break down the problem into smaller parts with other people and start working on (small) improvements. And remember, it’s okay to feel a bit anxious about this, but try to make the best of it anyway! At the end of this story, I still consider myself a newbie on unit testing, but I now know a lot more than before and in the process, I infected some more developers with the ‘testing virus’, and that’s what truly matters to me.
Questions or comments? Yes, please!
Comment here or start a conversation with me on Twitter