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?

This past month, I was a customer to a contractor. I hired someone to complete a house project for me. And I’ve been a contractor for a customer. I was hired to complete a body of testing. In the same month, I bartered testing services for html work with a web designer.

It’s been interesting to experience both sides of the professional table at the same time. The basic task of estimating is the same despite the work being vastly different. I learned that estimating isn’t just a nuisance task to get management off my back. Or to fill a Gantt chart to appease a project manager. It turns out that estimating is an essential task because without good estimating, how can I tell if I’m truly available?

Estimating inaccurately hurts. It hurt when my contractor accepted more work than I wished and I was forced to wait for his services. I finally had to request that unless services could be performed within a specified period of time I would get someone else. I thought carefully about how to say this in an effective way since I wanted this particular contractor to take the project.

It hurt when I took on more than I could and I knew I had frustrated someone like my contractor had frustrated me. I’m grateful the two experiences aligned in time so that a message about estimating was beaten into my head because sometimes subtle doesn’t work for me.

Estimating is about gauging a body of work. Past a raw number of how long the work will take, I think there are three questions often being asked within a request for an estimate. What clients truly want to know is:

Are you available?
And to what extent are you available?
And where on the coming calendar does my work fit in
your schedule?

That’s certainly what I wanted from my contractor. How does the body of work being estimated fit into the current or coming calendar with other work and competing demands? No wonder estimating is difficult because inside an estimate request there is often an unspoken expectation about scheduling the work. And an estimate and scheduling are not the same.

Scheduling includes gauging the coming calendar. How the work will fit into the current or coming calendar? A holiday week can throw a schedule. But that’s obvious what’s more challenging is how one body of work may align in time with another body of work to create an unexpected mess of time. Otherwise known as chaos.

Preventing chaos is enough incentive to make scheduling a distinctly separate topic.

I told Pat, a friend of mine, that I had just begun blogging and he asked me, why? Why are you blogging and why should I read your blog? Pat says he’s checked out numerous blogs and continues to find content he doesn’t find value in. As he said, too much “what I had for breakfast” content for him to consider reading blogs as time well spent.

He couldn’t have raised the question “Why Blog?” at a better time for me since I had just posted my first entry. I took his questions to heart. My answers to those questions will be my blog guidelines.

What’s in my blog?

Subject matter guides the content. I want to focus on four T’s: testing, technology, tools and techniques. But it’s not just facts. My blog is about sharing my insights, ideas and perspectives on these topics. There is a personal element to blogging which brings me to the next question.

Why am I blogging?

To share insights
I want to share some of my insights. Some, ideas I think might be worth public consumption and only insights, ideas and perspectives relevant to software testing. Other life topics and epiphanies belong somewhere else.

To foster the community of software testing
I want to contribute to the community of software testing. And while I’ve been quietly reading for awhile, I don’t want to be a silent member anymore. It’s time to share. A benefit of blogging that I hadn’t anticipated before writing was the sense of community I feel. Previously, I only felt the community of software testing at the conferences I attended or phone calls with people in our field. Blogging has changed that feeling for me.

To learn
There is nothing like public speaking or writing to make me think as carefully and as clearly as I am capable of. By pulling my own thoughts together, I learn. By reading other people’s entries and participating by sometimes posting, I learn.

When will I blog?

I will ask myself before posting is: Is my idea ready for public consumption? I will only blog decently formed ideas. My ideas don’t have to be as polished as a published paper or article but my entries have to be more than raw thoughts.

But I also want to give myself some space. I enjoy the freedom of blogging. Blogging isn’t about a perfectly polished paper nor should it be. Sometimes, blogging is an opportunity to share an idea when the idea is at the seedling stage. This means I can enjoy writing without fretting about perfection. I’ll know from comments posted whether my insights resonate with other people or not. (So post comments.)

So, why would you read my blog?

To hear my thoughts about one of the four T’s: testing, technology, tools and techniques. See how our thoughts align or don’t. You can post conflicting thoughts. You can push me to defend, shape or polish an idea.

To join me in a learning exchange. You might learn from an idea I share. You might post a comment that helps me. Our entries may help other people, specifically other testers. We can alternate between teaching and learning. We can provide answers to seekers and have a place we can both seek.

