Karen Nicole Johnson

I’ve been writing. I’m pretty much writing all day and as much at night as I can. I’ve been writing seven days a week.

I found myself hiding to write earlier this week and thought how hard all this writing might be for someone who doesn’t like to write. But it occurs to me that all testers need to write at least some of the time. And test managers even more so.

So this blog entry, I’m sharing some of my writing tips.

It depends on the environment you work in whether formal documentation with test cases, test protocols, final reports, etc. are required but even in less formal environments, there are test cases that need to be written. Test plans, test protocols, validation reports, defects reports, etc. All tasks that require writing.

Once in a casual environment that I worked in, I wrote high-level test cases in html and posted the test cases on the intranet to share what I was testing and to encourage ideas to be exchanged. Everywhere I work, I leave behind reusable test cases in some format. So there is always writing.

Suggestions:

o Write an outline.
An outline can help you think through what you need to include. Outlines can help you determine major and minor elements. An outline is a good start. Once you have an outline you can work in small chunks and that helps. It’s less intimidating to work on one part than trying to write a “whole” document at once.

o Work in bursts of time
Use your outline. Focus on one section at a time. Set small deadlines. In one hour can you write this one section? (Writing sessions are often like testing sessions, you can work in bursts.)

o Create a conducive environment
Find whether you need quiet or need some noise. Does music help or hinder? Do what you can to make the environment conducive whatever that means for you.

o Think wide then narrow
Write the larger elements first. Look at help files, you’ll typically find great examples of one page pieces written on many topics. I often look at the help file of a product to guide me with my outline. Once you’ve drafted the larger topics, go back through and flush out the details.

o Focus on the content
Never (a word I use sparingly) focus on the length. Word count is for 8th graders who have compositions to complete. Ask yourself if you hand over your writing to someone and if they would understand everything you needed them to. Pretend that you couldn’t talk to the person to explain anything – does the piece you have written say everything you would need it too? That’s what counts.

o Ignore grammar
Acknowledge the value of grammar but don’t let grammar stilt your writing. It’s more valuable to communicate clearly than to have perfectly constructed prose. More people would write and would enjoy writing if they didn’t obsess about writing it “properly.” Get it down. Worry later or ask someone else to edit.

o Don’t confuse writing with editing
Avoid rewriting each time you read through your draft, you’ll never get to the end if you feel you have to “fix” everything as you work. Get it out. Get it down. Nearly everyone likes to edit so you will always get opinions once you have a draft.

For anyone who doesn’t want to hear personal stuff, this is the end of my entry. Good luck with your writing.

For anyone who’s wondering, what is she writing? Read on.

I’ve had nine test protocols I’ve been writing in the past nine working days. I can’t say more than that since I honor confidentiality.

For the month of December, I’ve also had a goal of completing 12 “chunks” of writing (or about 15,000 words if you can’t get over counting) for a writing project I’m working on.

I’ve also been forming and drafting ideas around two different papers I want to write in 2007. I’m starting with the abstracts. I have two ideas lodged in my head – and two different conferences/workshops for which I plan to submit my ideas.

It’s a helluva a lot of writing and time is tight. I have one big advantage; I enjoy writing. Another advantage is that I worked as a technical writer – for seven years, which is a decent block of time. And I was a newspaper reporter for two years and oh yeah; I also majored in journalism with a minor in English (not C.S.) So for me, hiding from people to write is a joy.

Recently I had an entire day off unscheduled and unplanned. It was absolutely great. We had a snowstorm and outside was beautiful. Snow is only beautiful if I don’t have to go outside.

Hanging around the house, I had a couple of experiences that made me think of Elisabeth Hendrickson’s term test obsessed. It’s a good term. And I could see again, how I think like a tester. Testing has affected how I think about everything.

I used the iron and found myself thinking mmm I haven’t used this in awhile. I wonder if the auto shutoff really works. So I left the iron and to see if the feature still works. What a perfect day to check this out I thought. I don’t usually test hardware. Or then is it software inside the device that dictates the shutoff? And how does the device distinguish time? Over time will the device’s clock malfunction and lose track of time? Who tests the timers in home appliances? How do appliance testers test?

