The King's Speech

今年奧斯卡最大的贏家, 非"王者之聲"莫屬. 榮獲12項提名, 最後得到4項大獎 - 最佳影片, 最佳導演, 最佳男主角, 最佳原創劇本.

(以下有部分劇情透露)
















"當我演講時, 國民相信我會為他們發聲, 但我沒有辦法演講." -- 英王喬治六世.

故事背景在二戰前夕, 在廣播媒體的普及後, 廣播成為英國王室與國民間溝通的管道. 王子約克公爵自小一直有口吃的毛病, 無法在眾人前順利發表演說.

在父親過世, 哥哥不愛江山愛美人的情況下, 約克公爵即位為喬治六世. 此時英國正面臨著最艱難的時刻: 德國與英國的大戰一觸及發. 如何用廣播去激勵人心變成了喬治六世所面臨的最大難題.

"王者之聲"描述了喬治六世如何去克服口吃, 並在關鍵時刻鼓舞了大英帝國的故事.


"也許他該換個職業." -- 言語治療師萊諾.
演說對許多職業來說, 已經是不可或缺的技能. 它是一個闡述自己想法及理想的管道, 是為了讓他人能瞭解自己想法的溝通方式. 歷史上有許多撼動人心的演說, 像金恩博士的"我有一個夢", 不過短短15分鐘, 影響力卻已超越了45年. 即使基層的工程師, 只要是團體合作, 也會有需要傳達理念的時候; 像解釋產品的設計, 說明一些有趣的創意, 亦或報告工作的成果, 都需要藉由簡報來陳述.

要如何成為一個有影響力的演說者? "練習"是不二法門.
沒有人生下來就具備那些演說技巧, 大師也是經由後天不斷地磨練而成長.
賈伯斯二十歲三十歲時的簡報風格與現在差異很大.
好好地把握每一次簡報的機會, 不斷精進自己, 造就了今日他卓越的簡報術.
我們只要每次都比前一次進步, 相信假以時日, 簡報技巧的成長就會相當可觀.
愛迪生曾說過. "如果把所能做的事都完成, 我們最終將對自己大吃一驚."
與大家共勉之.

---------------------------

The 83rd Academy Awards belonged to The King’s Speech, which won four Oscars from its 12 nominations, including Best Picture, Best Actor (Colin Firth), Best Director (Tom Hooper), and Original Screenplay (David Seidler).

(The synopsis is included below)

"The nation believes that when I speak, I speak for them. But I can't speak." King George VI of Britain said.

The story opens in 1925, before World War II.
Radio is getting popular, and becomes the communication media between the royal family of England and citizens. Prince Albert, the Duke of York (the future George VI), has a speech impediment, so he can't give a speech to the public.

But his father King George V’s death in 1936 and his elder brother Edward’s sudden abdication as King in December of that year suddenly thrusts Albert into the spotlight as the next monarch of Great Britain. It is a tough time of Great Britain, because the war against Germany starts. How to speak persuasively by radio to inspire the public becomes a difficult problem for him.

"The King's Speech" is a story of George VI to find his voice and boldly lead the country through war.


"Perhaps he should change jobs." The speech therapist, Lionel Logue, said.

The ability to deliver an impressive presentation is a crucial skill for many jobs. Presentation is a way to expound and propagate thought to people, and is a method to communicate with others.

There are some classic speeches in history. "I Have A Dream" by Martin Luther King Jr, is only 15 minutes long, but the impact has already been over 45 years. Even for engineers, delivering a good presentation is necessary for teamwork. It is through the presentation to explain the design of products, to make a description of novel innovations, or to show productivity to the boss.  

How to be a good presenter? The most important three ways are practice, practice and practice. 

No one is born with great presentation skills. Masters practice over and over to be masters. Steve Jobs' current presentations are very different from the ones in his twenties. Cherishing every opportunity to make a presentation and improving himself continuously result in his excellent presentation skills today. If you can always do it better than last time, after some time, your growth must be considerable. 

"If we all did the things we are capable of, we would astound ourselves." Thomas Edison said.

Let's work on it together!

Hot or Not? GUI Automation

軟體測試中, 最直覺的測試方法就是直接操作使用者介面, 然後觀察介面上的回應是否符合預期.
舉例來說, 要測試小算盤這個程式有沒有問題.
就是打開小算盤, 按"3+4=",
如果螢幕上顯示7. 那代表運作正常.

開發團隊為了節省回歸測試 (Regression test) 的成本, 想導入自動化測試.
寫了一隻程式去點3那個按鈕, 再依序點+, 4, =等按鈕.
最後檢查輸出欄是否為7.
測試完加法運算, 還有減, 乘, 除, 開平方等功能需要測試.
辛苦地完成了所有的測試程式後 (可能幾百項到幾千項),
某一天產品經理說: "這個使用者介面不夠炫, 為了市場需要做些調整."

當使用者介面改變後, 測試程式還能運作嗎?
看情形, 大部分的情況下都是需要調整的. 只是改得多改得少而已.
你可以想像當測試項很多時, 一個個地修改需要耗費的時間與精力.
更糟的是, 一個月後產品經理又說: "上次修改的部分不是很受市場歡迎, 讓我們再調整一次."

根據上面的情況, 讓我們思考一下.

1. 使用者介面常常改變嗎?

    跟產品底層的邏輯比起來, 使用者介面改變的頻率高很多. 可能顧客反應使用起來不夠直覺, 或是現有的設計上有漏洞, 也有可能因為公司高層一句話說改就改了.
    還一種狀況是, 在開發軟體的下一個版本時, 為了讓使用者感受前後版本有所不同, 通常也會調整使用者介面.
    資源有限的情況下, 自動化測試因為介面的改變而沒辦法累積下去是很可惜的.


