QBQ！問題背後的問題 - 重點節錄

QBQ實踐原則：
個人責任不是通過改變他人，而是通過改變自己力求解決問題
個人責任不是抱怨團隊，而是要充分認識個人的力量
個人責任就是要適應變化，不斷完善自我
個人責任就是要利用現有的資源與工具實現目標
個人責任就是要做出具有積極作用的選擇
個人責任就是要不斷自問"我還能做些時麼？"

QBQ的精隨：藉由提出更好的問題，立刻做出更好的選擇。

個人責任感的不同，造就了個人事業的差異。
請做更好的選擇吧！

QBQ指導原則：答案就在問題之中

QBQ三項簡單指導原則：
1.以"什麼"或"該如何"這兩個詞來發問，而不是用"為什麼"、"什麼時候"或"誰"。
2.在所有問題中包含"我"字在內，而不是只包含："他"、"他們"、"我們"、"你"或"你們"。
3.把問題的中心詞放在動詞上面，也就是放在行動上。
EX.我能做什麼？

如果你想贏，就要擊敗三個人：你的對手、你自己以及裁判。

"個人負責的精神"可以改變世界的方法就是：每次都做出一個最好的選擇。

承諾用自己的智力、心力和勞力解決問題，而且絕不再爭功諉過。

團隊精神的基石就是：欣賞團隊中每個人與生俱來的天賦與優點。

在工作中要麼選擇言行一致；要麼選擇辭職離開！

個人責任的重點不是期盼他人首先改變，或是改變他人，而是首先改變自己，進而改變現況。

QBQ祈禱文：
願上帝賜我平靜，接手我無法改變的人。
願上帝賜我勇氣，改變我能改變的人。
願上帝賜我智慧，了解我自己這個人。

實踐個人責任的方法：
1.提煉自己的想法
2.問比較好的問題
3.最後付諸行動

領導(Leader)就是那些時時刻刻都在提煉自己的想法，以承擔個人責任為己任，不斷做出具有積極意義的選擇並付諸行動的人。

QBQ的內涵是"個人責任"：
別再有"小媳婦"的心態，別再拖延、推諉或怪東怪西。
我只能改變我自己。
立刻就去執行！行動高於一切！

時光旅人~~

花費了這個周末，我看完了一本小說式的自傳：時光旅人

主要是在描寫一個物理學家故事

他如何在小時候因為父親的驟逝

走入了人生的低潮及憂鬱的胡同之中

直到他接觸到了一本小說

威爾斯的｢時光機器｣

一個夢想 從他的心中油然而生

打造出時光機器  回到過去再見到他的父親一面

於是  他開始了他的科學人生

雖然結尾時他還沒有打造出真正的時光機器

且他那基於愛因斯坦相對論的理論

在一位知名教授的點醒下 發現了一個很大的問題

根據他的理論所打造出來的時光機器

最遠只能回到時光機器打造出來的那個時間點

即便如此他還是沒有放棄他的夢想

如今他已值花甲之年

但他應該還會繼續努力下去 朝著他的夢想前進

就讓我們繼續看下去吧~~

挪威的森林~~

今天我終於把挪威的森林看完了

會想看這本書的動機是因為

之前看過一本書 那年我心中最每個旋律

書中常常提到這本書 而且這本書也是 小橘 的遺物之一

我想過幾天我應該會再重看一遍 那年我心中最每個旋律

就我目前能觸及的記憶 是

兩本書中都有一個女生 不知是

對未來 對現實生活 還是...  沒有辦法適應

於是都選擇了 結束自己的生命

不同的地方是

小橘 在臨死前 演奏了讓人永生難忘的 雙簧管 演奏

她的自創曲 弱水三千

而

直子 則是在上吊前 帶著微笑過了一個

在Kizuki選擇離開人世後 最輕鬆的一天吧(我猜)

兩個人都有低調且冷清的葬禮 可能都是因為是自殺吧

就在前幾個小時 我邊看來邊認為會有 不錯的結局

結果就再倒數的幾章 劇情急轉直下 直子 自殺了

男主角 渡邊君 經歷了兩次身邊人(摯友及愛人)的離世

都有了不同的領悟

死不是生的極反，死只是生的延伸

死去的人 總會帶走自己身上的某些東西

寫到這邊總覺得一整個很灰暗

至於好不好看 感覺是見仁見智

但蠻多地方值得去深思的

