那些測試的知識我都曾在幼兒園裏學過
--- 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.