2. 我們是不是可以把自動化測試包裝的好一些?

    是的, 這能應付某種程度的使用者介面改變.
    像是用關鍵字將事件抽象化, 把使用者介面的操作包裝在關鍵字內.
    但抽象化也不是萬靈丹, 如果介面的改變超過了本來關鍵字涵蓋的範圍, 還是要針對每一個測試項去改.


3. 既然使用者介面常常改變, 可以只做單元 (Unit) 或是API的自動化測試嗎?

    這二種測試不受使用者介面改變的影響, 聽起來很棒不是嗎?
    但相對地, 也無法測試到使用者介面上的臭蟲.
    可能每次自動化測試都有通過, 但顧客拿到產品後一打開使用者介面就馬上當掉.
    對整個產品的品質來說, 還是有些風險.


到底使用者介面上的自動化測試值不值得投資?
這類型的測試開發成本很高, 但似乎又不應該完全放棄.
針對這個問題, Mike Cohn的部落格有一篇很棒的文章.
"自動化測試金字塔中被遺忘的一層" (The Forgotten Layer of the Test Automation Pyramid)

自動化測試金字塔

金字塔最底層的部分是單元測試, 這塊面積最大; 面積的大小代表理想的自動化測試程式組成比例.
單元測試是所有測試的基礎. 產品由一堆小單元組成, 只有當每個單元都各自運作良好時, 產品才能運作正常. 大量的單元測試確保了大部分的元件都能夠運作. 如果單元測試沒有通過, 因為每個單元都很小, 所以除錯並不困難; 從10行程式碼中找出問題一定是比從1000行容易得多.

最上層的部分是使用者介面測試, 對於某些沒有介面的系統, 也可以是端到端測試 (End-to-end testing).
即使元件都各自運作良好, 互相整合的部分仍可能有問題, 使用者介面本身也可能有臭蟲, 因此仍然需要測試程式確保這部分的品質. 但考量前面所提到的種種因素, 這種測試程式開發及維護的成本都很高; 當維修成本過高時, 整個測試團隊可能會一直原地打轉, 不停地維護相同的程式. 因此, 建議挑一些代表性的測試項自動化就好, 不需要所有的測試都透過使用者介面執行.

中間被遺忘的一層是服務, 換句話說就是系統提供的功能.
舉例來說, 小算盤提供的服務就是加減乘除等運算.
事實上產品主要的邏輯都在這層, 使用者介面應該只是把運算結果顯示到螢幕上而已.
若開發團隊能提供一個跨過使用者介面的測試介面, 像是可以從命令列下指令, 或直接發送通訊協定給伺服器, 再從產品的紀錄去驗證執行的結果. 一樣可以測試到產品中元件整合的部分.
這類型的測試還有幾個好處:
- 跨過使用者介面測試的速度會更快.
- 不需等待使用者介面的開發完成, 早期測試. 使用者介面的開發可能會比底層服務晚, 倘若一定要等到使用者介面開發完才能開始測試, 是很沒效益的.

結論:
各類型的測試都有優缺點. 適當的比例是成功的關鍵.
使用者介面的自動化測試仍然有存在的價值, 但為了讓維護成本合理化, 選擇最重要的部分開發就好.

----------------------------------
In software testing, the most intuitive way is to operate GUI (Graphic user interface) directly, and observe if the response of interface is expected.
For example, we want to know if the calculator works correctly.
One test case should be that:
- Launch the calculator.
- Press the buttons "3+4=".
- Verify if output is "7" on the screen.

The development team wants to introduce automation test to save regression effort.
They write a program to click "3", "+", "4", and "=" buttons, and to assert if the output text is "7".
Besides addition, there are as well as subtraction, multiplication, division, and square root needed to be tested.
After developing all test programs laboriously (there are maybe hundreds or thousands of test cases). One day, the project manager says, "Well... this UI isn't cool enough. We should adjust it for marketing."

Can test programs work properly after the interface changes?
It depends. But in most cases, we need to tune test programs.
Please imagine the effort of tuning every program respectively when the case number is considerable.
What's worse, the project manager changes his mind again one month later. "Customers didn't like the modification. Let's change to another interface."

According to the scenario above, we can think about that:

1. Does User Interface Change Frequently?

    User interface changes more frequently than fundamental program logic. It may change because it isn't intuitive enough for users, because there are bugs in current design, or because the boss just doesn't like it.
    When developing the next version of the product, in order to make customers feel novel and in a visual sense, the GUI is adjusted, too.
    With limited resources, it is a pity that test automation can't be accumulated because of GUI changes.

2. Can Test Automation be Wrapped Better?
  
    Yes, it helps in certain levels of GUI changes.
    We can use keywords to abstract testing scenarios and reduce the impact of changes.
    However, abstraction is not a silver bullet. If the change is beyond the range of keywords, we still need to modify testing program respectively.

3. Since User Interface Changes aren't Avoidable, Can We Only Invest Resources in Unit or API Level Testing?

    They aren't impacted by GUI changes. Sounds great!
    Nevertheless, they can't find the bugs in GUI.
    Even though all automation tests are passed, user interface may crash immediately when it is launched.
    It is risky if GUI automation testing is given up.

Is it worth investment in GUI automation?
This kind of testing takes lots of effort, but it can't be skipped.
There is an excellent article by Mike Cohn to discuss this problem.
"The Forgotten Layer of the Test Automation Pyramid"