寫到這覺得怎麼一整個很灰暗的感覺

說點其他的吧

像是男主角的一個朋友永澤兄

離去前給了他一個禮物：不要同情自己，同情自己是下等人幹的事

還有書中有一個蠻常出現的口頭禪：要命

另外，這本小說關於色色的畫面描寫相較於一般的小說好像稍多了點

最遙遠的銀河~~

應該有好幾個月了吧，沒有動手寫任何一篇文章
雖然這幾個月有讀了幾本書，不過都很懶得動手寫
因為很怕自己一寫就半個鐘頭一個小時過去了
直到今天花了一個晚上，看完了｢最遙遠的銀河｣有點想寫個心得
不過還是有點懶，好不容易洗個澡然後強迫自己動手寫下
這個由小說改編成前後兩篇的電影(應該算電影吧)

整個劇中讓我最有共鳴的是晴的人生吧
不過這個共鳴不是來自於自己，而是之前看過的一本東野圭吾的小說｢真夏方程式｣
劇中跟晴有關係的人死了四個：

一個深愛他且奉獻自己的愛人
一個最好的摯友和最好的敵手
一個殘害及殺死他所深愛的人
一個肯為他獻身的最好的朋友

除了一個是晴殺死的，剩下的都是把自己的人生託付給晴的人
然而，在最後晴卻覺得自己沒有資格活下來給其他人帶來幸福
選擇的焚船(幸成丸)自戕 (幸成:根據渡警官的解釋，他覺得是給活著的人幸福的意思)
看到這讓我想到真夏方程式中的兩個人，他們也是背負的人命的人
他們卻勇敢的面對，努力得繼續生活下去
雖然他們負擔的沉重及面對的壓力是不同的
但，我總覺得晴辜負了所有相信他的人
當然這是以我這個完全局外人來看，若角色互換的話可能又不一樣了

劇中還有一首詩，我覺得還蠻值得玩味的

===遙遠的銀河===
光，初生的早晨
光，統治的午後
光，沉睡的黑夜
光若不閃耀
只能被夜晚的黑暗吞沒
轉瞬即逝的光帶著永遠的光輝
沉睡在遙遠的銀河

過去一年看過哪些書呢？

今天一月一號，沒什麼事，整理了一下過去一年看過的書有哪些。希望明年可以再接再厲，但是是多看點技術專業類的書籍，不然亂七八糟的小說實在是看太多了~~

最後期限：專案管理101個成功法則
雪中足跡
加護病房裡的選擇題
數學少女
真夏方程式
遺憾，擱淺了未滿的愛情
神秘島
流浪鼠之歌
諾亞的魔幻旅程
推理要在晚餐後
漫畫-微積分
漫畫-宇宙
輕鬆Scrum之旅(電子書)
迴旋宇宙(電子書)
時間旅行－來自未來的客人(電子書)
鬼太郎之妻
陰陽師-瀧夜叉姬(上)(下)
國姓爺的寶藏
在自己房間裡的旅行
星塵
從謊言開始的旅程
末日之旅
贏在測試：軟體測試專家之道
不只是旅行－邂逅世界81位女性
我的成功可以複製(電子書)
活著
投資銀行青春白皮書
胡立陽出人頭地100招
聽風在唱歌
最好的時光
那年我心中最美的旋律
日光旋律(重讀)
異鄉人(亦舒)<= 抓錯本，不過還是看完了
異鄉人(卡繆)
蒼蠅王(電子書)
大道至簡－軟體工程實踐者的思想(初版電子書)
天方夜譚
境遇(+藍天緞帶繪本)
張忠謀自傳(上)
大山背的野孩子
軟體測試實戰：測試Web MSN(電子書)

大道至簡 - 軟體工程實踐者的思想 內容整理

客戶不會用C，難道就會用UML嗎？客戶是因為他認為你理解了他們的需求，而在｢需求確認書｣上簽字，而不是因為你的UML畫的是否精確。

需求階段：

1. 確定了專案的實際目標，以及遠期的方向

2. 設計需求條目

我們開始在網路上查看相關的軟體系統的特徵以抽取客戶所關注的內容；瞭解該客戶的公司、經營理念、組織結構形式以及工作模式；瞭解同類公司的成功經驗和優秀的管理模式，以及客戶的競爭對手在做什麼和在關心什麼。經過上述的步驟，可以總結出產生需求的資訊點為：

