軟件測試的兩種未來

黑暗未來

像流水線一樣測試

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

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

黑暗未來

推進(jìn)正統(tǒng)教育

Ÿ   所有測試人員必須通過多個容易通過的考試的認(rèn)證

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

Ÿ   每個測試產(chǎn)業(yè)的從業(yè)者使用同樣的語言，并且按同樣的標(biāo)準(zhǔn)測

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

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

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

黑暗未來

測試和學(xué)習(xí)無關(guān)

Ÿ   測試關(guān)注證實、驗證和確認(rèn)

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

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

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

黑暗未來

測試被簡化為無腦的檢查

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

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

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

黑暗未來

測試人員負(fù)責(zé)制

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

黑暗未來

測試人員負(fù)責(zé)制

測試人員不能控制日程、預(yù)算、產(chǎn)品 、團(tuán)隊、合約等等，但是我們?nèi)匀粚|(zhì)量負(fù)責(zé)。

黑暗未來

測量

Ÿ   我們測量

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

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

Ÿ   產(chǎn)品質(zhì)量，通過統(tǒng)計bug數(shù)

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

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

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

Ÿ   屬性各個值之間的相關(guān)性不重要

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

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

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

         Cem Kaner說過一個測試用例是我們想要問這個產(chǎn)品的一個問題。James Bach也多次說過，一個測試用例是一個問題的容器。在黑暗未來，我們評估工作質(zhì)量，是坐在辦公室里，統(tǒng)計每天早上進(jìn)進(jìn)出出的公文數(shù)量。我們不去考慮看一下其中的內(nèi)容。如果公文的數(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 經(jīng)典的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。愛因斯坦曾經(jīng)說過“不是所有有價值的都能被計算，不是所有能計算的都有價值”。我們當(dāng)然也忽略了他。

糟糕的事情是黑暗未來

                                                           和很像           
 
         在黑暗未來，在項目管理比較便于測試人員操作時，他們會在幕后驅(qū)動整個項目。即使測試人員明顯沒有什么權(quán)力，他們?nèi)匀粚λ匈|(zhì)量過失負(fù)責(zé)。因為他們是代碼后的經(jīng)手人，于是看上去任何沒有被檢測到的問題都是他們的過失。測試人員必須簽署文檔來決定產(chǎn)品是否可以發(fā)布，即使產(chǎn)品的發(fā)布是一個商業(yè)層面的決定，而不是技術(shù)層面的。