Test Automation Pyramid

At the base of the test automation pyramid is unit testing. Unit testing should be the foundation of a solid test automation strategy and such represents the largest of the pyramid.
The product is composed of units. Only if every unit works correctly, the product can work correctly, too. Lots of unit testing makes sure the quality of units. Once unit testing fails, because its testing scope is small and specific, trouble shooting is easy. Debugging in 10 lines is much easier than in 1000 lines.

The top is the user interface level. For systems without GUI, it means end-to-end testing.
Although every unit works as expected, there are still integration problems, and user interface itself may have bugs. It is better to have test program to cover this type of testing. As discussed above, the cost of development and maintenance is expensive, and the team goes round in circles if they are always busy maintaining existing test program. It is suggested that we implement the most important test cases by this way, but not all cases.

The layer between UI and unit is the service layer. In other words, it is the functionality the product provides. For example, the service of the calculator is mathematical operations.
Main program logic is in this layer, and user interface is just a presentation layer to display computed results. If the development team can provide testing interface bypass GUI, such as a command line, or a socket server to listen requests, and as well as provide comprehensive logs or system events for verifying the expected results, integration code can be tested with reasonable efforts.
There are some benefits of service testing, too.
- Testing speed is faster by bypassing GUI.
- Testing doesn't depend on user interface, so it is possible to test in the early stage.
  User interface is generally finished later than main program service. It is inefficient to test after everything is ready.

Conclusion:
Every type of testing has its own importance. The appropriate ratio of testing is the key to success.
GUI automation is useful to make sure the product quality. However, to reduce maintenance efforts, we just need to implement the most important test cases.

Learning from the Master - Steve Jobs

Steve Jobs, 蘋果總裁.
同時也是世界上最偉大的簡報者之一.

他最有名, 最能撼動人心的就是2005年在史丹佛畢業典禮那場演說.
"求知若飢, 虛心若愚" (Stay hungry, Stay foolish)







iPad發表會.
與其介紹新產品的規格.
觀眾們更想知道的是iPad能為他們做些什麼.
Steve從觀眾的角度出發.
他簡報的特色是大量圖片, 輔以少量文字說明.







之前讀過一本書在介紹他簡報的祕訣.
"大家來看賈伯斯, 向蘋果的表演大師學簡報"

http://www.books.com.tw/exep/prod/booksfile.php?item=0010460757


提到Steve Jobs之所以與眾不同的幾個特點:
-  在開始製作投影片之前, 先準備好你的紙與筆.
   試著用心思考, 擬定腳本, 如何將關鍵訊息傳達給觀眾.
-  減少使用文字, 視覺圖像是最有力的傳達管道.
-  不斷地練習, 練習, 練習. 力求完美.
- ...

簡報是一門藝術, 追求完美是沒有極限的, 
觀摩大師的作品能幫助我們更上一層樓.


------------------------------------------


Steve Jobs, the CEO of Apple.
He is as well as one of the greatest presenters.

The most famous and impressive presentation is Stanford commencement speech in 2005.
"Stay hungry, stay foolish"

iPad announcement.
Instead of understanding the specs of the new product,
People are more willing to know how iPad affect their lives.
Steve present from users' perspectives.
Most of the slides simply show one image.
There is very little text on his slide.





I have read a book to talk about the skills used in Steve Jobs' presentation.
"The Presentation Secrets of Steve Jobs: How to Be Insanely Great in Front of Any Audience"

http://www.amazon.com/Presentation-Secrets-Steve-Jobs-Insanely/dp/0071636080

Steve Jobs's presentation is incredible because:
- Before opening the presentation software, prepare your pen and paper first.
  Start by thinking, sketching, and scripting.
  Think about how you can deliver key messages to the audience.
- Use little text only. Visualization is the most powerful method to convince people.
- Practice, practice, and practice. Make all perfect.
- ...

Presentation is an art.
The road to seek excellence is endless.
Learning from the master can make us better and better.

Key to Successful Automation III - Quality

測試自動化是為了確保產品的品質.
但當Developer的程式碼有測試程式檢驗時, 誰來驗證測試程式本身是否有bug?
我想應該沒有人敢這樣說 "老闆, 我需要再找一批人來測試自動化測試的程式."

測試程式的品質不好會有甚麼影響? 倘若每次自動化測試的結果並不穩定, 常常有假警報或是沒有抓到真正的問題, 久而久之, 測試工程師對自動測試的報告的信心指數是不夠的. 要嘛就是花很多時間去仔細檢查報告上"可能"有問題的地方, 要嘛就是隨著產品發行日一天一天逼近, 所有測試最後還是靠手動測試來確保品質. 這樣當初測試自動化的目的-節省回歸測試的成本, 不但完全沒達到, 反浪費了許多寶貴的時間, 可說是賠了夫人又折兵.

好, 現在我們知道沒做好的後果有多嚴重了.
那要怎麼提升測試自動化的品質呢?

1. 把測試自動化當專案在開發

測試自動化應有其目標, 策略, 資源, 計畫, 設計. 要像開發專案一樣地嚴謹.
測試開發的時程應與產品配合. 目標方面則是質應重於量: 20個穩定的測試項比200個不穩定的測試項有用得多.
由於一樣是程式開發, 版本控制絕對是必需的, bug追蹤系統最好也有.
此外, 需要有方法追蹤進度, 我們每天早上都會有一個15分鐘的會議 (Daily sync-up meeting) 討論昨天完成的工作, 今天要做的事及遇到的阻礙. 還有WBS (Work breakdown structure) 來紀錄工作的完成度.

