黑暗未來

像流水線一樣測試

         在黑暗未來，ISO標準29119會告訴我們需要測試什么以及如何測試。“無論你做的是哪種類型的測試，它都會影響你。”即使起草標準的人不知道你的業(yè)務也沒關系嘛；因為他們是“專家”，他們知道什么方式是好的方式，比你更知道。“標準使用了四層過程模型，開始有兩個層覆蓋測試策略和測試戰(zhàn)略。下一層轉向項目管理，后一層為所有測試級別定義了基礎測試過程，比如單元測試，系統(tǒng)測試，驗收測試，以及測試類型（例如性能和可用性測試）。第2和3部分，與過程和文檔相關，特別與測試過程潛在的所有輸出緊密關聯(lián)，相當于文檔部分定義的文檔。同時建議使用‘新工作項目’，這個將在測試過程改進中看到第五部分內容-假設一個測試產業(yè)每隔數(shù)十年沒有出現(xiàn)其他新的測試改進模型。”是不是聽起來很不錯？他們不僅僅告訴你如何去做，還包括如何改進-而不顧廣為人知的警告，“可能大的抱怨來源于IT標準不能滿足實際從業(yè)者的需求-我們中的很多人都會遇到這種‘空文’”。也不要擔心標準難以管理，當前標準的第2部分草稿，是在編寫的這部分，“僅”100頁。

         注意和標準相關的還有標準的術語表。術語表用英語。將它翻譯成其他語言會增加復雜度和模糊性。讓我們所有人僅僅用英語測試吧。如果其他文化不喜歡。。。好吧，有點困難。反正也沒多少從他們那需要學習的東西。      

黑暗未來

推進正統(tǒng)教育

Ÿ   所有測試人員必須通過多個容易通過的考試的認證

Ÿ   反正測試不是真正需要專業(yè)技能

Ÿ   每個測試產業(yè)的從業(yè)者使用同樣的語言，并且按同樣的標準測

         在黑暗未來，評估測試人員的能力是基于記憶權威知識體系中測試術語的能力。上下文環(huán)境和理解說明在黑暗未來沒有容身之處。考試總是需要的，這樣便于考認證，所以有多個認證的選擇也是必須的。如果擔心這種方法不足以評估技能，不用擔心：測試反正不是一個特別需要經驗的行業(yè)。一些測試人員能夠編寫代碼讓工作自動化，這個是一個好主意，因為無論從什么角度看測試總是一個枯燥、重復以及單調的任務。

    我們不希望測試人員和開發(fā)人員（即程序員-程序員僅僅指黑暗未來里的開發(fā)人員）親近。測試人員會意志薄弱以至于受到程序員負面的影響，所以這種親近會危害測試人員的目標。測試人員可能會被誘導不要報bug。

    重復在黑暗未來中是非常重要的。我們想要一遍又一遍的跑同樣的測試，沒有變化，因為變化可能導致不可預測性。發(fā)現(xiàn)和研究bug會讓我們脫離原定計劃

黑暗未來

測試和學習無關

Ÿ   測試關注證實、驗證和確認

Ÿ   測試人員檢查確認規(guī)定的測試通過

Ÿ   探索和研究，往好處說是品，往壞處說是危險

         在黑暗未來，測試是持續(xù)不斷的例行任務，機械化的活動，即使它們是由人完成的。它和學習無關，和確認我們已知的事情有關，回答我們知道答案的問題，重復一遍又一遍同樣的無腦測試。在黑暗未來，沒有探索、研究或發(fā)現(xiàn)、學習的地方，也是沒有技能、創(chuàng)造性和想象力生長的舞臺。也沒有詢問客戶如何評估我們產品的空間。我們只是做我們被告知的，我們不學習任何東西。    

黑暗未來

測試被簡化為無腦的檢查

“有腦”意味著“需要人類智慧”

一個“無腦”的活動可以：

被不能思考的機器執(zhí)行（但是迅速并且精確）；或者被封閉思考的人類來執(zhí)行（慢并且不可靠）

黑暗未來

測試人員負責制

