軟件測試的兩種未來(2)

　　一條需求不是文檔里的一行字或一個段落;那些東西只是表述方式-文字的表示方式-某人有什么和某人想要什么之間是有區別的。用統計需求文檔數量的方式統計需求會忽略掉需求背后的一切含義，就如同把三輪車和航天飛機放在一起統計一樣。
　　人們會說有測量總比沒有好。那就像說安樂死比沒有被槍斃要好。
　　政治性和感性決策比較強的領域，做一個決策總是基于誰的價值更相關，以及他們的感受如何。測量的目的不在于提供答案，而是提供更好的建議。
　　我們如何測量
　　Ÿ 一階測量
　　Ÿ 減少瑣事，直接觀察，減少測量
　　Ÿ 應習慣于觸發控制行為或者提示搜索更多提煉的信息
　　Ÿ “發生了什么?我們應該做什么?我們在哪里觀察”
　　Weinberg建議，在軟件開發中，我們往往執迷于三階以及二階測量，其實一階測量可能已經滿足我們全部的需要-并且無論從各個方面來說都要成本低廉
　　為什么傾向于一階測量?
　　Ÿ 當你在開車時，你大部分精力花在
　　Ÿ 你的速度、加速度、汽車重量、牽引系數、摩擦力?(三階)
　　Ÿ 你的引擎溫度、轉數以及瞬時油耗?(二階)
　　Ÿ 看著窗口以防撞車?
　　控制測量 vs. 詢問測量
　　Ÿ 一個控制測量是指促成決定的測量方法
　　Ÿ 任何你用的控制自知系統的測量方法將讓系統控制你
　　Ÿ 一個詢問測量是任何幫助你在正確的時間問正確的問題的方法
　　Ÿ 詢問測量有賭博的意思，但是收益會非常低，所以人為操控的可能性幾乎沒有
　　測量，從定義上看，是現實的簡化版，并且同樣的數字能夠表示出不同的現實場景。
　　任何包含人的系統都是自知的。任何你用的控制自知系統的測量方法將讓系統控制你。
　　一個詢問測量可能看起來像控制測量。區別就在于你如何用以及如何推斷。
　　觀察是在沒有定量測量的情況下能夠直接做出評估和控制行動的方法。這是一階方法。要問碰到其他模型怎么辦，除了數字類型的，你都可以使用這個方法。應該從你想要解決什么問題或你想要評估什么場景開始問起。與間接觀察相比，更應做直接觀察。確保你已經考慮了很多可能的解釋，然后選擇一種控制行為或者搜索以獲取更詳細的信息。如果你擔心觀察和評估是主管的(確實)，問相關的多個人。
　　光明未來
　　通過詢問來測量，而不是控制
　　Ÿ 像通過/失敗率以及缺陷發現率這樣的度量標準忽略了幾乎每個相關因素
　　Ÿ 需求和bug關聯的因素
　　Ÿ 問題解決的困難程度
　　Ÿ 產品設計的質量
　　Ÿ 代碼質量
　　Ÿ 發布時間
　　Ÿ 誰做出發布決定，為什么
　　Ÿ 客戶采納的時機
　　Ÿ 我們用這些虛假的度量標準去評估測試質量?
　　一行代碼代表一個思想。一行代碼既能簡單到在CPU的寄存器中存放一個值，也能復雜到一個多分支、多條件的判定點。一個開發人員的任務是學習、解決問題，構造和重新構造解決方案。有時這意味著移除代碼，而不是添加。評估開發人員做的事情遠不止統計有多少行代碼這么簡單。代碼行數的統計是同樣愚蠢的測量方法。
　　什么是探索測試
　　Ÿ 我接受(也做了一定程度貢獻)Kaner的定義，這個定義2007年經過多個會議中的修正。
　　探索測試是：
　　Ÿ 一種風格的軟件測試方法
　　Ÿ 強調個體自主權和責任
　　Ÿ 是針對單個測試人員
　　Ÿ 為了持續優化他/她工作的價值
　　Ÿ 通過處理測試設計、測試執行、測試結果說明以及測試相關的學習
　　Ÿ 作為相互支持的活動
　　Ÿ 并行的執行
　　Ÿ 貫穿整個項目
　　為什么探索?
　　Ÿ 你不能用一個腳本
　　Ÿ 調查你已發現的問題
　　Ÿ 判斷腳本是否有問題
　　Ÿ 避開你已識別出的腳本問題
　　Ÿ 識別產品中嚴重的風險
　　Ÿ 決定組織報告的最佳方式
　　Ÿ 弄清令人困擾的場景
　　即使是“腳本”測試人員也一直在探索!
　　是的，探索測試需要專業技能
　　探索測試是結構化的
　　Ÿ 我們已經學習了ET(探索測試)結構，我們已經寫下來，我們知道如何教
　　Ÿ ET結構有很多來源(非過程化結構，是認知的結構)
　　Ÿ 測試設計啟發
　　Ÿ 大綱
　　Ÿ 時間限制
　　Ÿ 覺察產品風險
　　Ÿ 具體測試的類型
　　Ÿ 待測產品的結構
　　Ÿ 學習產品的過程
　　Ÿ 開發活動
　　Ÿ 項目負擔的限制和資源
　　Ÿ 測試人員的技能、才能和興趣
　　Ÿ 測試全面的目標
　　探索測試是可說明的
　　精簡的文檔，最小的浪費
　　詳細的過程文檔非常昂貴，通常是不需要的。
　　教程似的文檔也通常不需要，但是如果你做了，那么將它和工作文檔區分開來。
　　探索測試是可說明的
　　基于會議的測試管理
　　Ÿ 大綱
　　Ÿ 每個測試會議有一個清晰簡明的任務
　　Ÿ 時間限制
　　Ÿ 90分鐘左右(+/-45)
　　Ÿ 審核結果
　　Ÿ 一份會議記錄一份測試報告，數據可以被工具掃描、分析和編譯。
　　Ÿ 任務匯報
　　Ÿ 測試人員和管理者或者測試主管之間的溝通
　　探索測試是可管理的
　　在實際測試和使用系統過程中，通過摸索不同的測試設計來提煉優秀的測試設計方案。
　　通過個別監督和簡明的測試思路指導測試人員。同時，訓練他們能夠指導他們自己，能夠考慮到可能增加的工作挑戰。
　　探索測試是可管理的
　　注意檢查的角色，尤其是當開發人員編寫和維護代碼后，需要增加額外的測試組件。

原文轉自：http://www.kjueaiud.com