By Lee Copeland
Summary: 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 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.
Summary: 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 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.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11379785/viewspace-701430/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/11379785/viewspace-701430/
5720
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
