The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #46: Keep your mind open to new techniques and tools - Graham Perry
It's easy after several years to fall into patterns of practice. When we start to feel like we know what we are doing, or what the expectations are, we can easily get complacent, and just "go with the flow". The danger we face is that we can become stagnant, or we can become too comfortable with the approaches and tools that we use. Also, we can get to a point where our tools do the work, and we are little more than operators of those tools.
Tools are good, they are important, but we have to be careful to not get too tied up in what they do so that we shut off our minds to learning and trying different things. Also, if all we do is operate tools, it's possible that we can be replaced by someone who looks a lot like us to operate those tools in our place, or have a machine operate those tools instead. We need to bring more to the table.
Workshop #46: Find a tool that interests you (open source or proprietary) and create a series of tutorials that describes how to use the tool and what aspects of testing you will use it for, with example of solving real challenges you face.
When we look in books or online at tutorials for programming languages, software tools, or other applications, very often the examples given are simple. They convey the concept as economically and as universally as possible, since to do more than that would require focusing on individual contexts that, for most, are not relevant.
It's within the individual contexts, though, that the real learning and mastery of a tool can be found. Most of us will, more than likely, see that the simplicity and elegance of many tools seem to get lost in translation when we try to approach our own everyday work. We find we have a variety of issues that are different than the samples we see. Solutions don't come as easily. Our applications seem to have many different challenges that don't seem to flow as elegantly.
Often this is a point where people get discouraged (well, I certainly have) and have either given up or just handed the harder parts over to another group and had them do the work, then later ran the tool themselves. While this can be an effective approach to getting the work accomplished and moving forward, it has the side effect of leaving those who were motivated to explore or use the tool with little in the way of insights as to what it is doing.
The benefit of sitting down and making your own tutorials (writing them out from your own perspective) is that you can focus on seeing what you understand, and why you can explain to others. This is not as easy as it sounds. We naturally want to get to the meat of what we want to do quickly, and so we make lists of shortcuts, we cobble together little scripts that chain commands together so that we can accomplish, and then we think that we are making progress.
By taking a step back and spelling out what we are doing, as though we were going to teach this to someone else, we can actually see what fits together and why it fits where it does. Some tools will be graphical and with a lot of drop down selections, but by tying together the ones that are used most often, it's possible to develop a series of workflows that others can use. If the tool is code based, by creating a number of scripts, documenting the steps, and making a "personal style guide", we can get a better handle on what we are doing, how the moving parts fit together, and ways that we can be both efficient and effective with the tools we use.
I personally do this with a variety of the tools and procedures that we use. My first step is why I refer to as the "sticky note process". This is where I go through and I quickly collect any and all examples from pairing sessions or as I am being guided through, so I can make an immediate "cheat sheet" of steps. This helps with making sure that we know the initial steps necessary. The problem is, if we don't follow up fairly quickly, we will lose the context and the "why" for what we are doing, or variations we can explore.
My next step is to put it into my own document system and try to make a more detailed walkthrough of what I am doing. Ideally, I try to spell out the ideas in a way that will address a variety of situations and permutations, so that it's not just a "one off" or always the same script/approach. At times, that really is all that's needed, or there are not many variations of what is done. Other times, there are switches or options that, while not frequently used, can give control or provide additional information. By walking through and capturing examples of what I'm seeing (usually by way of screen shots or other output) I can create a narrative that goes beyond just a string of commands.
Finally, I have the benefit of a company that prides itself on the creation of how to documents for lots of aspects of development work and testing. This "third step" allows me to share these documents with everyone else, and they can use what I have put together so that they can likewise leverage what I have learned. This also allows them the opportunity to ask me questions, or clarify any areas I may not have fleshed out.
This doesn't just work with a literal testing tool. This approach can also be used with approaches to testing that don't rely on tools. Even if we are alone on our teams in the capacity of performing testing, having a blog or some other place to share these ideas, experimenting with the approaches, and getting feedback from others can help tremendously with our understanding (or lack thereof).
Bottom Line:
We learn a lot by actively doing, but we can really nail down the details when we teach others. Through blogs, tutorials, and other approaches, we have a chance to really get into the guts of what we use and strengthen our understanding.
No comments:
Post a Comment