項目管理不夠成熟，不能做出合適的決定
 
         在黑暗未來，測試人員是質量的看門人。我們決定何時開始測試，僅僅當產品和相關文檔按嚴格標準提供時，以及當我們收到完整的、無歧義的、新的需求文檔時，我們開始測試。我們決定產品質量是否達到發(fā)布的要求。管理者必須得到我們的簽名和我們的允許，才能發(fā)布一個合格的產品。我們能夠中止發(fā)布，如果我們認為產品不夠好。當然我們自己不需要遵守這些標準，那不是我們的工作。在黑暗未來，我們的角色是告訴其他人他們什么做錯了以及如何改正。在黑暗未來，測試人員是真正的項目管理者。

黑暗未來

測試人員負責制

測試人員不能控制日程、預算、產品 、團隊、合約等等，但是我們仍然對質量負責。

黑暗未來

測量

Ÿ   我們測量

Ÿ   需求范圍，通過統(tǒng)計需求文檔數(shù)

Ÿ   測試覆蓋率，通過統(tǒng)計測試用例數(shù)

Ÿ   產品質量，通過統(tǒng)計bug數(shù)

Ÿ   測試人員價值，通過統(tǒng)計bug報告的數(shù)量

Ÿ   程序員的產出，通過統(tǒng)計代碼行數(shù)

Ÿ   復雜度，通過統(tǒng)計代碼分支數(shù)

Ÿ   屬性各個值之間的相關性不重要

Ÿ   如此簡單，小孩子也能做
 
         需求文檔、生產率、復雜度、測試覆蓋率、產品質量以及測試人員價值與我們看到的成百上千的因素有關。然而大部分因素并不能明確的量化，過分簡化的統(tǒng)計只能是誤入歧途。在黑暗未來，我們解決問題的辦法是忽略他們。

         一個bug并不是這個世界上的普通的一件事情。一個bug是結構化、充分思考的精神產物。它是特定人和特定產品之間的關系，比如其他的人可能不會把它視之為bug。甚至當兩個或更多人認為部分行為似乎一個bug時。他們也可能不同意這是個明顯的bug。盡管如此，在黑暗未來，我們會統(tǒng)計它們。越多的bug意味著越高的質量；越少的bug意味著越低的質量。這對測試人員同樣適用。我們會忽略所有測試人員帶給項目的其他活動和維度的價值，通過統(tǒng)計他們bug報告的數(shù)量來測量他們的工作效率。

         在黑暗未來，我們不會做定性的測量、做第一手的觀察、看測試人員和開發(fā)人員的交流，或者和實際用戶進行溝通。我們不相信故事，只相信統(tǒng)計。然而我們不會擔心測量方法中的合理性或其他可能的問題。我們只是簡單的使用方法，比如應該對每個需求文檔有一個可追溯的測試用例。不，等等！應該是兩個！一個正向測試用例和一個負向測試用例。

         Cem Kaner說過一個測試用例是我們想要問這個產品的一個問題。James Bach也多次說過，一個測試用例是一個問題的容器。在黑暗未來，我們評估工作質量，是坐在辦公室里，統(tǒng)計每天早上進進出出的公文數(shù)量。我們不去考慮看一下其中的內容。如果公文的數(shù)量越多，那顯而易見的表示公司的工作效率在提升。

         我們忽略簡單統(tǒng)計背后隱藏的問題，回避Cem Kaner和Pat Bond所著的Software Engineering Metrics:What Do They Measure and How Do We Know?(http://www.kaner.com/pdfs/metrics2004.pdf); Darrell Huff 經典的How To Lie With Statistics; Gerald M. Weinberg所著的Quality Software Management， Vol. 2: First Order Metrics ; 尤其是Robert D. Austin所著的Measuring and Managing Performance in Organizations。愛因斯坦曾經說過“不是所有有價值的都能被計算，不是所有能計算的都有價值”。我們當然也忽略了他。

糟糕的事情是黑暗未來

                                                           和很像           
 
         在黑暗未來，在項目管理比較便于測試人員操作時，他們會在幕后驅動整個項目。即使測試人員明顯沒有什么權力，他們仍然對所有質量過失負責。因為他們是代碼后的經手人，于是看上去任何沒有被檢測到的問題都是他們的過失。測試人員必須簽署文檔來決定產品是否可以發(fā)布，即使產品的發(fā)布是一個商業(yè)層面的決定，而不是技術層面的。