2. 程式檢視 (Code Inspection)

所謂程式檢視, 就是由一群人一起審核程式碼, 提出程式碼中有錯誤或是需要改進的地方. 每個人或多或少都有盲點, 所以藉由眾人的智慧來提升程式的品質. 

我們實際的經驗如下:  一次檢視的範圍大約是1000行的程式, 整個測試團隊都要參加 (大約四~六人, 如果人更多可以拆成Feature team), 在正式檢視的會議數天前, 這次被檢視程式的作者會向團隊大概講解一下程式的架構, 幫助大家加速檢視. 在會議前所有成員都應該確實讀完要檢視的程式碼, 並將有問題的地方記錄下來.

檢視的範圍應著重於程式的架構, 邏輯, 或者是可維護性 (Copy-paste, Hard code都應該被修正), 註解不夠的地方也可以提出來加強, 而不用拘泥於一些小錯字. 另外有一樣東西也很值得檢視, 程式中是否有時間差的問題 (Timing issue)? 測試程式有時候在等待使用者介面切換或是產品完成某件事時, 會用睡眠 (Sleep)的方式去等, 但這些時間會隨著機器規格不同而有所變化, 因此使用固定的時間等待將導致自動測試結果不穩定, 時好時壞. 比較好的作法應該用事件 (Event) 或檢查產品的紀錄 (Log) 來判斷是否一件事情已經完成.

檢視的標準可以設定在如果今天這段程式碼要交接給你維護, 你覺得能夠接受.

檢視的會議中, 會有主席及紀錄, 主席會讓與會成員提出觀察到的問題. 但主席也需要維持整個會議進行的流暢, 每個問題的討論不應超過3分鐘, 亦不討論詳細的解法, 只要大家覺得這真的是個問題就可以繼續下一項, 3分鐘討論不完的部分則可以另闢新的會議. 紀錄將所有該討論該解決的地方都記下來, 以便追蹤. 最後主席會讓大家表決, 是要找人追蹤呢? 還是如果品質過差的話, 需要再一次的檢視會議.
整個會議進行的時間不宜過長, 超過2小時與會者注意力就會開始渙散, 效率降低.

程式檢視除了提升測試程式的品質外, 還有帶來一些好處. 首先就是因為知道程式會被別人檢視, 開發中就會比較注意細節及註解, 有達到警惕的效果. 此外閱讀資深工程師的程式可以幫助新手成長, 也能夠瞭解是否有函式可以共用. 如果人事上有異動, 交接上也變得比較容易.

程式檢視會花一些時間, 但相信是值得的. 

3. 保持簡單

保持測試程式, 除錯, 閱讀測試報告簡單.

簡單可以節省例行公事的時間, 專注於更重要的事情上, 也能讓測試自動化的效果發揮到最大. 

測試程式簡單的話, 問題會比較少而且除錯簡單, 程式檢視也較容易. 單元測試 (Unit test) 就是一個很典型的例子. 一般來說, 單執行緒 (Single-thread) 的程式也會比多執行緒 (Multi-thread) 的程式容易除錯.

除錯簡單可以從幾個地方來觀察: 測試架構是否能單步除錯? 是否有收集產品除錯資訊(Debug log)?測試程式本身的除錯資訊寫得完整嗎? 是否有紀錄當時測試環境的資訊? 像是螢幕的截圖, 甚至如果有足夠的硬碟空間, 自動測試發生錯誤時可以記錄一個虛擬機器的還原點. 收集夠多的資訊, 除錯將會更容易. 

閱讀測試報告簡單是說, 當測試報告出來時, 能否能很容易地知道目前產品的品質? 對測試的結果自動產生一些分析, 能提升閱讀以及除錯的速度. 像是如果有10台測試機器, 那除了每台機器有自己的報告外, 也應該有一份完整的分析報告可以看到所有機器的狀態. 另外, 如果有些測試程式剛開發完成, 是不是能跟目前穩定的測試程式有所區隔? 之前同事有一個建議我覺得很不錯, 自動化測試的報告上可以分成"穩定/開發中" (Stable/Developing), 剛開發完的測試程式可以先標記成開發中, 閱讀上就不容易混淆.

做測試自動化應該像是經營精品, 像是PRADA.
也唯有精品化的測試程式, 才能真正確保產品的品質.

-----------------------------------------------------

The objective of test automation is to make sure the quality of the product.
However, when production code is verified by test automation, who is responsible for making sure the quality of test program itself?
I bet nobody tells his/her boss. "Hey boss, we need more test engineers to test our testing code."

What is the impact of test automation with poor quality?
If the results of test automation are not stable, there are usually false positives or false negatives; as a result, test engineers aren't confident of test automation, so they may spend lots of time double checking issues in automation reports, or they may give up test automation and test manually because of the tight project schedule.
In the end, the goal, saving regression testing effort, of test automation is not achieved, but also precious resources are not utilized efficiently. Bad automation is worse than no automation.

Well, now we understand how serious bad test automation is.
How can we improve it?

1. Treat Test Automation as a Project

For test automaton, we should define the goal, the strategy, the schedule, the design, and the resource plan. It should be as formal as product development.
Automation schedule should always align with the product. When defining the goal, quality is more important than quantity; 20 stable cases are worth than 200 unstable cases.
Test automation is code development, too. Source control system is absolutely essential, and it is better to have bug tracking system.
Besides, there should be ways to follow up the development progress. My team has a 15 minutes daily sync-up meeting every morning. We exchange the information about what we accomplished yesterday, what we plan to do today, and what obstacles we met. There is as well as a WBS (Working breakdown structure) to trace all tasks.

