TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPass
Home  >  Detail: All I Ever Need to Know about Testing I Learned in Kindergarten



A StickyMinds.com Original
Article Picture
All I Ever Need to Know about Testing I Learned in Kindergarten

By Lee Copeland

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: Recently, Lee Copeland participated in the EuroSTAR testing conference. In addition to presenting a tutorial and a keynote address, Lee was asked to give the after dinner speech at the closing gala reception overlooking Tivoli Gardens in Copenhagen. 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, which we've reprinted as the column of the week, Lee changes the rules of childhood into guidelines for living life as a tester.


Telelogic North America
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 took memos that my staff had prepared and put a sticky note on them that read, "My staff member wrote this . . . I think it's good work . . . I hope you concur."

Another thing people take that isn't theirs is guilt. You will not find every defect. Try hard, use your skills, do a good job; but remember, some will sneak by you and that's OK. As Boris Beizer says, "We need devious testers." But sometimes, as devious as we are, our developers and users exceed our capacity.

Say you're sorry when you hurt someone.
No matter how careful we are, at some place and time, we will hurt someone. Most of us will never intentionally hurt anyone physically, but we will hurt him emotionally. We'll say something or do something--perhaps intentional, perhaps in ignorance, or perhaps in jest--that will reach into his chest and rip out his heart.

As testers, we're in the error-discovery business. Our job is to find other people's mistakes. When we find them, we report them publicly. We know to always focus our reports on the errors, not the person who made the errors. But still, sometimes egos are bruised; sometimes feelings are hurt.

Say "I'm sorry." It is one of the most powerful, healing phrases in the human language.

Wash your hands before you eat.
In other words--start clean. Once the system fails, it may not be in a stable state to look for more defects. Reboot or reload often.

Flush.
This is always good advice. And, as a professional user of airport toilets, I am amazed at the number of men who don't know to do this. Of course, a real tester would flush all the toilets at once, just to see what happens. Could you do that with your software too?

Also, always remember to flush the cache when doing performance testing.

Sometimes features need to be flushed from the product before shipment because they are so problematic. Sometimes entire projects need to be flushed. Perhaps you can help--maybe you can even pull the handle.

