All I Ever Need to Know about Testing I Learned in Kindergarten


In addition to presenting a tutorial and a keynote address at the EuroSTAR testing conference in Copenhagen, Lee Copeland was asked to give the after dinner speech at the closing gala reception overlooking Tivoli Gardens. He chose to model his comments after Robert Fulghum's book "All I Really Need to Know I Learned in Kindergarten." But in his speech, Lee changes the rules of childhood into guidelines for living life as a tester.

In 1986, Robert Fulghum published a book, "All I Really Need to Know I Learned in Kindergarten." It contains some wonderful ideas. I'd like to discuss how those might apply to us as testers.

Share everything
Once I observed a situation in which a tester, with better knowledge of an application domain than an inexperienced developer, used his knowledge to find and report bugs in a system. He could have shared this knowledge with the developer, but wanted to stroke his own ego and pump up his bug report count.
Our profession advances when we share information instead of using it for our own purposes.

Play fair
Here are some other things I've seen testers do:
One tester reported the same defect over and over again with slight variations to pump up her bug report count.
Another tester discovered a significant defect during a design review but did not inform the developers. He waited until the defect was implemented in code and then filed a scathing defect report.

What goes around, comes around. When we don't play fair, we become untrustworthy. Then others won't play fair with us. It's lose-lose all around.

Don't hit people
If you find a defect in someone's work, first tell him informally, personally, and discreetly.

Once a co-worker gave me a document he had written and asked for my review. I didn't get to it until the last minute. Rather than talk with him in private, I blasted his work publicly in a meeting. Later, he came to me and simply asked, "Why?" I still remember the look in his eyes, and I have never done that again.

As a tester, remember that we are paid to "hit" software, not the people who wrote it. It's the software that's buggy, full of holes, not worth the ink used to print it, and, as James Whittaker likes to quote Neil Young, "A piece of crap."

Rather, remember Norm Kerth's gentle words: "Regardless of what we discover, we understand and believe that everyone did the best job they could, given what they knew at the time, with their skills, abilities, and the resources available."

Put things back where you found them
You probably use a test lab. It's probably a common resource used by other testers. When you are finished, put things back--reconfigure the hardware, restore the software, reload the test data, set up the accounts, and reset the parameters.

In one organization I visited, the lab had a sign on the door that read "Test Lab." Everyone else in the organization read it as "Spare Parts Room."

Clean up your own mess
And while you're at it, throw away those pizza boxes and coffee cups.

We have a rule at my house, "It's OK to spill." No one ever gets yelled at for spilling. But we have another rule, "Clean up your mess." That one you will get yelled at for not doing.

Even better, try not to create messes in the first place. One way to do this is to write clear bug reports--ones that will really help your developers find defects quickly; not reports that will lead them on wild goose chases for your amusement.

Don't take things that aren't yours
One thing people take that isn't theirs is credit. Once my boss asked me to research something. Later, I wrote a memo, which began, "To: Boss, From: Lee." The next time I saw the memo it read "To: Big Boss, From: Boss." He took my work and didn't give me any credit. I learned something from that experience. From then on, I always

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.