2. Code Inspection

Formal code inspection involves multiple participants to review code. It is intended to find and fix bugs, and improves code quality. Everyone may have a blind spot, but it can be covered by others. 

Our practice is that, the scope is 1000 lines of code per review, and whole test team (4 to 6 persons, big team can be divided into feature teams.) is involved. Before the inspection meeting, there is an introducing meeting to give an overview of inspected code by the author; it assists reviewers to read code more efficiently. Participants must review the code before the inspection meeting and take notes of the defects he/she found. 

Inspection should focus on the structure and the logic, and the maintainability (Copy-paste and hard code should be avoided.) of code; lack of comments can be highlighted, too. Typo can be noted but doesn't need to be highlighted in the meeting. A common error - timing issue in test automation should be noticed. Sometimes, while test program waits for the user interface switching or the product response, it is implemented by sleep function to wait a fixed period. However, the switching or response time varies depending on testing machine specs and environment, so test automation is unstable by waiting fixed amount of time; sometimes it works but sometime doesn't. A better way is to communicate by system events or logs created by the product. 

The criteria of inspection should be that if this code is transferred to you, you are comfortable to maintain it. 

During the inspection meeting, Moderator leads it, draws attention to each section of code. Inspectors contribute issues from their preparation logs. Issues are evaluated to determine if they are real defects, and recorder helps document them. The discussion of each issue should be less than 3 minutes. To save time, detailed solutions are not come out during the inspection meeting. In the end of meeting, Moderator lets reviewers vote to decide if this inspection can be finished, and assigns member to follow up issues; or if the code quality is not acceptable, there is another inspection meeting needed. 

Code inspection not only improves code quality, but also brings some benefits. First, people know their code will be reviewed by others, so they develop test more carefully, and may take down more comments. Second, reading code written by experienced engineers is helpful to junior engineers, and lets others know what functions can be reused. If there are personnel changes, the transfer should be easier. 

It takes time to inspect automation code, but it is worthy.

3. Keep Simple

Keep test program, debugging, and reading test reports simple. 

Keeping things simple can free precious time from regular tasks, and people can focus on more important things. It also lets automation get maximum result.

If test program is simple enough, bugs should be few and debugging is intuitive, and code inspection is efficient. Unit testing is a typical example of simple test. In general, single-thread programming debugging is much easier than multi-threads one. 

Simple debugging can be checked by some quick questions. Does test framework support tracing step by step? Does test program collect enough product debug logs? Does test program itself provide adequate logs? Is the environment and the system information recorded when error occurs? For example, taking screenshot at the moment; or taking the snapshot of the virtual machine with support of testing infrastructure. Sufficient information helps debugging and improves test program quality. 

Keeping reading test reports simple means that, when testing reports are sent out, is it easy to understand the quality of product? Auto-generated analysis of testing results can help us check them more systematically and efficiently. For instance, 10 testing machines have executed automation test, and generate their own test reports. You would not want to check the reports one by one; complete analysis of 10 reports can save your time. Another example is that, some test program is new created and is unstable now; can we distinguish it from stable one? My colleague suggested that there be labels for "stable/developing" in testing reports. We can mark new cases as "developing" and are not confused.

Test automation should like luxury goods, such as PRADA.
Only test automation with good quality can make sure the quality of the product.

Ten Simple Rules for Good Presentations

原文: http://www.scivee.tv/node/2903

Rule 1: 與觀眾對談
這裡指的不只是面對你的觀眾, 還要盡可能取得眼神上的接觸, 這能幫助你的簡報增加一定程度的親和力. 此外, 請針對你的觀眾設計簡報, 瞭解觀眾的背景及知識程度, 以及他們來參加這場演講想聽到的內容到底是甚麼? 離題的簡報只會讓人頻打瞌睡.
切題是一個好簡報的根本.

Rule 2: 化繁為簡
初學者常常犯的一個錯誤是 - 說得太多. 他們可能急於向觀眾證明自己懂很多. 但說太多的後果就是模糊了焦點, 還浪費了寶貴的Q&A時間.
好的簡報應該清楚明瞭, 並能引導觀眾去思考, 提問. 假如一場簡報中沒有被問任何問題, 那麼很有可能是觀眾根本沒聽懂, 或者是內容太過平淡了. 講太多通常也會導致講太快, 讓觀眾沒辦法吸收重點.

Rule 3: 言之有物
有時候演講者可能很熱心, 想把知道的東西都分享出來.
但請記住你的觀眾的時間跟你的時間一樣重要. 不該為了不完整的內容浪費彼此的時間.

Rule 4: 讓關鍵訊息被記住
有一個很有用的檢測方法: 在簡報後一週, 找個觀眾來問他/她是否記得當時簡報的重點.
根據經驗, 一般人大概能記住3個重點.
如果觀眾能答出簡報設定的3個重點, 恭喜你! 你的簡報非常成功.
如果答出來的重點並不符合你的設定, 那簡報的方向可能有些偏差.
如果完全想不起來的話, 那...革命尚未成功, 同志仍須努力.

Rule 5: 故事性
簡報就像是個故事. 應該有其起承轉合.
先吸引大家進入主題(起), 陳述中心思想(承), 再安排一個強而有力的結尾(合).
這也能讓關鍵訊息更容易被理解.

Rule 6: 簡報台=舞台
簡報應該要能娛樂觀眾. 但切記量力而為. 如果天生的幽默感不夠, 也不用勉強自己在台上扮小丑. 如果不擅於講奇聞軼事, 也不要像背書一樣背稿.
一個好的表演者能加深觀眾的印象, 讓關鍵訊息更容易被記住.