Warm cookies and cold milk are good for you.
Yes, they are. Enough said. (Oh, it's better if your employer furnishes them. And chocolate chip cookies are the best.)

Live a balanced life.
There are things in life in addition to testing--friends, family, travel, sex, food, rest, sex, health, fitness, art, recreation, good deeds, sex, spirituality, learning, play, and, of course, introspection.

It is difficult, especially in the early years of our careers, to put work aside and focus our attention on other things.

But, as the great philosopher Ferris Bueller once said, "Life moves pretty fast. If you don't stop and look around once in a while, you could miss it."

From a testing viewpoint, create diversified test teams and develop diversified test strategies.

Learn some, think some, draw some, paint, sing, dance, play, and work every day.
This one is more difficult to apply. How about "Learn some, think some, model some, explore some, document some, communicate, and test every day"?

Take a nap every afternoon.
If you work in an office with cubicles, taking a nap in plain sight is probably not a good way to win friends and influence people. However, we all need quiet time to be with ourselves--time to think, time to reflect, time to rest, time to regenerate. Try to establish your own quiet time--a time when you don’t read email, answer the phone, attend meetings, or allow interruptions.

Taking a step away from your project will give you fresh insight and a different outlook. When you come back to the problem, you often have your own "a ha!" moment.

When you go out in the world, watch for traffic, hold hands, and stick together.
There is great strength in teams. The days of "us vs. them" are over. The days of "throw it over the wall to the testers" is over. It turned out that idea was about as successful as Communism.

Synergy is the concept that the whole of us is more than the sum of us. In years past I ran an experiment in one of my seminars. It was based on a "Lost in the Desert" exercise in which individuals are given a problem to solve, and then they solve the same problem again in teams. When working together rather than as individuals, 98 percent of the time, the team score was better than the average of the individual scores. And 95 percent of the time, the team score was better than every one of the individual scores on the team. Working together as a team is better, smarter, and more powerful than working as individuals.

Be aware of wonder.
I have a four-year-old granddaughter and a two-year-old grandson who live with me. Imagine, at my age, I'm doing the "father" thing all over again. And it is a fabulous experience. You see, I had forgotten the "wonders" in the world: the wonder of butterflies and bugs; the wonder of the rainbow; the wonder of first words; the wonder of fire trucks and cement trucks and bulldozers and diggers of all kinds; the wonder of heartfelt hugs; and the wonder in a child's eyes and smile.

Be aware of wonder as a tester: the wonder that they made so many stupid mistakes; the wonder that so much actually does work; the wonder that your organization is still in business; the wonder of your own talent as you discovered an amazingly convoluted bug in the code; and the wonder that you have so much fun and get paid for it.

The world is full of wonder. It is a wonder-full world. I wish you a wonderful life. Good night.

About the Author
Lee Copeland has more than thirty years' experience in the field of software development and testing. He has worked as a programmer, development director, process improvement leader, and consultant. He has developed and taught a number of training courses focusing on software testing and development issues based on his experience. He is a technical editor and regular columnist for Better Software magazine and StickyMinds.com. Contact Lee at lcopeland@sqe.com.

Back to Top
 
 


Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Pam Hickox 7/26/2007

Great article. I have also heard it said that "A great tester is one who can tell a developer that their "golden haired child" is ugly without making them mad! (I've added ... and have the developer agree.) :-)

 
 
Comment:    
by Anne Simoncelli 6/7/2007

"Flush" equals "reboot after a hard crash," a best practice that is often ignored, at the expense of the developer (time wasted) and tester (subsequent buggy behavior marked "can not duplicate", credibility suffers).
In fact, "flush" probably should equal "cycle power" and not just "restart Windows".
If you can duplicate the problem after 'flushing' - go ahead and report it.

 
 
Comment:    
by Duane Harnish 1/3/2007

You forgot one... HAVE FUN! Testers should inherently enjoy being creative and "playing" with the software. If not, maybe you need to find another toy (different product that interests you more), another teacher (different boss), or perhaps even a different kindergarten (different company).

 
 
Comment:    
by Emily Joseph 1/30/2006

This article opened my eyes. We need also to remember when looking at defects for the first time, is very similar to the first time we see the 64 Crayola box, never realizing there were so many colors...

Author's Response:
1/30/2006    
Thanks Emily. I remember that day. I still remember Burnt Umber

 
 
Comment:    
by Isabel Evans 1/29/2006

Hi Lee A lovely, encouraging, cheering column - thank you! An important aspecting of sharing - as well as sharing our knowledge - is telling other people what we don't know and when we don't understand, because otherwise they'll assume we have understood... I remember being on a student placement when I was at college, and another student saying to me "Never ask questions, never admit you don't understand." Even then it seemed to me a foolish attitude, now 30 years later I'd see it as... But admitting you don't know is hard - and I think it gets harder as one gets older, and other people rely on you more... best...Read On

Author's Response:
1/29/2006    
Isabel, thank you for your comments. I have found responses such as "I don't know", "I'm not following, could you explain this to me", and "please help me understand" to be incredibly freeing. Once I acknowledge that I am not all-knowing, it is easier to work together. Cheers!

 
 
Comment:    
by Erik Petersen 1/26/2006

For Flush, I'd mention the importance of group play, e.g cards with a flush, table tennis, etc, especially involving both dev and test teams. Best one I ever heard of was we had a guy addicted to coke (the drink!) who had several hundred cans in an organized pile on his desk. When he was off for a day, we built a life size coke-man with wire and tape, and sat it in his desk. Of course we were "flushed" with pride afterwards.... ;) And there is always the flushed look that some people get after serious partying or lunching. That is when you need a nap....!

Author's Response:
1/26/2006    
Thanks for your comments Erik. Best wishes with future wire and tape projects.

 
 
Comment:    
by Sidney Snook 1/26/2006

...I was going to comment on your article...but its nap time....

Author's Response:
1/26/2006    
Well Sid, when you wake up, let's chat.

 
 
Comment:    
by Lisa Crispin 1/26/2006

It's great advice, especially for those of us who have done this a long time and think we know what we're doing! I wish there were a way to work in actual naps, though!

Author's Response:
1/26/2006    
Well, Lisa, back a long time ago, when I was Director of SomethingImportant at SomePlaceThatWillNotBeNamed, I had an office with real walls and a door. That's when I learned the importance of naps.

 
 
Comment:    
by Robert Rose-Coutre 1/26/2006

This is definitely a "Copeland Classic" and very fun and enlightening. Lee—I hope you will publish a book of your collected columns. My only comment is to emphasize the importance of taking a nap every afternoon.

Author's Response:
1/26/2006    
A "Copeland Classic"? Robert, I know I'm getting old but a "classic"? Great to hear from you again. Gotta' go -- it's nap time.

 
 
Comment:    
by Priti Borse 1/25/2006

I have recently joined Testing Area, Performance testing in particular. It was very refreshing and reassuring to read your comments on testing. Specially I liked the FLUSH and START CLEAN which I or usually all tend to forget. Also, overall your comments say be Humane and professional vs just professional. Afterall being a humane first helps build the strong, trustworthy teams.

Author's Response:
1/25/2006    
Your comment reminded me of some things Jerry Weinberg has said: "When survival is concerned, there's no choice but to put people first." "Leaders who don't care about people don't have anyone to lead, unless their followers have no choice." "Very little work we do is really so important that it justifies sacrificing the future possibilities of the people doing the work." "If you are a leader, the people are your work. There is no other work worth doing."

 
 
Comment:    
by Erik Boelen 1/25/2006

Very nice article indeed, with some interesting new points of view on testing. I think both new and experienced testers should read this. It will both help people on the way, as put them back with their feet on the earth. By the way, 'stickyfingers' launched an interesting discussion about this article in the discussion board. The title of the thread is: "All I needed to Know, I learned in Kindergarten SHARING", and can be found under the general testing discussion...Read On

Author's Response:
1/25/2006    
I just read the discussion thread - it expresses concerns about sharing information with people who are not ready to receive it or use it well. An analogy might be giving the car keys and a booster chair to an 8 year old. I still like "sharing" as a general rule but I agree with your concerns.

 
 
Comment:    
by Peter Veeken 1/24/2006

Thank you for a great article Lee, I remember reading Robert Fulghum's book years ago and really liked it - They are such a simple set of rules for success that I despair why more people don't follow them - work and life would be much better if we all did. Like yourself, as a 30 year veteran of the IT industry, there is not enough space to share the frustrations I've had/witnessed when people don't follow these simple rules and the most frustrating bit is that some people don't learn from their mistakes. Cheers. Peter

Author's Response:
1/24/2006    
Thanks Peter. I appreciate your comments.

 
 
Comment:    
by Steve Driscoll 1/24/2006

I really enjoyed your article. Your anecdote about sharing information reminded me of a co-worker from years ago. He was very knowledgeable but considered difficult to work with. So he was rarely included in planning meetings. So he often "shut down" in order to get along with others. In one meeting I found a key to get him ( and others ) to open up, and I want to share it with you. In this meeting, the project manager outlined their approach in great detail. My coworker sat thru the meeting completely silent, trying to get along. After the meeting I spoke with him and learned that he knew of a major flaw in the...Read On

Author's Response:
1/24/2006    
Yes, I often ask a similar question in my consulting work - "Are there any other questions that I should have asked you?" I'm often amazed at the things I missed. Thanks Steve.

 
 
Comment:    
by Jim Little 1/24/2006

Lee, this is a great article. I especially like the point of share everything. It is amazing today how many people, QA, Development and beyond, still feel that keeping knowledge to themselves is to their own benefit. Sharing knowledge with your associates not only shows what you know, but that you have the ability to share it in an understandable way. -- Jim

Author's Response:
1/24/2006    
Thanks for your kind words. As a hobby, I used to do research and writing on historical topics. (I gave it up because it doesn't pay well. Actually, it doesn't pay at all.) But, while researching, I hung out in libraries a lot. I discovered that librarians are really cool people. They know where all the good stuff is. One librarian had a shoebox full of 3x5 cards on which he'd accumulated really useful bits of information over the years. If you had a question, before looking anywhere else, he'd look in his shoebox. He was always ready to share the informaton he'd collected (on company time) with library patrons, but he wouldn't share it with other librarians. He realized the truth in Francis Bacon's statement, "Knowledge is power." What he didn't understand was that teamwork and synergy create power also.

 
 
Comment:    
by Wolfgang Schneider 1/24/2006

Great article - made the same experiences in 30 years of development and testing. I also started to tell the developers about the problems in private before "publishing" them. Interesting that you had just 95% in the "lost in the desert" thing. There is always one person in the seminar who is better than a team - due to special knowledge the team does not fully accept. But his/her team is always the best one.

Author's Response:
1/24/2006    
In one of my desert exercises the students first introduced themselves to each other. All but one said they had no knowledge or experience in survival. One fellow, Jesse, commented that he had read a book about it once. Well, it turns out that Jesse is an ex-Army Ranger who has actually been dumped in the desert. But, for some reason known only to Jesse, he did not share his knowledge with the team. Perhaps you've encountered situations where a team member did not share their knowledge.

 
 
Comment:    
by Sandy Flann 1/23/2006

This is great! An excellent and positive way to start my week. I'd love to see a StickyMinds article on "The Tao of Testing." <grin>

Author's Response:
1/23/2006    
Sandy, thanks for the compliment.

 
 
Comment:    
by Shannon Brown 1/23/2006

Thanks for the thoughtful approach. Many of the items you mention are good lessons on a personal level, as well as a business level. I especially needed a reminder about "wonder" as I sometimes become jaded in the Corporate America world and tend to focus on the things that need fixed rather than the things that work well.

Author's Response:
1/23/2006    
Yes, when we focus so much on what's wrong, it's easy to forget what's right. Thanks for your comment.

 
 
Comment:    
by Razvan Anghelidi 1/23/2006

Thanks for a great article! But personally I disagree with the first rule, "Share everything". In an ideal world, there would be no regressed errors. In the same world, once a developer knows about a bug, he will fix it. In my experience, which without doubt is much smaller than the authors', the developers don't always care about an error if it's not in the system. If I don't add it in the defect tracking program, I might even forget about that bug. I'm lucky enough to work in an organization where the number of issues found by testers is not a criteria for performance, but I still report each and every bug for the reasons above.

Author's Response:
1/23/2006    
Hmmm, it seems to me that by entering the defect into a tracking system you are practicing the idea of "Share Everything." You're sharing that vital information with the project team.

 
 
Comment:    
by terri calderone 1/23/2006

This article made my Monday morning. Great advice! Work would be a lot less stressful if even a few of these items were followed by everyone.

Author's Response:
1/23/2006    
Thanks for your comment.

 
 
Comment:    
by Srinivasan Desikan 1/23/2006

Wonderful article. I would rate this as one of the best articles I read. One of the kindergarten lesson is to learn the basics ie. ABCD. I would like to add that learning the basic principles and methodologies of testing should be done before doing the testing. I have seen few testing people asking the definition of regression after being test managers which is similar to studying ABCD in post graduate college.

Author's Response:
1/23/2006    
Thanks for your kind words. Most of the credit should go to Fulghum for his wonderful little book.

 
Back to Top


Marketplace

Web based bug tracking - AdminiTrack.com
AdminiTrack offers an effective web-based bug tracking system designed for professional software development teams.

BugSplat - Automatic Crash Analysis
Fast online exception analysis. Capture customer crash data online.

Six Sigma Certification
100% Online-Six Sigma Certificate from Villanova - Find Out More Now.

New Webcast: How to Profit with Remote Support.
Discover how REMOTE SUPPORT can fuel your IT business in ways you've never thought of before.

Need Agile Test Cases?
Create statistically complete test cases simply and quickly.

Get your product or service listed here.
Subscribe to Better Software Magazine
Subscribe to Better Software Magazine

First Name:

Last Name:

Email Address:


Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2008 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


Skytap, Inc.



STARWEST 2008

 
Agile Development Conference 2008