Earlier this month, I was at PNSQ and heard Andy Hunt present a keynote on Improving Cognition and Learning. Andy suggested maintaining a knowledge portfolio. My mind started flipping backwards through past technologies and tools I’ve learned. The term made sense to me instantly.

Cem Kaner spoke as a panelist at PNSQ. He suggested maintaining work samples which triggered similar thoughts. Would I want to pull out an old test strategy document and show that as a sample of what I know or have done? What would I want to show?

I’ll learn a technology or a tool that’s relevant to the project I’m focused on and when it’s over, I’ll forget about it because I become focused on the next project. Some tools I keep in my utility folder and other bits of knowledge, I forget about. Given that I purposely seek projects that are not alike, I’ve gained a varied knowledgebase. So how would I show that?

Some years ago, I was a newspaper reporter and there is a standard in the field to maintain a portfolio. I still have mine. It’s a large leather case with newspaper clippings. The key in the newspaper world is to show your byline. What would the key in a testing portfolio be? What would a testing portfolio look like?

Can I combine the concept of a knowledge portfolio and work samples so that I can show and articulate to someone what I know or have done? How could my knowledge portfolio or work samples demonstrate what I might be capable of learning in the future since both of these are focused on the past? In a field where resumes are scanned for keywords – if I can’t show an exact match on a technology how can someone assess whether I could learn yet something else? To me, this is the next part of participating in a conference, putting ideas into reality. I have some thoughts around how I may pursue this and will post more.

I was told to just run the install the other day when I needed an application loaded on a test PC. I’m sure I winced when I heard this because I can’t just run an install. I need to understand what an install is doing to my test PC. An install can be filled with files and registry settings that just running an install strikes me as a haphazard activity. My previous experience as an install tester has left me cautious of running any install or update without knowing what the update contains.

It’s been awhile since I’ve tested a desktop application but I was able to find my old favorite utility Inctrl pretty easily. Inctrl is a utility application that has been around for several years and is now on version 5. Inctrl5 does an excellent job of tracking every file, folder and registry setting added, changed or deleted during the install. I’ve used the output report to compare what was supposed to be installed against what was actually installed. Install testing aside I’ve used the utility to help me understand the registry settings and dlls an application uses – it helps me to know what an application truly consists of.

So I did run the install the other day but with the use of the utility, I didn’t just run the install, I know the before and after state of the test PC.

One small task I currently have is using small text files to feed a test simulation application. Each character provides either data or a setting of significance to the test. This means I need to read small text strings and count carefully to update the alphanumeric characters. If I’m off by a character, it can affect the test dramatically so I have to be very careful. It is a tedious but essential task. I tried importing the unformatted text into Excel but had no luck. I’ve tried reading and counting slowly in notepad but when I have a long string of zeroes, it can be easy to lose my place. I’ve been experimenting with my hex editor (since I sometimes need the hex value too) as a tool to help me read the strings and count the characters. The visual use of the grid makes counting easier for me. And the fact that the hex value appears on the same view is convenient.

I was traveling from the airport to home the other day listening to the limo driver complain about the new credit card validation system. The theory was that credit cards would be validated through the Nextel phone. The communication connection couldn’t be made so the reality was the driver skipped validating my card. He said he hasn’t been able to validate any cards since the new system was installed.

I asked some questions: How long have you had the new system? 3 days. What happened to the old system? It was removed from the car. Did he have a chance to test or become familiar with the new system before the old system was removed? No. Did he know if the new system was tested in any cars or was it only tested in an office test lab? He didn’t know.

The product might have been tested in an office test lab before it was rolled out to a few test limos. But how does a limo compare a lab? In a limo there would the factors of a moving vehicle, telephone wires overhead, other cell phones nearby and the possibility that the driver might turn the radio down vs. off providing multiple frequency disruptions that can’t all be simulated in an office test lab. And what about the power factor – was the system tested with the phone connected via a car adapter (as my driver was using)?

I can tell when a software issue has captured my interest because I find myself thinking about different variables. My curiosity builds.

I explained to the driver what I did for a living and he was genuinely excited (a refreshing change for me). I gave him my card. I think I’ll call the company to see if they would be interested in my services. I’ve tested in a several different test labs over the years but never in a limo. Maybe I can get a stretch?