Rule 7: 多練習並試著計時
這對於一個新手來說尤其重要. 更重要的是, 簡報時忠於你所練習的內容. 倘若你對主題不夠熟稔, 又如何能說服台下的觀眾? 百步穿楊及老翁滴油不沾的本領都是出自不斷的練習.
隨著你簡報的歷練越多, 也將越容易得到簡報的機會. 因此不要錯過任何機會, 積極爭取每一次的演出.
重要的簡報也應該先與部分的觀眾排演過, 聽聽觀眾們的建議, 像實驗室的同學或公司的同事就是很好的預演對象, 他們有著相同背景所以能幫忙指出簡報中不足的地方.

Rule 8: 保守並有效地使用視覺效果
簡報有許多種流派, 極少數的人能夠不使用任何視覺效果卻仍能打動人心, 在大部分的情況下簡報者還是需要一些視覺輔助(圖, 表). 準備好的視覺輔助將會是另外十條基本規則.
規則7可以幫助你可以決定適量的視覺效果. 一般來說大約每分鐘有一個視覺效果是最恰當的, 準備太多很容易超時. 當然有些圖表需要講解的時間長, 有些短. 同樣地, 規則7可以幫助你取捨. 盡量避免逐字念稿, 請記住你的觀眾也識字.
視覺效果應該與簡報相輔相成, 或提供一些有力數據來支持你的論點. 切記太過與不及都不好, 讓重點簡單及清晰才是王道.

Rule9: 利用錄音及錄影檢討
沒有比實際當一次自己簡報的觀眾更有效的進步方法了. 聽及看過自己的簡報後, 可以在下一次簡報中改進未臻完美之處. 倘若發現自己有壞習慣, 也應該努力去改正.

Rule10: 適時讚美
人們喜歡被讚美. 但太多無謂的讚美會讓真正有貢獻的人被埋沒. 而且如果違反了規則7, 讚美可能會變得不適當且超時. 最佳的讚美時機應該在簡報的開始, 或是簡報中他人的貢獻很顯著之時.

最後想提醒大家的是, 即使十條規則都遵守, 也不能代表簡報一定能成功.
即使我們有萬全的準備, 臨場與觀眾的互動還是很難預測.
有時候你覺得簡報會進行得很順利, 但隨後卻感覺一團糟.
有時候你很擔心觀眾的想法, 但最後卻是非常開心.
這就是人生, 相當有趣不是嗎? 歡迎留言討論你的想法.

-------------------------------------------------------------------

The original article:http://www.scivee.tv/node/2903

Rule 1: Talk to the Audience

We do not mean face the audience, although gaining eye contact with as many people as possible when you present is important since it adds a level of intimacy and comfort to the presentation. We mean prepare presentations that address the target audience. Be sure you know who your audience is—what are their backgrounds and knowledge level of the material you are presenting and what they are hoping to get out of the presentation? Off-topic presentations are usually boring and will not endear you to the audience. Deliver what the audience wants to hear.

Rule 2: Less is More

A common mistake of inexperienced presenters is to try to say too much. They feel the need to prove themselves by proving to the audience that they know a lot. As a result, the main message is often lost, and valuable question time is usually curtailed. Your knowledge of the subject is best expressed through a clear and concise presentation that is provocative and leads to a dialog during the question-and-answer session when the audience becomes active participants. At that point, your knowledge of the material will likely become clear. If you do not get any questions, then you have not been following the other rules. Most likely, your presentation was either incomprehensible or trite. A side effect of too much material is that you talk too quickly, another ingredient of a lost message.

Rule 3: Only Talk When You Have Something to Say

Do not be overzealous about what you think you will have available to present when the time comes. Research never goes as fast as you would like. Remember the audience's time is precious and should not be abused by presentation of uninteresting preliminary material.

Rule 4: Make the Take-Home Message Persistent

A good rule of thumb would seem to be that if you ask a member of the audience a week later about your presentation, they should be able to remember three points. If these are the key points you were trying to get across, you have done a good job. If they can remember any three points, but not the key points, then your emphasis was wrong. It is obvious what it means if they cannot recall three points!

Rule 5: Be Logical

Think of the presentation as a story. There is a logical flow—a clear beginning, middle, and an end. You set the stage (beginning), you tell the story (middle), and you have a big finish (the end) where the take-home message is clearly understood.

Rule 6: Treat the Floor as a Stage

Presentations should be entertaining, but do not overdo it and do know your limits. If you are not humorous by nature, do not try and be humorous. If you are not good at telling anecdotes, do not try and tell anecdotes, and so on. A good entertainer will captivate the audience and increase the likelihood of obeying Rule 4.

Rule 7: Practice and Time Your Presentation

This is particularly important for inexperienced presenters. Even more important, when you give the presentation, stick to what you practice. It is common to deviate, and even worse to start presenting material that you know less about than the audience does. The more you practice, the less likely you will be to go off on tangents. Visual cues help here. The more presentations you give, the better you are going to get. In a scientific environment, take every opportunity to do journal club and become a teaching assistant if it allows you to present. An important talk should not be given for the first time to an audience of peers. You should have delivered it to your research collaborators who will be kinder and gentler but still point out obvious discrepancies. Laboratory group meetings are a fine forum for this.

Rule 8: Use Visuals Sparingly but Effectively