When I ran the dishwasher and the sink backed up enough to flood the countertops I was curious why? Is the drain clogged? Is the issue with the drain, the sink, the garbage disposal or the dishwasher? Will this happen on the next wash? I was reminded of James Bach’s dead bee heuristic. Why did the sink flood? I wanted to find the cause. I wanted to see the dead bee.

As I spent the day at home, I found myself checking things out. So what does all this have to do with testing? It answers a question I’ve been asked many times. What is the number one skill I look for when I hire a tester? Curiosity. (Not certification.)

One particular definition of curiosity says it well: curiosity is an interest leading to inquiry, intellectual curiosity.

Technical skills can be taught. And technology changes frequently anyway. (Yes, I recognize technical aptitude can be an issue.) But a curious mind is harder to train into someone.

Testing becomes a way of thinking and once bit by the testing bug it affects how we look at any object or process.

Consider doing something different in 2007. Write a paper on a testing topic that you feel strongly about or a testing topic you have a great deal of experience around. And present at the Conference for the Association for Software Testing.

Presenting isn’t as scary as it sounds. The testing community may be filled with some tough critics because testers are more or less critics for a living but hey, we aren’t toastmasters and no one expects you to present like a marketing pro. True experience and interesting stories are a valuable contribution to the community. When you present to a community of testers at least you’re with a group of people who understand what you do for a living. Be a little brave.

Now during the cold dark days of winter (for many of us), is a great time to sit indoors and write a paper. The writing process and the thought of publicly distributing a paper will make you think clearly about a topic. Writing can help you solidify your thoughts. When you put your paper “out there” like-minded people will find you. I’ve met some amazing people because I’ve the courage to stand up and speak.

To start, all you need is an idea then submit an abstract explaining what you’d like to write and talk about. Take a look at the Call for Papers on the Association for Software Testing site. I’m working as a program co-chair for the conference so if you need more information, you can contact me. Envision this summer when you can be in Seattle and talk with like-minded people about software testing.

For the current primary contract I’m working on, I sit in a cube, bouncing back and forth between a test lab and my desk. My desk means little to me other than the laptop contents and the need to sit somewhere.

Now it’s interesting sitting where I sit. A row of employees sit on one side of the hall. And the contractors sit across the aisle. The employees talk intermittently through the day. On the contractor’s side, banter is minimal. The reality is we are contractors and since we are paid by the hour, no one wants to hear us chattering.

On the employee side, it’s a very congenial group that genuinely seems to get along and treat each other with respect. They chat about topics nearly any adult could relate to. Painting houses, barbequing, sports, their kids, going out for lunch. They are a hard working group and there is an element of daily routine and personal lives being shared that has seems to have lasted a long while.

On the contractor’s side, there are respectful good mornings and brief how are you’s. But I have other things besides chatting with my neighbors to think about. That reality is the same for my contracting neighbors. Where is my next contract, when should I follow up on a proposal. And then there is always reading I want to get to. And I have a writing project to think about. There are other things to do; there is more to get done. My contracting neighbors express similar concerns – they have multiple things going on – even though those activities vary between us – the point is – this contract isn’t their only focus. And it’s not that employees don’t have other activities but those activities do not appear to be professionally focused activities.

For everything I work on, I think about how it will reinforce a skill I have or help me gain a new skill. If I work on a project that isn’t strengthening a skill or developing a new skill – I know I will leave before long. (Of course I had this mentality as an employee too so why I didn’t make this transition sooner I’m not sure.) My concern is my skills remaining market desirable and competitive. My skills are my responsibility.

When I’m not focused on the job – I leave. I don’t bill for hours I don’t work, I don’t stay seated at my desk when I’m not focused on work for that client. If I need to leave for a few hours to take care of other business, I do. I talk candidly with my client and my client respects my honesty.

It is a different contract to be an employee. And it strikes me as a naïve contract. Generally, there is an expectation that the company will take care of them. On the employee side of the hall, they work their hours (and many employees will crank in extra hours at times) but the belief prevails that the company will take care of them. And because the company is taking care of them, I see less concern about maintaining marketable skills. Ironically making employees more dependent on the company and the cycle continues. A dependency cycle. It is a different point of view to be continually for sale because you focus on your skills and value. Is there any other reason to sit in a cube?