1. 客戶在公司層面的外在表現、內部機制和運營管理手段。

2. 客戶在專案中既已明確的需求和可能發生的需求，以及客戶圍繞其公司行為(和方向)所提出的需求。

專案的歷史資料：

History是為整個專案而記錄的。一些參考的記錄內容有：

l需求階段：與誰聯繫，聯繫方式、過程、結果以及由此引發的需求或變更；

l設計階段：如何進行設計、最初的構架、各個階段的框架變化、因需求變更導致專案結構上的變化(有助於瞭解構架的可擴充性)；

l開發階段：每一種技術選型的過程、每一種開發技巧的細節和相關文檔、摘引的每一段代碼、演算法、開發包、元件庫的出處和評測；程式單元的測試框架；每一個設計和構架變更所導致的影響；

l測試階段：還記得測試用例和測試報告嗎？那是最好的history之一。

另一件最重要的事，是記得在每一筆記錄後寫下時間和你的名字。

由於軟體工程的興起，工程被當成了藉口，掩蓋了我們做事的真正目的：“實現”。因此，我們在一個項目中常常聽到說“工程要這樣做”，或者“工程要那樣做”，而絕少聽到“專案要求這樣做”或者“客戶的本意是那樣的”。

從成本的角度思考專案：

1. 不計成本的專案計畫不會得到經營者的支持；

2. 毫無目的地消耗成本是項目中的慢性毒藥；

3. 最致命的風險是成本的枯竭

成本因素包括：時間、人力、資金和客戶成本（客戶的數量及耐心）。

語言只是工具：

方法：是對既有行為的歸納總結。

過程(Process)：過程伴生工程而出現。過程解決的是工程中角色間的關系問題。

工程：

組織：

軟體工程理論體系：

軟體工程三要素：流程(process)、方法(methods)和工具(tools)

軟體測試實踐：測試web MSN - 內容整理

測試用例是軟體測試的最小單位，是測試工程師的子彈。對軟體測試入門者來說，測試用例是第一位的，有了好的測試用例你就能發現別人沒有發現的bug。只有當你具有良好的、開放型的測試思維，你才能得到優秀的測試用例。

1. 我們要熟悉產品的需求規格說明書(軟件需求是測試的標準與範圍)。若需求不具體或者需求文檔過於簡略，這時測試應該去推動需求的制定。

a. 測試以需求規格說明書為基礎，但同時也要去發現它裡面的錯誤，推動需求的完善。

b. 測試工作是貫穿於整個軟體開發過程的，越早發現錯誤，修正這個錯誤的成本就越小。

2. 測試工程師要瞭解專案的整體安排(即專案的時程)

a. 測試是無窮盡的vs.實際測試是有限的 <= 測試的經濟面(時間、成本等限制)

3.預備好測試環境

a. 工作環境與測試環境要分開

b. 功能測試環境和性能測試環境要分開

c. 提前準備好硬體(伺服器、客戶端、網路設備)和軟體(作業系統、瀏覽器)

d. 測試支援平台也是測試環境的一部分。測試支援平台：一套測試的自動化辦功系統，例如測試用例管理系統、bug管理系統、測試報告產生系統等。

e. 把搭建測試環境時遇到的問題和相應的解決辦法記錄下來，形成文字，以備之後查詢。

<<測試常用專有名詞>>

黑盒測試：只知道功能的測試。 <= 功能測試

白盒測試：只知道程式碼結構的測試。 <= 單元測試

灰盒測試：知道功能也知道程式碼結構。 <= 執行某個功能中所有的單元測試??

功能測試：對產品的功能做測試。

性能測試：一般是檢驗在普通場景下產品的性能。

壓力測試：檢驗產品在極端條件下的性能(極端條件下的性能測試)。

回歸測試：

1. 在開發人員修復一個bug後，去驗證這個修改是否正確所做的測試。

2. 在軟體開發後期，選擇否依部分重要的測試用例去驗證產品的某一個版本工作是否正常。

單元測試：函數級別的測試，一般都由開發人員來完成。

整合測試：將各模組代碼整合到一起，實現一個或一些功能。驗證代碼的整合是否正確。

系統測試：針對子系統做測試，也就是大一點的整合測試。

邊界值：是確定合法輸入與非法輸入的判斷條件(通常會在邊界值的左右在各選一個值來測試，也就是每一個邊界值得測試會有邊界左值、邊界值、邊界右值，三種值)。