Presenters have different styles of presenting. Some can captivate the audience with no visuals (rare); others require visual cues and in addition, depending on the material, may not be able to present a particular topic well without the appropriate visuals such as graphs and charts. Preparing good visual materials will be the subject of a further Ten Simple Rules. Rule 7 will help you to define the right number of visuals for a particular presentation. A useful rule of thumb for us is if you have more than one visual for each minute you are talking, you have too many and you will run over time. Obviously some visuals are quick, others take time to get the message across; again Rule 7 will help. Avoid reading the visual unless you wish to emphasize the point explicitly, the audience can read, too! The visual should support what you are saying either for emphasis or with data to prove the verbal point. Finally, do not overload the visual. Make the points few and clear.

Rule 9: Review Audio and/or Video of Your Presentations

There is nothing more effective than listening to, or listening to and viewing, a presentation you have made. Violations of the other rules will become obvious. Seeing what is wrong is easy, correcting it the next time around is not. You will likely need to break bad habits that lead to the violation of the other rules. Work hard on breaking bad habits; it is important.

Rule 10: Provide Appropriate Acknowledgments

People love to be acknowledged for their contributions. Having many gratuitous acknowledgements degrades the people who actually contributed. If you defy Rule 7, then you will not be able to acknowledge people and organizations appropriately, as you will run out of time. It is often appropriate to acknowledge people at the beginning or at the point of their contribution so that their contributions are very clear.

As a final word of caution, we have found that even in following the Ten Simple Rules (or perhaps thinking we are following them), the outcome of a presentation is not always guaranteed. Audience–presenter dynamics are hard to predict even though the metric of depth and intensity of questions and off-line followup provide excellent indicators. Sometimes you are sure a presentation will go well, and afterward you feel it did not go well. Other times you dread what the audience will think, and you come away pleased as punch. Such is life. As always, we welcome your comments on these Ten Simple Rules by Reader Response.

Key to Successful Automation II - Tool

子曰: "工欲善其事, 必先利其器"
想把測試自動化做好, 善用工具是十分重要的.
這篇文章將介紹一些值得推薦的工具, 而且好消息是 - 它們都是免費, 跨平台.

1. STAF (Software Testing Automation Framework)
http://staf.sourceforge.net/
功能非常強大的測試工具.
STAF是一隻daemon process, 提供著各式各樣的服務, 像是電腦間的溝通, 開啟process, 處理檔案系統, 資源管理, 寄電子郵件等等...
功能十分齊全, 也很適合拿來開發自己的測試架構.
某些商業測試軟體也是以STAF為基礎開發.

STAF process可跨OS溝通

網站上有著完整的使用說明, 跨平台 (Windows, Linux, Mac), 穩定度高.
提供程式介面, 可以搭配各種程式語言使用 (Java, C, C++, Python, Perl, Tcl, Rexx).
在測試項(test case)的管理上有STAX輔助, 可以用XML的格式來撰寫測試項, 當然也能與unittest framework像是JUnit搭配使用.
個人使用迄今只有遇到一個問題, 就是在Windows日文64位元平台上會crash.
在選擇開源(open source)軟體時, 最怕的就是沒有人維護, 但STAF維護的狀況相當好, 可以從SourceForge的專案狀態看到:臭蟲不斷地被修正及釋出新版.
http://sourceforge.net/project/stats/?group_id=33142&ugn=staf&type=&mode=year

由於STAF是提供服務, 所以在使用上需要寫一些程式來整合所有的服務.
以下是一段Python的sample code

from PySTAF import *
import sys
try:
# Initialize一個STAF的handle
    handle = STAFHandle("MyTest")
except STAFException, e:
    print "Error registering with STAF, RC: %d" % e.rc
    sys.exit(e.rc)
# 利用STAF的PING service測試STAF這支process是否存在
result = handle.submit("local", "ping", "ping")
if (result.rc != 0):
    print "Error submitting request, RC: %d, Result: %s" % (result.rc, result.result)
# 利用STAF的VAR service得到電腦的作業系統資訊
result = handle.submit("local", "var", "resolve {STAF/Config/OS/Name}")
if (result.rc != 0):
    print "Error submitting request, RC: %d, Result: %s" % (result.rc, result.result)
else:
    print "OS Name: %s" % result.result
# Uninitialize STAF的handle
rc = handle.unregister()
sys.exit(rc)



2. Selenium
http://seleniumhq.org/
網頁測試工具.
在開始介紹它之前, 先提供一個數據給大家參考.
從Elisabeth Hendrickson的文章"Do Testers Have to Write Code?"中.
業界徵才-測試自動化的需求中, Selenium排名高居第一, 相信大家就能瞭解這個工具有多紅.
Selenium提供了網頁測試所需的各種功能. 打開瀏覽器, 輸入文字, 點擊按鈕, 檢查文字等..
跨平台, 跨瀏覽器, 支援各種程式語言 (一覽), 提供完整的使用說明讓Selenium一炮而紅.
最貼心的是, Selenium還提供Firefox的外掛可將使用者的操作錄成程式碼, 降低了開發的門檻.

以下是官網上的Python的sample code, 結合Python的unittest.
用起來相當直覺.

from selenium import selenium
# This is the driver's import.  You'll use this class for instantiating a
# browser and making it do what you need.

import unittest, time, re
# This are the basic imports added by Selenium-IDE by default.
# You can remove the modules if they are not used in your script.

