那些测试的知识我都曾在幼儿园里学过
--- Lee Copeland原著《All I Ever Need to Know about Testing I Learned in Kindergarten》
---Kiki翻译于2006/1/26
摘要:最近Lee Copeland出席了EuroSTAR测试研讨会。除了发表一个辅导和主题演讲外,lee还被邀请在哥本哈根的闭幕招待会做餐后演讲。他选择模仿Robert Fulghum的书籍《那些人生中最重要的道理我在幼儿园里都学过(All I Really Need to Know I Learned in Kindergarten)》以作为他自己的见解。但是在他的那篇演讲中(即此文),Lee将这个孩提的法则改变为了测试员生活的指南。
在1986年,Robert Fulghum出版了一本《那些人生中最重要的道理我在幼儿园里都学过(All I Really Need to Know I Learned in Kindergarten)》的书籍。它包含了一些非常棒的思想。我想讨论一下如何将它们适用于我们测试人员。
共享
我曾看到一个这样的情况,有个有着比一个没经验的开发人员更多的关于应用程序知识的测试人员,利用他所知的去发现并提交在系统中的发现的bug。他应该和开发人员一起分享这些知识,而不是想满足自我且拉高自己的bug报告的数量。当我们分享信息的时候,我们的专业素质才会提升,而不是利用它为己私。
公平的游戏
我曾看过测试人员做过另外一些事情:一个测试人员多次提交了同一个但又有轻微差别的缺陷,以拉高bug报告的数量。另一个测试人员在做设计检查的时候发现了一个重大的缺陷,但却没有通知开发人员。他要等到这个缺陷被实现到代码中,然后归档为严厉的缺陷报告。
你的所做所为,也会得到报应的。当我们玩不公平的游戏时,我们就变得不值得信任了。然后其他人也将不会和我们公平的游戏。这是彻底的双输。
不要打击别人
如果你在别人的工作中发现了一个缺陷,首先正式的告诉他,再单独的和他私下谈谈。
曾经有个同事给我一份他写的文档,请求我的检查。我直到最后一分钟都没有开始做。与其私下和他谈,不如我在会议上公开的抨击他的工作。后来,他过来找我,只问了一句“为什么?”。我仍然记得他的眼神,从此我再也没有那样做了。
作为一个测试人员,需要记住支付我们报酬是用来“攻击”软件的,而不是编写软件的人。它是个多臭虫的软件,充满着陷阱,不值得使用打印的墨水,就像James Whittaker喜欢引用Neil Young的话说“一堆废物”。
当然,也要记住Norm Kerth的雅言:“不管我们发现了什么,我们理解且相信任何人都做了他们所能够做的最好的工作,假设当时他们知道,他们的技能,能力和可用的资源”
把东西放回你发现他们的地方
你或许使用了一个测试实验室。那可能是其他测试人员也要用的公共资源。当你完成时,把所有东西都回归到原样-重新配置硬件,回复软件,重载测试数据,设置帐号并且重置参数。
在我曾经参观过的一个机构里,实验室有一个读做“测试实验室”的符号。机构中的其他所有人都读它为做“备用的部件房”。
打扫干净你自己的垃圾
当你还在那里的时候,扔掉那些匹萨盒子和咖啡杯。
在我家里有个原则:“现在可以扔东西了”。没有人不断的被叫唤着扔东西。但是我们也有另一个原则,“清理自己的垃圾”。那时如果你什么都不作,你就会被叫唤扔东西。
最好,首先试着不要制造垃圾。可以做到这一点的其中一个方法就是书写清晰的bug报告-可以真正帮助你们的开发人员马上发现缺陷;而不是引导他们变成供你娱乐的野鸭追逐戏。
不要拿任何不属于你的东西
人们拿走不属于他们自己的其中之一个就是信用。从前我的老板要我研究一些东西。后来我写了一个以“To: Boss, From: Lee”开头的备忘。后来有一次,我看到我那份备忘,却以“To: Big Boss, From: Boss”开头。他占有了我的工作成果且没有给我任何荣誉。我从那次经历中明白了一些道理。从那以后,我总是将我下属准备的备忘上贴上一个贴纸“我的下属写的。。。我认为做的很好。。。我希望你也能感受到。”
另一个人们拿走不属于他们自己的东西就是内疚。你不可能找到每一个缺陷。努力的尝试,用你的技巧,做优秀的工作。但是记住,你会偷偷摸摸的做某些事情,并且很顺利。如Boris Beizer所说“我们需要狡猾的测试人员”。但是有时候,和我们一样的狡猾,我们的开发人员和用户将超出我们的能力范围。
当你伤害了别人的时候要说对不起
不管我们多么的小心,我们在某些地方或时间,都可能会伤害到别人。大多数的人从来都没有故意去伤害别人的身体,但是我们可能会在心灵上伤害别人。我们说或做某些事情-可能是有意的,或许是无意的,再或许是开玩笑的-但那些可能直达他的胸腔,打击他的心脏。
作为测试人员,我们正在做错误发现的事情。我们的工作是发现其他人的失误。当我们发现问题时,我们要公开的提交它们。我们知道总是将我们的报告集中在错误上,而不是制造错误的人身上。但是尽管如此,有时自尊心受到了伤害,有时感情受到了伤害。
说声“对不起”。那是人类语言中最有力,最有治愈效果的句子。
在你吃完后洗手
用另一句话说-开始清洁。一旦系统失败了,它可能不会处在一个稳定的状态以发现更多的缺陷。经常要重启或重新加载。
冲洗
这总是一个好忠告。并且,作为一个专业的飞机场厕所的用户,我对很多男人不知如何使用感到疑惑。当然,一个真正的测试人员要立刻冲洗所有的厕所,只是看看会发生什么事情。你可以和你的软件也这样做吗?
当然,永远要记住在做性能测试时清除所有的缓存。
有时,因为有些功能有很多问题,需要在发货前从产品中清除掉。有时整个项目需要被清除。或许你能够提供帮助-可能你甚至可以推动把手。
热曲齐和冷的牛奶对你有好处
是的,是这样。(哦,如果你的雇员自己提供最好。并且巧克力条的曲齐最好)
过平衡的生活
除了测试,生活中还有许多事情-朋友,家庭,旅游,食物,健康,瘦身,艺术,娱乐,公益,灵性,知识,游戏,当然还有反省。
这是很困难的,特别是在我们职业生涯中的头几年,抛开工作在一边,而集中精力在其他的事情上。
但是,如伟大的哲学家Ferris Bueller曾经说得“生活过得太快了。如果你不停下来偶尔四周看看,你可能会迷失。”
从一个测试的观点看,创建多样化的测试团队并且开发多样化的测试策略。
每天学一些,想一些,画一些,涂,唱,跳,玩并且工作。这个更难应用。怎么样“每天学一些,想一些,模仿一些,探索一些,编写一些文档,沟通并且测试?”
每天下午午睡片刻
如果你工作 在有隔离小房的办公室里,平躺着睡午觉或许不是一个好的可以赢得朋友和影响人们的办法。然而,我们都需要安静的时候和我们自己在一起-时间去思考,时间去反省,时间去休息,时间去重生。试着建立你们自己的安静时间-一个你不需要读邮件,接电话,参加会议或允许打断的时间。
从你的项目中挪出一步来将给你全新的洞察力和一个不同的见解。当你在回到那个问题时,你通常会有你自己的“a ha!”瞬间(顿悟)。
当你走出这个世界,看看路面的交通,手掺手并且互相支持。
这是团队中伟大的力量。“我们对他们”的时代结束了。“抛弃它到墙外给测试人员”的时代过去了。它证明了那个观点和共产主义一样成功。
协同是一个概念,指的是我们一起工作比我们单个的总和更多。在过去的几年里我在其中的一个研讨会上运行了一个实验。那是基于“迷失沙漠”练习的游戏,每个人被给予一个问题去解决,然后他们再一起解决那个问题。当一起工作胜于独立工作,98%的时间,团队的得分比个人的平均得分好。95%的时候,团队的得分好过在团队中每一个人的得分。作为一个团队一起工作比个人工作更好,更精确,更有力。
意识到奇迹
我有个四岁的孙女和两岁的孙子,和我住在一起。试想一下,在我这个年龄,我正在重新做“父亲”所做的事情。它是一个令人难以置信的经历。你看,我已忘记了在世界上还有“奇迹”:蝴蝶和臭虫的奇迹;彩虹的奇迹,第一句话的奇迹,火车,水泥车,推土车和各种各样的挖掘车;真心拥抱的奇迹和在孩子眼中和笑容中的奇迹。
作为一个测试人员要意识到奇迹:他们制造如此多愚蠢错误的奇迹;如此多可以工作的机器;你组织仍然运作的奇迹;当你在代码中发现一个令人吃惊的费解的bug时关于你自己天份的奇迹;你有如此多快乐并且得到报酬的奇迹。
这个世界充满奇迹,这是个充满奇迹的世界。我祝你们有一个奇妙的生活。晚安。
All I Ever Need to Know about Testing I Learned in Kindergarten
By Lee Copeland
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
-------------------------------------------------------------------------------
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 discretely.
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.