On the face of it testing seems like such a simple thing. You just need to check that everything works right? Seems straightforward. However, I think anyone who has tested for any period of time knows that the reality is much more complex than this. The longer I work in testing and the more I try to learn and grow in my skills, the more I come to recognize this. The skills required to be a good tester are vast and varied. Not only are there a myriad of technical skills that one can (should?) learn, but there are also many skills that are not specific to testing itself but that are general to knowledge work. We need to know how to navigate relationships and politics in a company. We need to be effective and skillful communicators. We need to understand process and change management. We need to know how to work well with those that we like and those that we don’t. We need to understand how business need and financial pressures affect what we do.
In my current work, we make simulation software and there is one interesting thing that happens. The more powerful computers and our software get, the bigger the problems our customers will try to solve. “Instead of just looking at each component in isolation why don’t we just look at all of them together and see how they interact?” I feel like we are doing the same thing in much of our knowledge work (testing included). Instead of looking at each piece on its own we are trying to put everything together into one big system and work with and understand the whole. What this ends up doing is meaning that no longer do I have ‘just’ worry about testing, but I need to figure out how to fit in and understand all these many other functions and roles. It is a more realistic approach to what is really happening – knowledge work has always been about relationships and understanding and not just you doing your simple task on your own – but it is a hard world to understand and navigate. We still have so much to learn.
The previous model for shrinking our world down to a manageable size was to give each person a clearly defined role and action that they had to do and then pass on to the next person (think of an assembly line), but in knowledge work we are coming to see that this way of shrinking the world doesn’t work. However, our response so far seems to be to make the world infinite and hope that we stumble on the right things to focus on. So the question is how do we shrink down the world when everything is so interconnected and interdependent? To paraphrase G.K. Chesterton, I though I was getting into testing, but I find myself struggling with gigantic angels and demons.1
One of the things I have been doing with this is putting limits on which areas I want to focus on when learning testing skills, but I wonder if there is more I can do to help shrink down this infinite world into something I can manage? How can I navigate what I ought to be doing and learning – not in the sense of what my job description says, but in the sense of doing the things that are best for the company?
One place where I can see the answer to this is to shrink down the deliverables instead of the roles. Instead of giving each person a defined role and having them work within that role and not have to worry about the why of doing it, we need to give each team a small set of deliverables. Within that context we have a limiting of what to do and learn, but we are not constraining each person to only do a particular thing. What I need to know and learn and work on is defined by ‘whatever we as a team need to be done so that we can get this deliverable completed.’ Maybe, what I need is to learn how to do security testing, or maybe what I need is to learn how to help facilitate people in bringing different parts of the project together, or maybe what I need to learn is how to fix a defect. Whatever it is, what I need to do and learn is defined by the project and the deliverables and the skills needed by the team as a whole and not by something that is heavily and specifically tied to a particular role that I might have as a tester.
We keep going down deeper here, but of course the next question to ask is what are my deliverables as a tester on the team I am on? We have certain feature deliverables that are pretty obvious, but I think there is another deliverable that I have some unique skills to help with and that is the long term quality deliverable. I’m not thinking here of the testing role in terms of finding bugs during testing, but I’m thinking here of working with the team as a whole to help produce good quality, durable code that will help us continue to produce value in the future. This post is getting long, so I’ll wrap up here, having given myself (and hopefully you as well) something to chew on.
Footnotes
1. The actual quote is actually a little more profound “anyone who makes himself responsible for one small baby, as a whole, will soon find that he is wrestling with gigantic angels and demons” In Defense of Sanity – page 167
offbeattesting 