class NewTest(unittest.TestCase):
# We create our unittest test case

    def setUp(self):
        self.verificationErrors = []
        # This is an empty array where we will store any verification errors
        # we find in our tests

        self.selenium = selenium("localhost", 4444, "*firefox",
                "http://www.google.com/")
        self.selenium.start()
        # We instantiate and start the browser

    def test_new(self):
        # This is the test code.  Here you should put the actions you need
        # the browser to do during your test.

        sel = self.selenium
        # We assign the browser to the variable "sel" (just to save us from
        # typing "self.selenium" each time we want to call the browser).

        sel.open("/")
        sel.type("q", "selenium rc")
        sel.click("btnG")
        sel.wait_for_page_to_load("30000")
        self.failUnless(sel.is_text_present("Results * for selenium rc"))
        # These are the real test steps

    def tearDown(self):
        self.selenium.stop()
        # we close the browser (I'd recommend you to comment this line while
        # you are creating and debugging your tests)

        self.assertEqual([], self.verificationErrors)
        # And make the test fail if we found that any verification errors
        # were found

其它像是AutoIt(Windows使用者介面自動化), Watir(網頁測試工具, Ruby專用)也都是很常見的工具.
善用這些工具, 站在巨人的肩膀上讓我們能夠走得更遠, 更穩.

-----------------------------------------------------------------------------------
"To do a good job, one must first sharpen one's tools." Chinese philosopher Confucius said.
Good tools are prerequisite to the successful execution of test automation.
This article will discuss about some useful tools, and the good news is, they are all free and cross platform.

1. STAF (Software Testing Automation Framework)

http://staf.sourceforge.net/

STAF is a very powerful testing tool with a variety of functions.

It is a daemon process as a service provider; and it can handle communications between computers, launch process, provide file system utility, manage resource, and send email, etc.

STAF provides basic testing framework utility and can be used to develop advanced testing framework. Some commercial tools are based on STAF, too.

STAF process can communicate between different platforms

In STAF official website, a comprehensive manual can help you adopt it.
STAF is cross platform (Windows, Linux, Mac), and is very stable.
Besides, STAF provides programming interface with Java, C, C++, Python, Perl, Tcl, Rexx, etc, so you can integrate it with your familiar programming language.
About test suite management, STAX supports XML style test case description, or you can choose unittest framework like JUnit to manage test suites.
There is only one problem when I used STAF so far: It crashes on the Windows Japanese X64 platform because of some special double-byte characters.
Maintenance problem should be considered when choosing open source tool. Fortunately, from the statistics of source forge, STAF project status is excellent, bug is fixed and minor version is released frequently.
http://sourceforge.net/project/stats/?group_id=33142&ugn=staf&type=&mode=year

STAF provides services, so team 

Below is sample code in Python.

from PySTAF import *
import sys

try: 

# Initialize a STAF handle
    handle = STAFHandle("MyTest")
except STAFException, e:
    print "Error registering with STAF, RC: %d" % e.rc
    sys.exit(e.rc)

# Use STAF's PING service to test if STAF process exists

result = handle.submit("local", "ping", "ping")

if (result.rc != 0):
    print "Error submitting request, RC: %d, Result: %s" % (result.rc, result.result)

# Use STAF's VAR service to get OS information

result = handle.submit("local", "var", "resolve {STAF/Config/OS/Name}")

if (result.rc != 0):
    print "Error submitting request, RC: %d, Result: %s" % (result.rc, result.result)
else:
    print "OS Name: %s" % result.result

# Uninitialize the STAF handle

rc = handle.unregister()

sys.exit(rc)

2. Selenium

http://seleniumhq.org/

A web application testing tool.

Before introducing it, I would like to show you how "Hot" it is now.
From the article of Elisabeth Hendrickson "Do Testers Have to Write Code?", the top automaton technology required for software testers is Selenium.
Selenium provides common utilities for web testing, ex, launching browser, inputting text, clicking button, and asserting text...
It can also support cross platforms, cross browser, cross programming language, and of course, provide a comprehensive user guide.
Besides, the most amazing is that Selenium has Firefox plug-in to record user actions into test scripts, it can eliminate the barriers of adoption dramatically.


Below is the Python sample code from Selenium official website, combined with Python unittest.
The use is very intuitive.

from selenium import selenium
# This is the driver's import.  You'll use this class for instantiating a
# browser and making it do what you need.

import unittest, time, re
# This are the basic imports added by Selenium-IDE by default.
# You can remove the modules if they are not used in your script.

class NewTest(unittest.TestCase):
# We create our unittest test case

    def setUp(self):
        self.verificationErrors = []
        # This is an empty array where we will store any verification errors
        # we find in our tests

        self.selenium = selenium("localhost", 4444, "*firefox",
                "http://www.google.com/")
        self.selenium.start()
        # We instantiate and start the browser

    def test_new(self):
        # This is the test code.  Here you should put the actions you need
        # the browser to do during your test.

        sel = self.selenium
        # We assign the browser to the variable "sel" (just to save us from
        # typing "self.selenium" each time we want to call the browser).

        sel.open("/")
        sel.type("q", "selenium rc")
        sel.click("btnG")
        sel.wait_for_page_to_load("30000")
        self.failUnless(sel.is_text_present("Results * for selenium rc"))
        # These are the real test steps

    def tearDown(self):
        self.selenium.stop()
        # we close the browser (I'd recommend you to comment this line while
        # you are creating and debugging your tests)

        self.assertEqual([], self.verificationErrors)
        # And make the test fail if we found that any verification errors
        # were found

There are some excellent tools as well. For example, AutoIt is a tool for Windows GUI automation, and Watir is a web application testing tool for Ruby.
By leveraging these tools and standing on the shoulders of giants, we are able to go further.

Life after Death by PowerPoint

我最愛的影片之一.

Don McMillan 告訴你千萬別這樣做投影片.

One of my favorite videos.

Don McMillan shows examples of how NOT to do Powerpoint.