等價類：將涵意或影響相似的值分在同一類中，並為每一個類選一個代表即可。例如，在0~100中，如果以偶數奇數來分類的話，就是兩類，各選一個奇數和偶數來測試就可以了。

里程碑：軟體專案一般可分為多個階段，每做完一個階段，我們就說實現了或達到一個里程碑。

評審(Review)：

bug重現(再現)：不能重現的bug，它的嚴重性一般都不會很高。

BVT(Build Verification Testing)測試：在一個新版本出來後，先要做一個最簡單的測試，保證這個版本的基本功能工作正常。亦稱冒煙(煙霧)測試。

自動化測試：透過測試工具來實現自動運行的測試。

UI測試的關注點：

1.      界面元素要符合通用規範

2.      窗口能在不同的尺寸下顯示正常

3.      支持用戶不同的作業系統的設置

4.      支持用戶使用不同的解析度

5.      處理好焦點問題

6.      作語法檢查，避免文字錯誤

7.      對不方便人群的支持

8.      支持快捷建

測試計劃的關注點：

1.      測試時間的安排

2.      測試人員的安排及任務分配

3.      測試資源的安排，包括需要的軟體、硬體

4.      自動化測試的安排

5.      測試風險的分析以及對策

                                                                                                          

<<設計測試用例的一些思維>>

1. 一個測試用例只負責一個細小的使用場景，越細越好。

2. 軟體的基本數據也在測試範圍之內。

3. 檢查默認值是一種很好的測試思想和習慣。

4. 使用"排列組合"的方式編寫測試用例(測試是無窮盡的vs.實際測試是有限的)。

5. 輸入框為空是一種特殊值。

6. 做軟體測試時，總有一些"附屬項"需要驗證。

7. 測試用例要有覆蓋到極限值(邊界值測試)的情況。

8. 登入驗證在安全性方面要多多考慮。

9. 懷疑一切，驗證一切。

10. 網頁得標題欄也是需要測試的。

11. 考慮一個測試點時，需更多的從動態的角度出發。

12. 快捷鍵的驗證。

13. 下拉式表單的每一個子項都要測試。

14. 即便功能類似，用例還是要分開寫。

15. 幫助文件的內容也是需要測試的。

16. 在測試一項複雜的功能時，可嘗試使用Bottom-Up的測試邏輯。

17. 不要忽視功能點，他們也需要被測試。

18. 所有不正確的需求、設計和程序錯誤都可以報告為bug，讓相關人員去修正。

19. 測試員的眼界要越過被測試的對象，可以考慮與之相互通信的”兄弟軟體”之間的協作。

20. 工具攔中的每項設置都需要遍歷；設置之間的組合可以隨機來做，不必遍歷。

21. 測試人員應站在最終用戶的角度上看問題(UX)。例如，輸入框得到默認的輸入焦點；快捷鍵等。

22. 在每一個軟體的需求之外，還存在著一些”公理”，不言自明的。需求規格書不可能面面俱到，測試員可以根據這些”公理”來擴展需求。

23. 不以機率小而不為。

24. 有些功能可能是界面上沒有入口、看似沒有的，但是在某些條件下卻會出現。

25. 盡量對可能交互或產生影響的產品都有所了解，這樣在考慮問題的時候思路會更開闊。

26. 再考慮複雜場景前，可先以基本場景為切入點，接著列一些提綱，然後再根據一個個的提綱去思考、去突破。

27. 數據不是靜止的，我們需要使用動態的思維方式來考慮問題。

28. 瞭解同事的工作，就能夠做一些跨模組的思考，把測試做得更深入。並避免報告重複的bug。

29. 面對一個窗口的時候，從”變量”入手做測試是一個好的思路。既然它是變量，變成什麼就都有可能。

30. 除了琢磨模組自身內部包含的功能外，我們還要把它和其他相關模組放在一起測試。

31. 有效數據和無效數據都是需要驗證的(有時候他們被稱為合法的和非合法的數據)，測試中需要正反兩方面的用例。

32. 拆解功能的流程，然後逐一分析測試，用以避免遺漏掉很多問題。

33. 狹義上的UI測試：專指對操作介面的非功能性的測試。

34. 文檔保持更新，測試保持更新，保持一種在動態前進的心理預期。任何文檔不可能是一勞永逸的。