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 #84: Learn to take effective notes and document your testing in different ways - models, mind maps, sketches and other approaches will all help you gain insights and new perspectives on the system you are testing.
This particular post is timely, mainly because of a recent event that took place with the Australia/New Zealand chapter of Weekend Testing. In that particular session, we focused on test planning and ways that we would test a product with a limited amount of time and resources. We broke up into different groups and tackled the problem in a variety of ways. That session, its artifacts and the variety of approaches used, I think, illustrates this principle beautifully. We all used the tools that helped us to quickly and effectively gather our thoughts capture our ideas, and allow us to make decisions based on that information.
Workshop #84: Experiment with a variety of methods and see how they can help you approach issues and planning. Practice a staged model of information gathering and work through the steps of Capture, Analysis, Practice, Synthesis, Synopsis.
It's one thing to say that there are a variety of techniques that we can use, but we don't know how powerful they can be until we put them into practice. The benefits of mind mapping seem great until you are in a meeting and you decide you want to mind map, but haven't practiced the skills. Whiteboard sketches are helpful, and can be a bridge between regular notes and the more modern mind map, but how do you capture your results? Traditional mote taking can be effective at times, but you can find yourself with too much information and having to discard large swaths to get to what you need.
Add to this the fact that many people have differing approaches to how they process information, how they chose to practice what they do, and ways to store information that does different things. Procedural information on how to perform a task is different from higher level conceptual details or logging data that can help pin-point errors.
I personally have a three-tiered method when it comes to note taking and looking at ideas. My first line of defense is what I typically call my "Sticky note on steroids". This is using the built-in app "Stickies", and I use it because it is genuinely the fastest way to grab anything I am working on. I frequently grab items from IRC, Skype or Screen sessions when I pair with other testers and programmers. Most of the people I work with know what I mean when I say "hang on, I'm dropping this to Sticky". On some days, the sticky can get to be as much as 15 typewritten pages long.
I call this my first line of defense because, typically, this is where I capture what might be one-offs or items that are going to be used in the short term. As I go through testing activities, I will look to the Sticky first to see how often I reference something. I use font color, bolding, and other techniques to "heat map" the information I gather and use more frequently. If an item is in black text in the sticky for a long enough period, then I know that I have something that was useful for a little while, but I haven't come back to or I decided wasn't as valuable. This typically gets pushed down the pile or discarded after a time. The information that appears near the top, bolded, and in any variety of colors (but usually in red) means that I have something that meeds to be more permanently captured.
The next line is called my "private wiki". Working at Socialtext, there are a variety of workspaces and other items I use, some more private than others. I have a dedicated Wiki space where I go through and create full how-to guides on certain topics. Sometimes things that I use create short and potentially interesting, but limited, test ideas. This temporary wiki allows me to experiment, see what makes sense, what doesn't, and lets me play with parameters and consider approaches that might make for decent maxims to share. Again, the more often edited and refined, the more likely I'm working with something other people may find valuable.
The third line is the "public wiki" or group workspaces that we all share. We are all encouraged to actively go through and add to the "HowTo" documents. Additionally, if we find outdated information or details that do not line up with current reality, we are welcome to review, confer, supersede and even archive older data that doesn't meet the current reality. we refer to this as "gardening the Wiki", and it's everyone's responsibility to make sure that we are all sharing relevant and timely information.
Bottom Line:
The goal of al of these methods is to go through some simple steps. The cycle of Capture -> Analysis -> Practice -> Synthesis -> Synopsis is ongoing, and circular. Information can get stale rapidly if it is not consistently examined and the approaches applied. For many the capture part is the most important, but all steps needs to be examined and worked through to have the best effect. We can capture huge amounts of data, but if we don't actively practice the other steps, capture will be almost meaningless. Find what works for you, and make a habit at getting better.
No comments:
Post a Comment