|
測試員的角色
1）測試給項目產品做關鍵決策時提供信息依據。
2）測試員要明確自己的在項目中的使命，使命決定要做的一切。
3）測試員要服務於多類客戶，針對不同客戶，提供不同信息。（例如：技術支持、管理者、市場人員）
4）測試員需通知客戶有關威脅產品價值的任何信息。
5）測試員要迅速找出重要的程序問題。（變更的、核心的、常用的、可用性、影響大的、最需要的部分）
6）爲程序員提供支持。儘量建立最短、最快的反饋環路。
7）詢問項目相關一切問題，最好結合其他溝通形式提問。
8）測試員關注失效，客戶才能關注成功。注：確認程序正常是不可能的，除非運行所有可能的測試，所以確認成本是很高的。
9）測試員不會發現所有程序問題。所以應自知不能完成所有事，合理有效安排自己的時間。
10）測試員當心向客戶傳遞隱藏的已“完備的”測試。應讓客戶詳細瞭解測試過程，總結自己已實施和未實施測試點及如此安排的原因。
11）通過測試不能保證質量。測試員既不會提高質量，也不會降低質量，質量來源於構建產品的人。注：測試員能促進項目質量保證的信息，但質量保證是來自整個項目團隊的。
12）永遠別做看門人，即測試員永遠不要把控產品發佈的權力。因爲這樣團隊其他成員可能會放鬆質量。建議：由控制項目、條件好的人承擔發佈產品責任或由集體決定是否發佈產品。
13）當心測試中的“不關我事”理論。測試員的使命應該是盡其所能，通知團隊可能會對產品的價值產生消極影響的所有問題。
--14）當心成爲過程改進小組。因不管過程改進要幹什麼，它永遠都會涉及感情。
15）別指望任何人都能理解測試，或理解測試員需要什麼條件才能搞好測試。所以測試需向客戶解釋測試，且需一遍又遍地解釋。因爲疫苗的作用會逐漸衰退。
測試員的思考方式：
測試員不喜歡抱怨，他們喜歡提供證據；測試員不喜歡征服，他們喜歡打破產品沒問題的幻覺；測試員不喜歡發佈壞消息，他們喜歡把客戶從虛假信念中解放出來。
16）測試運用的是認識論。認識論研究如何認識所瞭解的東西：研究證據和推理。（如：怎麼知道軟件足夠好？如果軟件不是足夠好，怎麼才能知道？怎麼知道已完成了足夠的測試？）
17）研究認識論有助於更好測試。（例如：如何收集和評估證據？如何進行有效的推論？如何使用不同邏輯形式？如何做出好的決策？）
18）認知心理學是測試的基礎。如果說認識論告訴我們應該怎樣思考，那麼認知心理學告訴我們的是我們是怎樣思考的。（例如：人的感覺和記憶可靠性。信念從哪裏來。在壓力下如何思考。）
19）測試能力差別在於測試員如何思考。（如：測試員的測試設計選擇；解釋所觀察到的現象的能力；分析描述這些現象的能力。）
20）測試需要探索式推斷，而不只是輸出與預期結果對比。
21）優秀測試員會進行技術性、創造性、批判性、實用性地思考。
- 技術性思考：對技術建模並理解因果關係的能力。（如：相關技術事實的知識和使用工具並預測系統行爲的能力。）
- 創造性思考：產生思想並看到可能性的能力。（如：尋找猜想可能存在的問題。）
- 批判性思考：評估思想並進行推斷的能力。（如：消除錯誤的能力並構建好的測試用例的能力。）
- 實用性思考：把想法付諸實施的能力。（如：運用測試工具，並使測試手段和力量與項目範圍適應的技能。）
22）黑盒測試並不是基於無知的測試。因爲測試員對產品及產品的方式瞭解得越多，越能更好地測試它。而黑盒測試的優勢在於測試員可能與程序員的思考不同，因此有可能預測出程序員所遺漏的風險。
23）測試員不只是遊客。兩者差別：測試員把精力放在評估產品上而不只是見證產品。注意：測試員對產品做大量的非測試的事（例如：看看產品由什麼組成；怎麼工作的。），有助於對產品的瞭解，爲了更好地測試。
24）所有測試都試圖回答關於已BUILD產品和用戶所需產品間關係的某個問題。
--25）所有測試都是基於產品模型（例如：誰是用戶，用戶關心什麼等一些概念），而不是實際產品。
26）直覺是不錯的開始，但又是糟糕的結束。建議：把直覺用作指南，但不能用作合理性證明。
27）爲了測試，必須探索。所有測試都是採樣，且樣本永遠不可能完備探索式思考要在整個測試項目過程中，在尋求最大化測試價值時起作用。這裏所謂的探索，是指有目的的漫遊：帶着一般使命在某個空間中漫遊，但沒預先確定的路線。探索包括不斷學習和實踐。
28）探索要求大量思索。探索就是偵查，是沒有邊界的搜索，需要前向、後向、側向思索。
- 前向思索：根據已知探索未知，從所看到的探索還沒看到的。注意支流和副作用。
- 後向思索：從懷疑或想像的東西返回到已知，嘗試證實或否定自己的推測。
- 側向思索：讓自己的工作由於新冒出的想法而轉移，然後再探索主題返回到主線索上。
--29）使用誘導推斷邏輯發現推測。誘導推斷又叫做假設歸納，是一種測試員每天都要使用的關鍵推理形式：最佳解釋的推理。主要內容是：
第1：收集一些數據並要找出其中的意義。
第2：構造可能說明這些數據的各種解釋。
第3：收集更多的數據，以確定或否定每種解釋。
第4：從候選解釋中，選擇能夠最一致地說明所有重要數據的解釋，如果沒有足夠證據證實任何結論，剛繼續搜索。
30）使用猜想與反駁邏輯評估產品。
20世紀初，哲學家Karl Popper引入了猜想與反駁方法，用於如何區分宗教和科學問題。這種方法基於科學家永遠也不能絕對肯定任何具體事實，或關於自然的理論這個前提。這個方法，以如下三種重要方式應用於測試：
第1：測試的目的是顯示產品失效，要比顯示產品正常更有力。
第2：有關軟件（軟件有怎樣的行爲、如何好等）已經牢固形成的信念應該受到質疑。
第3：警惕聲稱以超過測試員所運行的具體測試的試，檢驗或確認了產品的測試。任何量的測試都不能提供產品質量的確認性。
31）需求是重要人物所關心的質量或條件。作爲測試員，必須認識到誰的關於質量的觀點最重要；不同客戶通過產品要得到不同的東西，他們不一定知道要什麼，而且所要的東西會隨時發生變化，這使得測試員的工作更有意義。
32）通過會議、推導和參照發現需求。需求信息到達測試員主要有三種途徑：
第1：會議：找出其關於質量意見最具影響力的人，與他們交流，瞭解他們最關心什麼。
第2：推導：通過外推已知的項目和產品其他信息，確定什麼需求最重要。
第3：既發現顯式，也發現隱式規格說明，並以此作爲測試的基礎。
33）既要使用顯示規格說明，也要使用隱式規格說明。
--顯式規格說明是一個有用的需求信息源，經過客戶的權威確認。（如：“是的，這就是規格說明，是產品描述。”）
--隱式規格說明是沒有經過客戶權威確認的一個有用的需求信息源。（如：“這不是規格說明，但是有意義。”）隱式規格說明的威信來自其內容的說服力和可信性，而不是客戶的批准。在大多數情況下，只有部分隱式規格說明與當前產品有關。其存在形式：
競爭對手的產品、相關產品、同一產品的老版本、項目團隊之間的電子郵件討論、顧客意見、圖形用戶界面風格指南、操作系統兼容性需求、測試員自己的豐富經驗等。
34）“它沒有問題”真正的含義是，它看起來在一定程度上滿足部分需求。注意：測試員所認爲的“它沒有問題”的意義，可能與別人的定義不同。
35）任何時候報告產品質量狀態時，都應該用有關測試方法和測試過程等已知侷限性的信息對報告限定。因爲不管測試員對產品的質量有什麼看法，都只是猜想。
--36）不要將試驗與測試混淆。測試需包括四個活動：配置、運行、觀察、評估。
37）當測試複雜產品時，使用“陷入與退出”法（plunge in and quit）。即，試着先研究複雜產品30分鐘或1小時，然後停下來乾點別的。這個方法的優點是，除了選擇產品的一部分進行研究外，絕對不需要計劃。這個幾個輪次的陷入與退出後，就能開始明白產品的模式和輪廓。
38）運用試探法快速產生測試思路。（試探法測試，如：測試邊界、錯誤消息、與程序員不同的配置環境、比較難設置的測試、避免冗餘測試等） 請注意：試探法中並沒有智慧，智慧來自測試員，試探法所能夠做的，只不過就是爲測試員的思考提出建議。在收集測試方法時，要了解每個方法背後的原理，以及適用和不適用的條件。
39）測試員不能避免偏見，但可以管理偏見。多樣化可抵禦過強的偏向，測試員集體談論測試問題，可將一個測試員的偏向降低到最低限度。
注意：試探法也是一種偏向，使用試探法，是因爲其偏向可以以較好的方式引導測試員。
常見偏向：
同化偏向、證實偏向、可用性偏向（以頭腦中已有的一種用戶操作場景作爲最常見的場景）、最初印象偏見、最新印象偏見、框架效應、知名偏向、表達偏向。
40）如果知道自己不聰明，就更難被愚弄。做到這一點並不難，只需仔細看看自己在測試中犯的錯誤，且在考慮自己的測試策略細節時就會更認真一點。任何時候都要注意其它測試員發現了本應自己也能發現但未發現的問題。
41）回溯漏測問題產生原因，是意外還是測試策略所致。
42）測試員的困惑，可能是某種重要的預示。（困惑內容，如：規格說明書不清楚；產品不清楚；用戶文檔不清楚？內部問題難以理解。）
43）新眼光或角度會發現失效。防止固化測試思路的三點提示：
第1：第一次接觸產品或功能時，要特別注意使自己困惑和煩惱的地方，因爲用戶也會有類似反應。
第2：當與團隊新成員一起測試時，觀察他們在瞭解產品時的反應。
第3：警惕陷入測試慣例。在任何可能的地方引入多樣性，或改由其它測試員負責。
44）測試員不能盲目遵循過程，除非過程先跟隨自己。注意：其一：如果要遵循測試過程，最好採用自己設計、自己擁有或已經完全瞭解的過程。其二：爲了得到最好結果，測試員必須掌握自己的測試，而不是自己的文檔，即要使過程跟隨自己。
45）在創建測試過程時，避免“1287”。即，編寫測試過程時要避免與測試概念無關的細化，只需包含所有必要的信息和設計與解釋測試所需的細節，但要讓未來的測試有創造性和判斷力地執行。
46）更好、更聰明的測試員是測試過程的一個重要成果。好的測試員永遠都在學習。注意：在評估測試過程時，首先要看項目測試員的素質，要看他們怎麼思考，以及這種思考怎樣對其行爲產生影響，只有掌握了這些信息才能評估他們的工作產品。
47）除非重新發明測試，否則不能精通測試。我們應該把東西分解，琢磨其工作原理，再以新的方式組裝以適應新的條件。在學習過程初期，要重新發明不是非常好的測試、想法、手段和文檔。這是正常的，要永遠使頭腦運轉，觀察其它測試員，研究和不斷評估如何篩選自己的思想，要善於做到這一點，就必須實踐。
測試手段：
48）關注測試員、覆蓋率、潛在問題、活動、評估的組合測試手段。即“五要素測試系統”。建議：測試時要時刻想都會所有五個要素，
可能做出更好的組合選擇，而不是採用只關注一種要素的手段。
- 測試員：進行測試的人。
- 覆蓋率：測試了哪些內容。
- 潛在問題：測試的原因（要測試什麼風險）。如：測試不滿足這個需求的各種方式。
- 活動：如何測試。
- 評估：怎麼判定測試通過還是不通過。
49）關注測試員的基於人員的測試手段。（如：強力測試、有關領域的專家測試、結對測試、自用測試）
50）關注測試內容的基於覆蓋率的測試手段。（如：域測試、最佳代表測試、組合測試）
51）關注測試原因（針對風險測試）的基於問題的測試手段。（涉及約束衝突的錯誤例子：輸入約束、輸出約束、計算約束、存儲（或數據）約束。）
基於風險測試設計建議：
第一：如果進行基於風險的測試，還需做相當量的非基於風險的測試，以針對瞭解還不夠，還不能做出正確決策的風險進行測試。
第二：針對時序測試，如：競爭條件或其他事件意外發生順序。
第三：在創建測試時，需創建測試過程，以強制程序使用測試員輸入的測試數據，從而能夠確定程序是否不正確地使用了這些數據。
52）關注測試方法的基於活動的測試手段。（如：冒煙測試、探索式測試、遊擊式測試、場景測試。）
53）關注測試是否通過的基於評估的測試手段。（如：與規格說明或其他權威文檔比較、基於理念的測試）
啓發式一致性。一致性是評估程序的重要評判準則。七種主要的一致性：與歷史一致、與我們的想像一致、與可比較的產品一致、與所聲明的內容一致、與用戶的預期一致、產品內部一致、與用途一致。
54）根據自己的看法對測試手段分類。注意：進行實際測試時，仍需在五個要素方面進行決策，包括：誰來測試？要測試程序的哪些方面？要尋找什麼類型的問題？具體要完成的任務？如何確定測試是否通過？
基於規格說明的測試的可跟蹤性矩陣：（優點：顯示永遠不會測試的功能及經常測試的功能點；當某個規格說明變更後，顯示對測試影響範圍。）
如何分析與程序的某個部分或方面關聯的風險：分析可從兩方面入手，其一：被測對象不能通過產品質量的某種重要度量（質量屬性）；其二：考慮被測試對象可能出錯的因素（問題起因）。
質量屬性：例如：併發性（concurrency）、標準符合性（conformance to standards）、可伸縮性（scalability）、可維護性（maintainability）、效率（efficiency）等。
問題起因：例如：新功能、新技術、新市場、學習曲線、變更後的功能、後期變更、貿然的工作、差的設計或沒有可維護性的實現、疲倦的程序員、其他的人員問題（例如：互不溝通）、意外溜入、外部組件、預算外、模糊、矛盾的需求、未知需求（開發過程中，新需求不斷浮現）、需求變化、複雜性、問題過多、依賴性（失效可能觸發其他失效）、不可測試性（緩慢低效的測試風險）、沒經過單元測試的、未進行過系統測試、依賴狹窄的測試策略、弱的測試工具、不可修改性（不能修改錯誤的風險）、程序設計語言類型錯誤。
缺陷表的使用方法：
a在缺陷表中找到一個缺陷。
b研究被測量軟件是否會有這種缺陷。
c如果在理論上有這種缺陷的可能，研究如果存在，應如何發現。
d研究在程序中出現這種錯誤的可能性，如果存在會產生怎樣嚴重的失效。
e如果可以，針對這類錯誤設計一個或一系列測試。
程序錯誤分析（編寫表達BUG報告）
55）錯誤報告，文如其人。
56）好的錯誤報告，能推動錯誤的改正。測試員的責任不是保證所有錯誤都得到改正，而準確報告問題，使讀者能夠理解問題的影響。
57）使自己的錯誤報告成爲一種有效的“銷售工具”。因爲錯誤報告勸導人們付出寶貴資源來換取測試員所建議的好處。對於程序錯誤，資源就是時間和資金，好處就是通過改正這個錯誤而帶來質量改進。銷售策略一般有兩個目標：其一：陳述種種好處，使得潛在客戶想要它。
二：向銷售人員說明預期存在的問題，並反駁他們。
58）錯誤報告代表的是測試員。
59）努力使錯誤報告有更高的價值。例如：
- 報告缺陷，並幫助程序員定位內部問題。
- 報告規格說明、測試文檔、用戶文檔或開發工具中的問題。
- 爲技術文檔編寫員提供背景信息，編寫員要編寫手冊或公司網站中的問題定位部分。
- 報告提示需要通過客戶培訓解決的問題。
- 報告爲客戶售後支持人員提供關鍵信息，如他們會遇到哪些沒被解決或不完全解決的問題。
- 報告和管理員提供正在開發的產品狀態和質量信息。
- 報告在開始計劃產品下一個版本時，提供初始改進建議。
60）任何產品/項目的相關人員都應該能夠報告程序錯誤。
61）引用別人的錯誤報告時要小心。注意：一方面：如果沒得到允許，可以補充評論，但不能編輯別人的材料，即使錯誤報告很糟糕也不要擅自修改因爲很可能會遺漏重要信息的風險；另一方面，任何時候要在（特別是其他人的）錯誤報告做補充，都要註明自己的姓名和日期。
62）將質量作爲錯誤報告。（質量對於個人來說就是價值。）測試員的任務就是幫助項目相關人員寫出清晰的其對產品感到沒價值的意見。
63）有些產品/項目相關人員不能報告程序錯誤，測試員就是他們的代理，所以應站在他們的立場理解要報告的內容。例如：測試員必須研究用戶使用產品的方式，以及他們喜歡這種產品的什麼，不喜歡什麼。
64）將受到影響的項目相關人員的注意力轉移到有爭議的程序錯誤上。例如：如果測試員認爲很難說服程序員改正錯誤，但是測試員希望改正，可以考慮公司中如果這個錯誤被改正能夠受益的其他人。
65）決不要利用BUG管理系統監視程序員的表現。例如：使用該系統估算修改代碼的時間，這樣會使程序員感到爲難外，其他程序員也就防備這個系統，最有可能的結果是，程序員爭辯設計問題並不是程序錯誤，類似的錯誤是重複的等。
66）決不要利用BUG管理系統監視測試員的表現。例如：如果測試經理用BUG數作爲考覈依據，測試員也許會報告容易發現、更膚淺的BUG，也許更願意報告同個BUG多個實例；他們會不願意花時間指導其他測試員；程序員更有可能認爲測試員是爲了BUG數而不質量。
67）及時報告BUG。因爲BUG報告拖延的時間越長，BUG被修復的可能性就越小；另一個風險是：項目其它相關人員就錯誤地以爲已測功能點沒BUG很穩定。
68）永遠不要假設明顯的BUG別人已提過。
69）測試員應報告設計錯誤。
70）極端的缺陷是潛在的安全漏洞。
71）使冷僻用例不冷僻。例如：極值測試思想：如果程序能夠在這種條件下存活，那麼在不那麼極端的情況下也可以存活。因些可以通過少量極端測試瞭解很多東西。
72）小缺陷也值得報告和修改。Kaner和David Pels研究發現小缺陷（指修改BUG在4小時以內的BUG）修改可避免該產品一半以上的技術支持成本。
注意：任何產品都會殘留一些小缺陷。但隨着小缺陷數量增加，客戶信心會下降，更糟糕的是容忍這些缺陷的腐蝕作用。當連報告小缺陷的行爲都停止後，測試員和公司就會容忍越來越多的嚴重缺陷，長此以往，最終會使產品失敗。
73）時刻明確嚴重等級和優先等級間的區別。嚴重等級：指BUG的影響或後果；優先等級：指什麼時候要求修復。
74）失效是錯誤徵兆，而不是錯誤本身。因此，任何時候看起來很小的錯誤，都要：執行後續測試，以發現更嚴重的徵兆或以發現更一般的場景。當問題很難重現時，可執行後續測試，以確定使該問題重現的關鍵條件，然後執行後續測試，以充分暴露現在已可重現的問題。
75）針對看起來很小的代碼錯誤執行後續測試。如果看到的是小失效，不要只是重現該失效並寫入報告。程序處於脆弱狀態，嘗試利用這一點，繼續測試，並可能發現內部缺陷的實際影響是糟糕得多的失效，例如系統崩潰或數據損壞。
對於每個認爲反映了編碼錯誤的失效至少要做幾分鐘的後續測試，要相信自己的判斷。建議嘗試如下三種後續測試：
a變化自己的行爲。（通過改變操作方式改變條件）
b變化程序選項和設置。（通過改變被測試對象的條件）例如：使用不同的數據庫，改變持久變量的取值等。
c變化軟件和硬件環境。注意：這不是配置測試，不是要檢查標準配置上的缺陷，而是要調查怎樣變更配置纔會使這個失效暴露充分。
76）永遠都要報告不可重現的錯誤，這樣的錯誤可能是時間炸彈。注意：不要報告還沒盡力重現的程序錯誤，但如果盡力之後仍不能重現該程序錯誤，仍值得報告，不過要明確說明自己不能重現這個程序錯誤。
77）不可重現的程序錯誤是可重現的。如下是無法重現時需注意的關注點：
a程序錯誤可能有延遲效應，例如內存泄漏、指針越界。
b程序錯誤可能只是在安裝、使用產品或使用產品的特定功能時出現一次。恢復乾淨系統，重新裝載該程序，檢查現在是否能夠重現該問題。
c程序錯誤可能依賴於特定的數據取值或被破壞了的數據庫。
d程序錯誤可能只在特定的時間或日期內發生。檢查日末、週末、季度末、年末。
e缺陷可能依賴於以特定順序執行一系列相關的任務。在執行這個失效任務前做了什麼？
f程序錯誤可能是前面失效的殘餘。例如：上一次出現GPF後重新啓動計算機了嗎？
g程序錯誤可能是由被應用程序與後臺運行的其他軟件，或與被測試應用程序競爭設備訪問軟件的交互引起的。
78）注意缺陷報告的處理成本。
79）特別處理與工具或環境相關的程序錯誤。
80）在報告原型或早期個人版本的程序錯誤之前，要先徵得同意。注意：在正式測試時，要把以前發現但仍沒被修復的問題錄入BUG管理系統。
81）重複錯誤報告是能夠自我解決的問題。注意：
a不要讓搜索時間失控。如果BUG數據庫大，可能需花大量非生產時間搜索重複程序錯誤。
b編寫良好的相同BUG的所有報告都包含新信息，有助於更容易修復BUG。
c兩個報告是否重複還需再統一確認。兩個失效可能是由同一個缺陷引起的，多個缺陷可能涉及到一個失效。要保留所收藏到的所有信息，直到確認統一併修復了該BUG。
82）每個程序錯誤都需要單獨的報告。Pettichord另一種建議：
有時爲了提高效率，可以在一份報告中包含多個相似的小BUG，假設這些BUG可以一次全解決。如果這個問題單狀態標記爲已修復後，仍有沒修復的殘餘BUG，可以爲這些沒修復的BUG寫一份新報告，並引用已修復的老問題單號。
83）BUG標題是錯誤報告中最重要的部分。建議包含的內容：
a簡要描述，要足夠具體，使讀者能夠想像出該失效。
b簡要指出程序錯誤的侷限性或依賴關係。例如：BUG產生的環境侷限。
c簡要指出程序錯誤的影響或後果。
84）不要誇大程序錯誤。記住，測試員的可信性是影響力的基礎。
85）清楚地報告問題，但不要試圖解決問題。
86）注意自己的語氣及報告的格式。例如：全部採用大寫字母，則讀起來像是編寫報告者在尖叫。
87）使自己的報告具有可讀性，即使閱讀對象是勞累和暴躁的人。要使重現步驟的描述簡潔：
a一次只走查該程序錯誤一步。
b爲每一步編號。
c不要跳過重現問題所需的任何步驟。
d儘量寫出能重現的最少步驟。
e通過空行使報告更容易瀏覽。
f使用簡短句子。
g說明實際發生了什麼，自己預期會發生什麼。
h如果後果很嚴重，可解釋爲什麼自己認爲很嚴重。
i便於程序員意識到問題或便於自己迴歸測試，可補充註釋。
j對於複雜產品或問題，考慮使用描述的頭三行專門小結問題，然後給出問題細節。
k要始終保持中立語氣。
l不要開玩笑，別人會產生誤解。
88）提高報告編寫技能。研究BUG管理系統的BUG，找出提高報告編寫技能的思路。例如：
a比較已修復的BUG和未修復的BUG，研究兩都報告方式的差別。
b研究程序員對錯誤報告的反映。例如：什麼使他們困惑不解、不能接受、能夠接受？
89）如果合適，可使用市場開發或技術支持數據。例如：
a可與同行產品進行比較，有助於描述用戶預期及有助於市場開發經理評估問題的嚴重等級。
b調查市場與客戶接觸時都遇到什麼問題，他們如何說明產品，演示什麼，怎麼演示，在報告中使用調查結果。
c如果可能，將報告的BUG與相關的技術支持記錄聯繫起來。可估計延遲修復BUG的技術支持成本或如果BUG留在產品中將會面臨客戶或技術支持人員的不滿。
90）相互評審錯誤報告。例如：在提交給程序員前，要安排第二個測試員評審所有報告缺陷。第二個測試員要：
a檢查是否清楚地提供了關鍵信息。
b檢查是否可重現該BUG。
c研究該報告是否能夠簡化、概括或加強。
測試員可以評審：所有缺陷、自己發現的所有缺陷、同事發現的所有缺陷。如果發現報告有問題，可找報告提交人討論該BUG。
注意：這是一種培訓員工、提高報告質量的有用的方法，但注意不要過多地增加評審測試員的負擔。評審過程需時間。
91）與將閱讀錯誤報告的程序員見面。
92）最好的方法可能是向程序員演示所發現的BUG。
93）當程序員說問題已經解決時，要檢查是否真的沒問題了。
94）儘快迴歸已修復的BUG。
因爲儘快迴歸已修復BUG，一方面，可表現出對程序員的尊重，也使程序員將來更有可能對測試員所報告的BUG迅速做出響應。另一方面，程序員可能仍然記得自己是怎麼改的代碼，並能夠立即處理該問題。
95）如果迴歸不通過，應與程序員溝通，而不僅僅通過報告反饋信息。測試員與程序員溝通時，語氣和態度應該友好、熱心。測試員要幫助程序員立即得到信息，並準備隨時澄清報告中的任何不清楚的地方，如果程序員想看，應準備隨時演示該BUG。
96）錯誤報告應該由測試員關閉。一般情況下，報告該BUG的測試員應再次進行測試，但是如果程序錯誤是非測試員報告的，是應由最熟悉程序這部分的測試員進行評估，如果可能，該測試員也應該諮詢原始報告者溝通。注意：除非經過測試員的評審和關閉，否則任何BUG都不能標識爲已關閉。
97）不要堅持要求修改所有BUG，要量力而行。注意：如查不能舉出某個BUG很重要，或產品/項目相關人員有充分支持測試員關於推遲特定BUG修復的請求，我們建議還是把該BUG放在一邊，先考慮其它問題。
98）不要讓延遲修復的BUG消失。建議：在項目一開始時評審延遲修復的BUG，因爲此時進度壓力最輕，而且項目經理也處於最清醒、最理智的狀態。
99）測試的惰性不能成爲BUG推遲修復的原因。
注意：如查測試經理要求程序員不要修復該BUG，而原因僅僅因爲修復該問題會影響太多的檢查單、腳本或其他測試用例，因此要佔用太多的管理時間，那麼說明測試過程存在致命缺陷。
100）對BUG延遲修復應立即上訴。
101）如果決定要上訴，就一定要贏。
注意：如果測試員確實要上訴，不要依賴自己最初錯誤報告中的語言和信息。如果測試員不列舉出更有效的例子，則不僅是浪費自己的時間也損害自己的信譽。爲了準備自己的上訴，測試員需提前做到如下幾點：
a與其它產品項目相關人員溝通。找出如果BUG留在產品對其影響最大的人，確定該BUG會增加他們多少成本或給他們帶來多大麻煩。
b補充做一些後續測試，尋找更嚴重的後果或尋找更廣的環境下產生。
c創建一些場景，說明合理的用戶在合理地使用該產品時也會遇到該問題。
d尋找一些討論與所報告錯誤類似問題的報刊文章。如：同行交付類似問題的產品後帶來的後果。
測試自動化：
如果自動化能促進測試使命的完成，就利用自動化。評估利用自動化是否成功的標準，是看它在多大程度上幫助測試員完成自己的使命。
測試自動化注意點：
a在決定要自動化的內容時，首先設計自己的測試。這樣可避免落入自動化測試的陷阱：易於自動化，但在找缺陷上很弱。
b採用與設計手工測試不同的方法設計自動化測試。例如：自動化時需考慮考慮人所不能做的事。因爲在設計手工測試時，測試員不太可能考慮如數千文件重複進行的測試，只因工作量太大。
總結爲兩點：
a沒有好的測試設計的自動化可能會產生大量活動，但沒什麼價值。
b沒很好理解自動化可能性的測試設計，可能會低估一些最有價值的自動化機會。
102）加快開發過程，而不是試圖在測試上省錢。
即如果要得到支持，就要把精力集中到降低開發失效的風險上。例如：迅速找出新版本中不穩定的變更；儘快暴露迴歸結果；快速報告問題。
其中，支持加快開發節奏的手段有：自動化冒煙測試、自動化單元測試。
冒煙測試：這個詞來自硬件測試。測試員插入一塊新板子並接通電源。如果看到板子冒煙，立即切斷電源。不必再做進一步的測試。冒煙測試又叫“版本確認測試”在有限的時間內，快速測試產品的功能。如果關鍵的功能不能正常運行或重要的BUG迴歸不通過，測試員就不再浪費時間安裝或測試該版本。
103）拓展測試領域，不要不斷重複相同的測試。注意：利用自動化拓展測試領域，使測試員能夠看到更多、做到更多。
自動化測試可拓展如下的測試範圍：負載測試、性能基準測試、配置測試、耐力測試、競爭條件、組合錯誤。
104）根據自己的背景選擇自動化測試策略。自動化測試策略受測試需求、軟件產品體系結構、測試人員技能。
測試需求：系統中往往只有少量的功能是關鍵的，且會被要求將其自動化；另一方面關注自動化能如何幫助控制產品的主要風險。
軟件產品體系結構：分析產品體系結構以確定測試自動化的可能性。例如：主要軟件組件是什麼？這些組件如何通信？使用了什麼技術？有哪些可用接觸點？組件間的關係。即，語言、環境和組件都會影響測試工具的適用性。
測試人員技能：因爲有些自動化測試方法適合沒編寫程序能力的測試員，有些則對編寫程序能力要求較高。
105）不要強求100%自動化。
106）測試工具並不是策略。注意：工具不能教測試員如何測試，如果測試出問題，則測試工具會加重問題。在實現測試過程自動化前，應首先解決測試過程中的問題。
107）不要通過自動化測試使無序情況更嚴重。如果測試設計得很差，則自動化會使差的測試執行得更快；如果測試組織得很差，計算機並不會替人組織，且自動化測試會把人的注意力從真正需要做的工作移開。
108）不要把手工測試與自動化測試等同起來。
因爲自動化測試只能執行測試員明確描述的測試，而不能利用測試員隱含的知識和認識。經過專業培訓的人大腦是最好的測試工具，要超過何可能的自動化測試工具。
109）不要根據測試運行的頻率來估計測試的價值。因爲測試價值在於它所提供的信息，自動化測試的價值是成本和效益綜合分析。注意：測試本身是不可比較的，因手工測試和自動測試不能提供相同類型的信息。
110）自動化的迴歸測試發現少部分程序錯誤。非正式調查顯示，迴歸測試發現BUG數佔總數的15%，而老功能的新測試一般能發現接近30%～80%的程序錯誤。
111）在自動化測試時考慮什麼樣的程序錯誤沒有發現。在計算測試自動化的成本時，建議關注機會成本。考慮花在自動化的時間可用來做什麼呢？現在沒運行什麼測試？沒發現什麼BUG？
112）差的自動化測試問題是沒有人注意。例如：自動化測試包是以前創建的，現在仍用來測試該產品。此時需注意：該包可能並不能完成所想像的工作；測試可能已不再重要；覆蓋率可能很差；虛警可能很常見；測試結果可能有錯。
好的測試包是活的。要補充新測試，要修復或刪除老測試。如果沒出現這種情況，測試包就會開始僵化。不久開發人員就會轉到其它工作上，測試包就會開始進入神話般的老橡樹狀態，即動畫片中的那種給出建議的角色。慢慢地，因爲它已存在很長時間，我們盲目相信創建了出色測試包的老測試員的智慧和編碼的現象叫做老橡樹綜合症。
113）捕獲回放失敗。關鍵問題是，這種錄製回放工具的腳本與用戶界面和系統配置的微小細節捆綁得太緊，只要程序或設計一改，這些測試就不能再用了。所以我們建議：要在構建能夠持久或與手工測試結合的自動化測試的技能和規劃上投入，與錄製回放相比，這兩種測試更高效。但錄製回放工具對學習工具很有用，並有助於手工編輯測試腳本，我們反對將錄製回放單獨做爲解決方案。
114）測試工具也有程序錯誤。
115）用戶界面變更。保持與用戶界面設計變更同步，是GUI自動化測試的一個主要困難，如果要自動化GUI測試，需把這點考慮在內。另，我們要抽象測試自動化設計的界面。即當用戶界面變更時，只需升級抽象層，而不是升級訪問修改後界面的所有測試。以下是提供產品GUI抽象的一些手段：
a窗口映射：GUI測試工具支持各種手段來標識窗口控件。例如內容名稱、各種屬性、鄰近標籤和順序位置。注意：不是將標識手段嵌入到對控件的所有引用中，而是使用窗口映射名稱與該控件的標識手段關聯。如果用戶界面變更迫使變更具體手段，則只需更新窗口映射。
b數據驅動的自動化測試：使測試員變更測試過程後仍能使用之前所創建的測試數據。
c任務庫：將測試用例分解爲要素任務。每個任務在概念上都應該是不同的。要特別注意任務的起始和結束狀態。爲這些任務創建可以在測試腳本中使用的函數。如果任務的用戶界面出現變化，只需更新任務而不用更新任務的測試。
d關鍵詞驅動的自動化測試。
e基於API的自動化測試：完成避免GUI。
116）根據兼容性、熟悉程度和服務選擇GUI測試工具。需考慮的因素，例如：確定團隊已知的工具或已知的工具所使用的語言（因爲工具使用培訓和學習費用相當高）；提供商支持工具的能力；需花一段時間測試工具與產品的兼容性，並檢查提供商的服務記錄，要有一個試用期（30～90天），或至少30天的訂金返還保證。
117）自動迴歸測試消亡。自動化迴歸測試不能使用的時間比期望的要早得多。很多自動化測試開發人員都發現，在診斷測試失效和修復退化測試方面所花的時間太多。所以失控的維護成本也許是自動迴歸測試要解決的最常見問題。
118）測試自動化是一種軟件開發過程。測試自動化項目常由於缺乏約束和項目管理而失敗。具體建議做到：規劃項目，並建立里程碑和可音樂會製品，定義需求，對工具、自動化代碼和測試進行源代碼控制；在編寫代碼前先設計並對代碼進行評審和測試；跟蹤自動化程序的BUG；將自動化測試的使用寫成文檔並提供給非自動化開發人員使用。
119）測試自動化是一種重要投資。注意：不要把測試自動化的所有預算都投到測試工具上，那只是冰山一角。
120）測試自動化項目需要程序設計、測試和項目管理的技能。
121）通過試點驗證可行性。例如：計劃用一個月左右的時間顯示結果，然後全面推廣。
122）請測試員和程序員參與測試自動化項目。考慮關鍵域，確立清晰的目標並定義需求：
a可評審性：誰評審測試？做到這一點難度有多大？
b可維護性：誰將維護測試？他們必須瞭解什麼？
c完整性：怎麼知道測試被別人信任？
123）設計自動化測試以推動評審。
--124）在自動化測試設計上不要吝嗇。
自動化測試設計需明確考慮的問題：
a保證測試已被正確地設置。
b描述預期結果。
c發現潛在的錯誤和副作用。
d從潛在測試失效中恢復。
e防止測試相互干擾。
125）避免在測試腳本中使用複雜邏輯。當需要複雜的邏輯控制時，可把邏輯放在單獨的功能中，這樣也可以單獨測試該功能，也使測試更容易評審。注意：要使測試簡單，使測試線性化。
126）不要只是爲了避免重複編碼而構建代碼庫。因爲使用這種庫的測試很難評審、調試、修改。有用的庫應該遵循更強的設計原則，應關注封裝用戶可感知到的任務，特別注意函數的起始和結束狀態。這種工作並不總能達到目的，如果出現這種情況，可採用“開放編碼”方法。（即，保留重複代碼不動）。
127）數據驅動的自動化測試更便於運行大量測試變種。這種方法對於有很多不同數據選項的產品工作流來說最有效。
--128）關鍵詞驅動的自動化測試便於非程序員創建測試。
關鍵詞驅動的自動化測試建立在數據驅動手段上，但是表中包含指令（關鍵詞），而不只是數據。
關鍵詞驅動的自動化測試實行步驟：
a這種方法既要求支持運行測試，又支持設置庫、結果分析和報告的一般框架。
b必須創建一個任務庫，封裝被測產品支持的用戶任務。標識可在測試中使用的所有任務函數，對每個任務函數在任務庫中都有一個記錄與之對應。聲明任務函數有效的起始狀態，以及所產生的結束狀態。這樣可以分辨出哪個任務函數序列有效，以便捕獲有問題的測試。
c增加對讀取電子表格數據的支持，每次讀入一行。通過聲明把第一列解釋爲任務函數的名稱，後續列是函數的參數。使用函數的參數執行該函數。然後指向下一行。
129）利用自動化手段生成測試輸入。在以下情況有幫助，例如：
a創建大文件。
b創建大量測試輸入。
c設置測試牀。
d創建隨機數據。
e覆蓋所有輸入組合。
f覆蓋等價類的所有代表對偶。
g覆蓋邏輯條件的交互。
h通過狀態模型創建測試場景。
130）將測試生成與測試執行分開。例如：數據驅動的自動化測試。這種分離的優點：測試易於理解和評審；可使用不同的測試工具或程序設計環境生成和執行測試；如果預先生成數據，則更容易重複測試；不同的測試專業人員會各自關注自動化測試的不同方面。
131）使用標準腳本語言。例如：Perl、JavaScript、Python。測試員可使用它生成測試用例、訪問編程接口、檢驗結果。注意：腳本語言是便於使用而不是用於提高執行性能的高級語言。建議避免使用提供商自己專用的腳本語言。
--132）利用編程接口自動化測試。公共API（指可用來實現測試的編程接口）和私用API（指沒提供編程接口軟件可能有不公開的接口）因更可能提供穩定性和利於檢測和隔離，所以想要搞好測試自動化，就須學習或找了解這些編程接口的人幫忙。
133）鼓勵開發單元測試包。測試員需一個像Junit這樣的框架來管理測試包的執行，代碼通過該語言所支持的一般調用接口測試。將單元測試用於迴歸測試、冒煙測試和配置測試。
134）小心使用不理解測試的自動化測試設計人員。注意：我們應該運用評審、設計策略和測試來防止開發設計的自動化程序錯誤。
135）避免使用不尊重測試的自動化測試設計人員。
136）可測試性往往是比自動化測試更好的投資。例如：安裝軟件後，用戶需檢查記錄文件以查看是否安裝有誤。如何自動化這種測試？更好的思路是把這些作爲軟件的一個功能在產品內部實現。這樣也許更可靠，實際上可直接使用戶受益。還有一個例子：斷言是代碼中語句，如果結果爲假則指示出現錯誤。斷言放入被測軟件，以檢查結果是否合理，與編寫外部代碼檢驗結果相比，這種方法往往更容易、更高效。
137）可測試性是可視性和控制。可測試性如：訪問源代碼、日誌、診斷、錯誤模擬、測試點、事件觸發器、讀入老的數據格式、測試接口、定製控件支持、允許多實例（即允許同一臺計算機上運行多個客戶端或代理）。
138）儘早啓動測試自動化。原因：
a當測試已成型後，很難把資源轉向自動化。
b當測試員和過程都集中於手工測試後，他們會牴觸變更。
c設計完成後，程序員在可測試性要求方面會變得不那麼合作。
注意：不要一開始就嘗試自動化所有東西，遲早建立基礎設施，但在選擇要自動化哪些測試時要慎重。
139）爲集中式測試自動化小組明確章程。注意：如果有這樣的小組，要確保有明確的章程描述要提供的測試輔助類別；應如何提出請求；以及如何平衡相互矛盾的要求。建議要求接受幫助的測試小組指定專人蔘加測試自動化項目，優點：
a可以評估他們做出的承諾或所面臨的實際問題。
b通過培訓其員工，可減少後續維護和失效分析要求。c通過與該測試小組合作，可以從頭至尾在項目中把他們的測試需求結合到工作中。
140）測試自動化要立即見效。應把關注點放在影響大、成本小的自動化任務。如下是可供參考的自動化切入點：
a系統設置與準備。
b輔助診斷：數據破壞和內存泄漏缺陷一般到該數據被訪問或內存耗盡纔會被檢測出來，而構建這種檢查內存工具也不困難。
c會話記錄：嚴謹的錯誤報告要示提供完整的配置信息，程序可自動收集和報告必要的信息。
d測試生成：利用自動化手段生成測試輸入。
141）測試員擁有的測試工具會比所意識到的多。因爲有些測試工具並沒貼上“測試工具”的標籤。例如：內存監視器、宏工具等。
測試文檔：
我們在使用IEEE標準829的結果並不樂觀，問題在於標準829並不是滿足公司需求的合適方法。
142）爲了有效地應用解決方案，需要清楚地理解問題。
143）不要使用測試文檔模板：除非可以脫離模板，否則模板就沒有用。注意：測試文檔模板不能替代技能。
爲了使用模板編寫好的測試文檔，必須理解模板每一部分的含義，理解爲什麼要有這一部分，什麼時候可刪除。如果測試員對這些都能夠理解，就不再需要模板了。如果不理解這些，就不要受模板的影響。由於測試員不理解模板作者對需求和權衡所做的全面考慮，模板就會使測試員生產率降低。使用模板的人必須能夠根據自己當前具體需求剪裁模板。
144）使用測試文檔模板：模板能夠促進一致的溝通。
145）使用IEEE標準829作爲測試文檔。
146）不使用IEEE標準829。實踐遇到使用該標準的問題如下：
a標準的前提假設看起來是瀑布方法，要在早期開發測試，仔細編寫測試，以後就不再更改。
b大量的測試文檔產生一種盲從心理。
該標準沒提供測試文檔的需求分析，即沒有提供什麼時候提供什麼類型信息的建議或指南。
d沒明顯提到/討論到提供所有這些信息的成本。
e強調文檔的廣度，好像越多越好。
f沒提出判斷測試文檔特定實例好壞的準則。
g這樣大量的文檔維護成本是很高的。
h將每個測試都寫入文檔會嚴重影響自動化的測試等。
147）在決定要構建的產品前先分析需求，這一點既適用於軟件也同樣適用於文檔。
148）爲了分析測試文檔需求，可採用類似以下給出的問題清單進行調查。
a測試小組的使命是什麼，測試這個產品的目標是什麼？
b自己的測試文檔是產品還是工具？如果是產品，測試員可能要按照客戶的要求遵循任何標準，反之則能在最低限度上有助於達到目標即可。
c軟件質量是受法律問題驅動還是受市場驅動？
d設計變更有多頻繁？如果變更頻繁，則不要編寫大量測試文檔，可能不值得。
e反映設計變更的規格說明變更有多頻繁？如果規格說明不完整或過時，則不能採用規格說明驅動的測試。如果不能得到好的規格說明，應計劃修改測試策略，而不是修改項目團隊政策。如果測試員要力爭更好的規格說明，則應該以其它項目相關人員編寫規格說明的成本和風險爲基礎。
f在測試時，是希望證明與規格說明一致，還是希望證明與客戶預期不一致？
g要採用的測試風格更依賴於預先定義的測試，還是探索式測試？如果是前者，主要重用測試用例；如果是後者，則更需要戰略和策略文檔
h測試文檔應該關注要測試什麼（目標），還是應該關注怎麼測試（過程）？
j文檔應該控制測試項目嗎？
k如果文檔控制部分測試項目，那麼是在項目的初期還是後期進行控制？
l測試文檔要在多大程度上支持項目狀態與測試進展的跟蹤和報告。
m文檔要在多大程序上支持向新測試員工指派工作。
n對新測試員的技能和知識做哪些假設？
o測試包應該提供預防、檢測和預測收益。對於本項目來說，哪一種收益最重要?
p文檔的可維護性有多高？多大程度上能夠保證測試變更能夠跟上代碼變更？
q測試文檔有助於標識程序風險模式的永久轉移嗎？
149）用簡短的語句歸納出核心文檔需求。如：
a測試文檔集主要支持我們自己找出這個產品版本中的程序錯誤、指派工作和跟蹤工作狀態。
b測試文檔集將支持當前產品開發和至少10年的測試維護，爲新測試小組成員提供培訓材料，並創建適合管理者或法庭檢查使用的檔案。
程序員交互
150）理解程序員怎樣思考。例如：
a大多數程序員都很專一。形成對比，測試員常常是多面手。爲了更好地測試，測試員必須理解程序的各個部分如何組合在一起，並必須能向程序員提供完整的系統信息。
b程序員關注自己的系統理論。程序員擁有系統組件如何關聯，哪個組件是可靠的，以及錯誤如何傳播的模型。他們說沒問題時，是指這種錯誤與他們的模型不匹配，他們相信模型是沒問題的。所以測試員要仔細記錄，應明確說明實際看到了什麼並讓程序員根據他們自己的推斷找出缺陷。
c程序設計是一種複雜活動。這耗費程序員很大精力，導致他們只想思想集中地關注他們認爲最重要的東西，而對別人打擾感到不耐煩。
d程序員常常要與各種困難做鬥爭。
e很多程序員不喜歡例行工作，常常構建工具和腳本來自動化自己所面臨的重複性工作。測試員不要把自動化測試當作贏得程序員尊重的一種方法。
151）獲得程序員的信任。如果要與程序員打交道，應與其共享信息，這樣測試工作會更有效。且能找出程序員需要什麼樣的反饋信息併爲其提供。測試員如果與程序員有不同觀點，可陳述自己的觀點，但不要反覆嘮叨。
152）提供服務。主動直接爲程序提供幫助。這樣可以建立信任，並證明測試員是程序員應該與之合作的人。測試員能爲之提供的服務：
a測試第三方組件。共享測試結果，使程序員能夠決定是否可在產品中使用該組件，及怎樣使用。
b測試非正式個人版本和原型。
c爲程序員建立測試環境以便程序員自己進行測試。
d評審需求文檔的可測試性。程序員會由於需求很模糊而感覺到頭疼，他們會很歡迎測試員的介入。
153）測試員的正直和能力能被尊重。
報告問題時需注意：
a要乾脆地報告問題。即，一步一步地將問題顯現出來，沒有多餘的步驟。這樣的工作會得到別人的尊重，因爲測試員這樣的表現出的是對程序員時間的尊重。
b將自己的判斷建立在產品行爲的實際觀察基礎上。
c如果失效是不可重現的，要展示爲了重現失效所做的各種嘗試。即展現對程序員時間的尊重，而不是一遇到困難就推給程序員。
--d直接報告壞消息。在向程序員的上司報告前先向程序員提供使用他們能夠做出反應的機會。
e不要假裝瞭解自己並不瞭解的東西。要麼繼續收集證據；要麼不發表意見；要麼明確表明自己是在猜測的。
f不要誇大錯誤報告。
g如果測試員是正直的，就可以展示自己的能力。
154）將關注點放在產品上，而不是人上。
155）程序員喜歡談論自己的工作，應該問他們問題。一個很好的切入點是討論程序員所使用的設計文檔。先做點準備工作，瀏覽能夠得到的所有文檔。如果可能，還可以看看代碼。如果沒文檔，可以向他們索要系統框圖。
例如：當程序員在白板上畫出系統框圖時，測試員指着任意一個箭頭或方框問：“如果不這樣會發生什麼？”這樣會發現遺漏錯誤處理或無異議的假設。對兩個或以上的程序員問這樣的問題，會暴露出程序員間很有意思的觀點差別。此時測試員應做好筆記，並與程序員、其它測試員共享信息，因爲程序員不喜歡一遍又一遍地對不同測試員回答同樣的問題。當測試員在積極地聆聽時，應注意嘗試幫助其他人說出必須說出的內容，詢問能夠啓發補充信息或條件的問題，做出推論等。作爲測試員，其工作就是考慮產品怎樣纔會失效。需要理解產品的價值所在，要讓程序員知道自己理解他們的工作價值。
注意：在向程序員索取文檔等信息時，要向程序員解釋爲什麼需要這些信息，及這些信息對自己工作能帶來怎樣的幫助。因爲程序員不知道測試員在想什麼的。
156）程序員樂於通過可測試性提供幫助。測試員通過程序員得到可測試性功能時，需注意：
a用程序員的語言談話。測試員必須以程序員能夠理解的方式提出請求。例如：確切地描述自己想要在哪部分代碼中提供什麼樣的接口，程序員會相當公正地聽取這類意見。
b儘早提出要求。
c要現實。因爲有些可測試性要求很小，可以與其他實現任務一起完成。有些可測試性要求需要新的功能，像其它所有功能一樣，也有預算和進度計劃問題。測試員還必須向管理層說明這些問題。
注意：提出可測試性要求很難，但是很值得。我們建議讀者要有不屈不撓的精神。
管理測試項目：
管理測試項目與管理其它類型的項目基本一樣，不過至少有一個特點：測試項目是受編程項目驅動的。測試員的工作是對程序員工作的反映。
157）建議一種服務文化。測試員的角色：
a向需要服務的人提供優質服務。即，服務提供者盡更大努力控制他所提供質量和相關性，以取得最終結果。
b服務提供都不控制最終產品的質量，不控制其它服務提供者（程序員、市場開發人員）所使用的過程，不批准或拒絕產品的發佈。注：服務提供者不是項目經理，而是要向項目經理提供服務。
158）不要嘗試建立一種控制文化。測試小組沒資源、經驗或行政力量來改正更廣的開發過程，也不能管理被改正的過程。
注意：我們鼓勵測試員擴展自己在公司中的作用和影響，但是要以合適的角色管理項目，即先當上項目經理的經理，因爲測試經理並不是管理項目經理的角色。
159）要發揮耳目作用。測試員在公司中的權力建立在自己的調查技能和自如溝通的基礎上，而不是建立在命令鏈上，因爲測試員在項目團隊的命令鏈中的位置並不很高。
建議：測試員要成爲能夠爲項目其它人有價值的、守信用的、高度正直的信息提供者。以此來施展和擴大自己的影響力。
160）測試經理管理的是提供測試服務的子項目，而不是開發項目。項目經理在如何動作測試項目上有很大控制權，便測試經理要通過各種方式提出建議，要把自己的想法說出來。如果項目經理沒采納您的建議，那麼接受現實。但如果項目經理做對測試員不恰當的批評或連續加班等超出項目經理合理的職權範圍時，作爲測試經理，自己工作的一個很重要部分就是要保護下屬人員不被濫用。
161）所有項目都會演變。管理良好的項目能夠很好地演變。在每個項目的整個過程中，測試經理一樣準備（正常情況下）對整個計劃的大小細化或更新。項目就是一組任務。項目團隊要爲集成新信息、確定下一步（可能）做什麼、項目完成前的迭代工作提供某種框架。要把項目看作是有關下一步應該做什麼的，及正在進行着的結構化對話。
162）總會有很晚的需求變更。用戶不能確切描述自己需求的原因是：
a他們不知道自己的所有需求。
b當他們試用軟件的早期版本或競爭對手產品後，其需求會發生變化。
c不同項目相關人員具有不同的需求，而這些需求常常是矛盾的。
Bach說過：需求是我們想要的和我們能夠得到的功能間進行不斷鬥爭的結果。
163）項目涉及功能、可靠性、時間和資金間的折衷。項目經理的任務就是：按時並在預算限度內交付一組合適的功能，達到合適水平的可靠性。
164）讓項目經理選擇項目生命週期。明智的項目經理會挑選能夠流暢地控制自認爲很難管理的方法，而預留出自己特別有能力解決的方面。
注意：生命週期選擇相互間有很大不同，做出選擇並不容易。
165）瀑布生命週期把可靠性與時間對立起來。瀑布模型下，要麼修改錯誤而推遲交付時間；要麼按時交付產品，但產品有較多錯誤。這也是項目經理和測試員間經典的爭執。
注意：在瀑布模型中，總不可避免地會存在可靠性和時間之間的折衷考慮，所以使用該模型時需小心。
166）迭代生命週期把功能與時間對立起來。團隊要在任何時候發佈該產品（即發佈通過測試的最新版本），所以新版本與舊版本的區別只是功能數量上的不同。
167）願意在開發初期將資源分配給項目團隊。測試員參加早期開發可以是有價值的活動。例如：
a評審需求文檔的可理解性、可測試性、模糊性。
b可儘早分段對產品進行測試。不要等整個產品完成後才測。
c推動代碼評審。
d擬定硬件配置和準備購置或借用設備的初步清單。
e要求提供可測試性功能。
f討論代碼覆蓋率度量和使用其他開發支持工具。
g準備測試自動化。
h研究測試工具。
--i訂購可用於被測軟件的外部開的發測試包。更一般地，尋找可用於預測的軟件，以便於進行大量測試。
j瞭解產品的市場和競爭情況。要成爲該產品行家，至少要能熟悉使用兩個同行產品。
168）合同驅動的開發不同於尋求市場的開發。
- 合同驅動的開發：開發公司的主要責任是根據合同完成自己的義務。隨着產品的開發，客戶可能會改變有關產品某些功能的想法。
- 尋求市場的開發：客戶只在開發公司已經開發出產品後纔會購買。所以在整個開發過程中，項目團隊的主要考慮是所發佈的產品是否能銷售
- 目標市場。市場人員在整個開發過種中，都會根據所蒐集到的客戶、競爭對手和媒體期望的最新信息，而要求修改設計。
在合同驅動的項目中，測試員的主要活動是對照一組規格說明測試軟件；在尋求市場的項目中，測試員更可能根據不同客戶的預期，來研究和測試產品。
169）要求可測試性功能。
170）協商版本開發進度計劃。內容包括測試小組接受軟件的頻度，對提交的被測試軟件的要求，以及在舊版本中發現的程序錯誤如何在新版本中重現。
171）瞭解程序員在交付版本之前會做什麼及不會做什麼。要了解他們的開發過程（例如：是否有做單元測試）並根據自己對他們的瞭解來確定他們所做的事。
172）爲被測試版本做好準備。當被測試版本就緒時測試環境也應該就緒，這一點很重要。所以管理良好的測試環境是很有價值的，特別是在快節奏的項目團隊中。
173）有時測試員應該拒絕測試某個版本。拒絕理由如下：
a由於這個版本應加入某個關鍵功能，測試員發現沒加或馬上失效。
b以前正常關鍵功能現在不能正常使用。測試小組的冒煙測試應發現這種失效。
c如果收到一個版本，並已知另一個版本在幾個小時後將完成，並且不會以任何方式受這個版本發現的問題產生影響時，取決於檢驗和安裝一個版本的成本，可能需要忽略該版本，直接等待下個版本同時繼續測試老版本。
174）使用冒煙測試檢驗版本。
一般，在冒煙測試中包含一系列標準的核心測試，以有少量對這個版本特別重要的BUG迴歸測試或特別功能的功能測試。注意冒煙測試過程是公開的。
175）有時正確的決策是停止測試，暫停改錯，並重新設計軟件。例如：如果不管進行了多少次程序錯誤的修復，在同一位置總髮現問題，或不管對用戶界面做了多少小修改，仍存在使用戶困惑的問題，也許應該停止測試並對有關代碼進行調試，這部分內容也可能需要重新設計或重寫。
測試要向項目經理提供服務，包括好的建議。測試經理可私下單獨向項目經理進行這種說明或建議，並且要認識到有可能不能說服項目經理採取自己所推薦的行動。
176）根據實際使用的開發實踐調整自己的測試過程。
177）項目文檔是一種有趣的幻想：有用，但永遠不足。有人估計，在現代軟件項目中，超過80%的代碼用於實現錯誤處理，實現主要控制流的代碼不足20%，但即使完整的規格說明也只會用20%的篇幅描述錯誤處理。這意味着805的代碼是程序員邊編碼邊設計的。
注意：在使用規格說明時應要求提供特定補充信息以彌補這種差距。不要根據文檔完備、一致或準確的假設設計測試或規劃項目。
178）測試員除非要用規格說明書，否則不要索要。要保證項目經理和編寫該文檔的人員知道測試員要使用，並知道將如何使用，否則以後他們不會向測試員提供會給他們帶來不便的任何材料。
179）充分利用其他信息源。例如：
用戶手冊草稿、產品市場開發文獻、市場人員向管理層做的推銷產品概念的演講、程序每個新的內部版本附帶的軟件變更備忘錄、內部備忘錄、已出版的風格指南和用戶界面標準、第三方產品兼容性測試包、已出版的規定、錯誤報告、程序逆向工程的結果、與項目相關人員（如：客服、項目經理、開發小組、領域專家等）面談、所使用的所有第三方工具的規格說明和問題清單、原型以及針對原型的所有實驗室記錄、前一個版本的客戶電話記錄（在用戶現場發現了什麼問題）、針對本公司產品的問題及所使用環境或平臺上的常見問題、與同行產品進行確切比較、參考描述常見錯誤的BUGnet和其它類似網站。
180）向項目經理指出配置管理問題。如果項目在修復問題時引入新問題或使用已修復的問題又reopen的機率很大時，需向項目經理討論這個問題，並要求提出解決意見，不管原因是配置管理的問題還是不切實際的進度計劃導致錯誤修復草率。如果問題還得不到解決，在狀態報告中要說明需要高級別的迴歸測試。在一定程序上，這像是公司的一個遞歸問題，需要增加未來項目的預算，以便實現大量自動迴歸測試。
181）程序員就像龍捲風。把他們看作是一種自然力量。程序員會按照自己的方式做，而不同公司中程序員的工作方式也有很大不同，測試經理應該相應地設計自己的實踐。
注意：把測試方法建立在公司內部編程小組不會實施的實踐基礎上，是沒有意義的。
182）好的測試計劃便於後期變更。建議如下：
a不要在測試之前開發大的測試包，而是在需要測試包時再開發。
b不要編寫維護成本很高的大量測試文檔，例如：詳細手工測試腳本。應使自己的文檔儘可能簡潔。
c不要把手工或自動化測試捆綁到特定的用戶界面，除非想要專門測試該用戶界面。因爲用戶界面會變更。
d通過最大化可維護性和跨平臺可移植性來設計自動化測試。
e構建一組能夠在不同程序中重複使用的通用測試。
f構建一組很強的冒煙測試，以快速檢測被測軟件中的基本失效。
g慎重使用極限編程法開發自動化的測試。我們建議構建一種整體體系結構並設計一系列自動化測試，然後反覆設計和交付代碼。所採用方法的優先順序是：最小化測試項目風險、結對編程、與項目相關人員密切合作以確定下一步應該做什麼。
h開發一種產品用戶和用戶能通過產品獲得效益的模型。通過這種模型導出複雜測試。這類測試的大多數都不會隨項目的推進而快速變化，因爲這類測試關注的是收益，而不是實現細節。
i幫助程序員開發大的單元測試包，以及相對簡單功能的其他測試。
注意：當軟件出現後期變更時，測試經理要分析自己的測試實踐和環境條件，以確定會有哪些成本支出和效率降低，然後尋找變更自己測試過程的途徑，以降低成本或把成本分攤到整個開發週期中，而不是集中到項目後期。
183）只要交付工作產品，就會出現測試機會。只要工作產品已能夠測試，都要儘快測試。
184）做多少測試纔算夠？這方面還沒有通用的計算公式。對的測試不確定性比錯的測試確定性要好，關於多少測試算夠的好的決策，必須依靠自己的技能和判斷，不要費心尋找計算公式，還是多開動腦筋。
185）“足夠測試”意味着“有足夠的信息可供客戶做好決策”。
判斷測試是否足夠好（即，存在未發現重要問題的機會足夠少），有多種因素：
a測試員知道要發現的重要問題的種類，如果存在這種問題的話。
b測試員知道產品的不同部件如何表現出嚴重問題。
c測試員對產品做了與這些風險相應的檢查。
e測試策略具有合理的多樣化。
f測試員使用了所有可用的資源進行測試。
g測試員滿足客戶期望滿足的所有測試過程標準。
h測試員能清晰地描述測試策略、測試結果、質量評估。
如果已做到以上幾點仍在交付時存在大問題，可能原因如下：
a測試員不想按照自己想像的那樣子瞭解風險的動態。現在知道得深入一些。
b測試員在測試中出現錯誤。下一次會做得好一些。
c測試員的風險評估是正確的。但管理層決定冒風險，並造成損失。
186）不要只爲兩輪測試做出預算。因爲往往產品測試不得不進行的次數比兩次要多得多。
187）爲一組任務確定進度計劃，估計每個任務所需的時間。測試員的工作由大量任務構成，列出的任務清單中，有些只能進行一般描述，有些任務可分解得相當細。例如：對需要一天以上時間完成的任務單獨列出一項。估計每個任務會佔用的時間，然後累加起來，再加上25%的會議、培訓和其他非項目工作，並以此估計所需的總時間。
其它估算方法如下：
a用以前類似項目所需時間估算這次所需時間。
b使用當前公司將程序長度和複雜度與測試時間關聯起來的數據爲基礎的模型，則使用這種模型導出估計值。
c如果瞭解與這個項目有關的風險，則估計針對這種風險測試需要什麼，最終估計出整個產品的測試任務。
d其他因素也會影響測試員的估算。例如：程序員擅長這種應用程序開發，則他們的代碼可能需要較少的測試。
188）承擔工作的人應該告訴測試經理完成該任務需要多長時間。如果測試員的估算比測試經理的估算長得多，先不要試圖讓測試員改變估算，而是盡力理解測試員對任務範圍的看法，測試員還做了什麼，以及還有什麼因素使測試員得到看起來很高的估算。
建議：由在估算有誤時要承擔責任的人進行估算（因此有得到最好估算的動力）。
189）在測試員與開發人員間沒正確的比例。原因：
a統計誰、什麼時候開始統計、在將測試與其他工作比較時統計什麼任務這些問題上，各個公司之間是有差別的。這使得不能在公司之間做這種比例的假設。
b這種比例關注的是自身，而不是所完成的工作。例如：假設在項目中，程序員花了16個人月，測試員花24個人月，即比例24：16是精確的，但沒意義。改變新代碼與第三方代碼的代碼比例，改變重用以前項目的代碼量，改變對錯誤報告中錯誤定位的要求等其它很多可變的因素，都會使上一個項目的比例不適合當前項目。
注意：並不是不能討論比例問題，而是要討論必須做什麼工作，以及每項工作需多少人完成。
190）調整任務、不能勝任的人員。不同的測試員都有不同的強項，要鼓勵測試員承擔風險並擴展自己的能力，測試經理要儘可能提供指導，但是要關注測試員的進步。不要讓測試員承擔不適合的工作。
191）輪換測試員的測試對象。當一個測試員開始對被測試對象的質量有信心時，可把他調離當前項目，所指派新測試員很有可能會發現前一個測試員沒想過的缺陷。
192）儘量結對測試。優點：
a當一個測試員必須向另一個測試員說明自己的思想時，簡單的說明過程看起來能夠把思想更好地集中，並很自然地啓發更多的思想。
b有助於兩個測試員始終關注任務，更容易重現和分析程序錯誤，並使一個測試員進行工作，而另一個測試員應付中間插入的情況，或離開主任務以抓住所需的東西。即其它人用小問題打擾他們的可能性更小。
c結對測試與單獨測試的效率至少一樣。結對測試可以在更短的時間內完成更多的工作。
建議：在開始測試前，每組結對測試的成員要先有個約定，大概花5～10分鐘時間考慮接下來的一兩個小時的工作方向。例如：可以關注要調查的風險、要測試的功能、或使用的工具。這只是一個總體指南。在進行一段時間後，應檢查一下約定，以確定下一步該做什麼。
193）爲項目指派一位問題查找高手。問題查找高手是經驗豐富、熱心探索的測試員。使用“問題查找高手”的方式如下：
a對有懷疑的部分進行初步探索式測試，形成更細緻的想法，接着讓經驗不足的測試員執行。
b探索被認爲是風險很低的部分，--問題查找高手能夠快速找到導致重新評估風險的程序錯誤嗎？
c定位看起來很容易引起不可重現問題的關鍵部分。
d找出關鍵程序錯誤，以說服項目經理推遲（不成熟的）發佈日期。
194）確定測試的階段計劃，特別是探索式測試的階段計劃。
階段計劃：測試員清楚地知道自己在接下來的60～90分鐘內要做什麼。這種方法有助於測試員集中注意力，但並不鎖定在這種計劃上，如果發現值得懷疑的現象或有了很好的想法，測試員可隨時按新思路進行；如果沒明顯更有吸引力或更大壓力的事情，則應該回到原定的計劃上來。
195）分階段測試。一個階段是一個不受干擾的時間塊，長度爲60～90分鐘。在一個階段中，測試員要進行專題測試，測試經理應保護這個階段的完整性——可在測試員的隔板外掛上所有人（包括測試經理本人），都應該尊重的“請勿打擾”牌子，除非有嚴重問題需要緊急解決。
196）通過活動日誌來反映對測試員工作的干擾。
197）定期的狀態報告，是一個強有力的工具。測試小組的真正力量來自溝通，不是監管。狀態報告是傳遞自己信息的很有用的工具，編寫狀態報告時需注意：
a永遠使用中性、客觀的語氣，不要使用感嘆號、全大寫詞彙或幽默。
b不要針對具體的某人。注意：對事不對人。
c採用所有項目都一致的格式。
d按照標準進度計劃提交報告。對所有項目都要採用一樣的報告頻率。例如：項目早期，狀態報告的頻度可以是每兩週一次，以後後是每週一次，項目接近結束時是每天一次。
e仔細地選定狀態報告的內容。狀態報告要簡練，要在幾頁紙中包含大量信息。
f要把狀態報告提交給項目相關人員及項目團隊之外的人。---這一點要慎重考慮，要視公司文化氛圍及責任而定。
198）再也沒有比副總裁掌握統計數據更危險的了。在報告狀態（度量）時，應知道自己在統計什麼數據及這些數據給誰看。測試經理應清楚度量的條件背景，有效地利用它。謹慎地給不知道條件背景的高層經理提供數據，可預測會帶來的誤解並直接提出問題，並拒絕提供某些數據。例如：
a不要跑到高層經理的辦公室，抱怨某個程序員修復BUG的時間遠遠大於平均水平。如果測試經理主動提供了根據BUG管理系統得出的個人表現數據，以後會被要求大量提供這種信息。
b如果提供的信息中提到“到交付至少需要5周”，因爲還有200個BUG未修復，而開發修復BUG的速度是40個/周。此時應在數學旁加上註釋。因爲其它項目因素比BUG數量對確定交付時間的影響更大。
c當被要求提供個人統計數據（例如：每個測試員發現的BUG數）時，可拒絕並向其解釋，這種做法帶的反效應。
199）要小心通過程序錯誤數度量項目進展。BUG數是一種試題項目進展的不錯參數，但BUG數是不充分的，並常常產生誤導。
BUG數可以用來說明項目離發佈時期還很遠；但BUG數不能用來說明產品已經接近發佈時所要求的質量。因爲如果到了項目的最後階段，未解決的BUG數已經降低到接近要求的水平，這意味着產品更穩定，還是測試小組花了太多時間編寫錯誤報告、運行迴歸測試（導致很少發現新的BUG），以及不直接導致發現新BUG的其它活動等。這些僅從BUG數中不能得到這些問題的答案。
--200）使用的覆蓋率度量越獨立，瞭解的信息越多。
覆蓋率試題涉及給定類型可能的測試總集合、計劃運行的測試集合、實際運行的測試集體。可以把已執行的測試數與計劃執行的測試數的比值作爲覆蓋率度量，也可以把已經執行的測試數與有意義的測試總數的比值做爲覆蓋率試題。兩種比值都很有用。覆蓋率度量都只限於一類因素，不管是所執行的代碼行、配置、經典風險等。所以每類可能的失效都會對應一種因素。
201）利用綜合計分牌需考慮多個因素的狀態報告。綜合計分牌常常用於度量企業是否健康發展。多個不同的數字看起來可以比較好地說明企業的狀態，但任何一個數字孤立地看都很容易產生嚴重的副作用。項目進展度量也應涉及多個不同的因素。例如：
a產品已完成了多少測試？
b計劃進行的測試已完成了多少？
c發現了多少問題？其中有多少問題還沒解決?
d我對測試質量有多大把握。（例如：如果beta測試員發現很明顯的問題，那麼對質量的把握就比較低。）
e出於未解決缺陷，或缺乏設備，或沒做出決策，有多少測試工作受到阻礙？
202）以下是周狀態報告的推薦結構。
可以把狀態報告看作四頁長的文檔。
第一頁列出關鍵問題，例如：所需的決策（例如：應該如何確定這些功能的優先級？測試什麼設備？是否吸收新測試小組成員？）；所需的程序錯誤修改（對測試工作產生影響的所有程序錯誤，都應該優先解決。）；預期的交付件以及承諾的交付日期（在截止日期之前一點就要把這些交付件列在清單上，過期沒交付的交付件要留在清單上，刪除已提交的交付件，這種清單是表示遺漏的東西而不是累積工作表，應突出阻礙工作進展的因素）；意外問題（例如：某種關鍵工具沒預想那麼好用，員工跳槽等）。
第二頁描述測試小組完成計劃任務進展的情況。例如：不同測試工作進度計劃，每項測試工作的預算，每項測試任務的完成情況，每項測試工作使用的時間。
第三頁提供錯誤報告統計數字。
第四頁列出本週推遲修復的BUG。清單可以只包括BUG數、總計（或標題）行，及測試員爲該BUG劃定的嚴重程度。需要更多的信息，讀者可進一步查找。
203）項目進展表是另一種展示狀態的有用方法。進展表是一種圖表，畫在會議室的白板上，向項目團隊所有成員和與該項目有關的任何人公開。典型的進展表會列出多個工作區，每個工作區對應一行。對於每個工作區，白板顯示當前工作量水平、計劃覆蓋率、已達到的覆蓋率、測試員對質量評估（分爲高、中、低）、測試員能夠補充一些關鍵註釋，以便進行評估。
典型的進展表每週更新一次（在項目初期），當項目接近尾聲時，可增至每天1～2次。進展表提供的信息要足夠新，使經過的經理也希望看一看。
204）如果里程碑定義得很好，里程碑報告很有用。如果公司要在每個里程碑處評估產品，那麼測試經理需要知道應對照什麼進行評估。公司怎樣定義里程碑？產品需要與里程碑定義中的哪些方面進行比較？如果沒有可用的里程碑，建議把里程碑看作是一個項目迭代的完成，需明確這個迭代退出的準則是什麼？可下一個迭代進入的準則是什麼？
205）不要簽署批准產品的發佈。要讓項目經理或項目團隊確定什麼時候發佈產品。測試經理的工作是使項目經理能夠得到可以做出這種決策的最好的數據。
206）不要簽字承認產品經過測試達到測試經理的滿意程度。如果有人堅持要測試經理簽署產品發佈表，需聲明自己的簽字只說明產品已經過充分測試，已完成了約定程度的測試，或測試小組在可用的時間內盡力做了最好的測試。
207）如果測試經理要編寫產品發佈報告，應描述測試工作和結果，而不是自己對產品的看法。測試小組對產品的整體質量或產品對目標市場的適合性做出評估是非常困難的。因爲測試經理並沒有相關的數據，他只掌握錯誤報告和測試覆蓋點。
注意：測試經理應只描述自己所知道的東西。
208）在產品最終發佈報告中列出沒有修復的程序錯誤。如果測試經理準備（或幫助準備）產品最終發佈報告，應該附上沒修復的BUG清單。還應在清單中列出認爲重要而被拒絕的設計問題。這份清單應事先傳閱，以免大家在最終報告纔看到這份清單而感到意外。
209）有用的發佈報告應列出批評都可能指出的10個最糟糕的問題。
測試小組的管理：
210）平庸是一種保守期望。如果認爲在自己的公司內不會出現英雄，就不會得到英雄。
211）要把自己的員工當作執行經理。執行經理就是管理自己的時間以及影響機構發揮作用的人。
其實大多數腦力勞動者（例如測試員）都是執行經理，人們交給執行經理的工作量，總是比其所能夠完成的要多。有效的執行經理會挑出自己能夠完成好的那一部分任務子集，並完全不考慮其他任務；低效的執行經理總是試圖做所有的事，總是不成功，特別是不能取得自己所努力爭取的結果。
我們對待測試員不要像對工廠工人那樣發號施令，管理測試小組時要錄用具有不同經歷和背景的員工，且要更多關注新測試員。我們的目標是產生執行經理，並從一開始就要表現出對其學習、思考的尊重；我們期望他們能夠迅速擔起責任，表現出工作熱情，建立自己的信譽，發展自己的技能。
212）閱讀自己員工完成的錯誤報告。這樣有助於測試經理了解產品情況、自己員工的強項和品德及影響自己員工的溝通和人際問題。針對員工的錯誤報告，可以用如下提問來評估員工的工作質量：
a這些報告寫得好嗎？
b報告直率地提出了問題嗎？
--c報告留下迫切要求後續測試的漏洞了嗎？
d發現程序錯誤的測試看起來是例行公事還是很有見地？
e程序錯誤很難發現嗎？程序錯誤出現在應用程序一般比穩定的部分嗎？如果是，這反映出測試員的堅韌性還是好運氣？
f報告的語氣怎麼樣？
g程序員能理解報告嗎？程序員對報告有什麼反饋意見？這反映出程序員和測試良好的協作？還是相互指責？
213）像評估執行經理那樣評估測試員。
注意：BUG數頂多就是測試員工作有效性的沒價值的度量，它會使測試經理產生誤導。我們建議評價員工工作時可以通過：閱讀錯誤報告；閱讀其編寫的代碼；閱讀其編寫的測試文檔；收集與其一起工作的程序員及其它相關人員的意見。需考慮如下因素：
a他捲入了什麼爭端，爲什麼？
b在按期完成任務方面做得怎麼樣？
c在信守自己的諾言方面做得怎麼樣？
d他遺漏了什麼類型的問題？
e他對其他測試員或程序員提供了什麼類型的幫助，以提高他們的工作效率？
f他在學習新技能嗎？他在把自己的技能傳授給其他測試員方面做得怎麼樣？
g他站在公司的立場上處理過什麼問題？這些在其對公司業務的判斷和個人道德上是如何體現的？
另，測試經理可把員工的自我評估當作正式評估的一部分參考依據，但不能太過依賴自我評估。且正式評估的頻度不能太低：每半年或一年進行一次。
214）如果測試經理確實想知道實際情況，可與員工一起測試。
測試經理參加項目團隊可能並不實際，但可對自己的時間劃分優先級，可仔細考慮至少積極地參加一個項目團隊的可能性，這項工作很重要，值得給出較高優先級。
因爲如果測試經理不參加項目團隊的測試工作，一段時間後可能就會喪失自己的很多技術能力，就不能看到測試員正在處理的真正問題，且很難評估測試員工作的質量。
215）不要指望別人能夠高效處理多個項目。注意：
a有些人會接受多項任務，但在特定的一週（一個月）內，他們只能承擔其中一項，而其它任務會被拋在一邊。
b積極地承擔所有任務的測試員會把時間分得太碎，要在管理方面花很多時間。最終測試經理使某個測試員參與多個項目，參加很多會議，花大量時間瞭解各個項目，而對任何一個項目所做的實際測試都很少。
216）積累自己員工的專業領域知識。領域知識包括：用戶如何使用類似的產品、什麼俗人問題對他們很重要、同行如何解決這些問題等
通過如下途徑可積累真正的專業領域知識：
a閱讀面向類似產品客戶的雜誌和書籍。
b參加客戶如何使用類似產品的培訓。
c參加與產品的下層主題有關的培訓。
d在客戶現場工作。
e推銷自己公司的產品或同行的產品。利用週六日到零售商推銷軟件，掌握了產品市場的很多信息。
f每週利用幾個小時解答公司技術支持需處理的熱線電話。
217）積累自己員工相關技術方面的專門知識。
218）積極提高技能。對於強化測試小組在公司中的價值極有幫助。
219）瀏覽技術支持日誌。爲了理解軟件安裝後正常運行時出現的問題，應閱讀公司的客戶投訴記錄，思考爲了使某類投訴減少自己可以做些什麼；如果有這樣的問題，思考什麼類型的測試會有助於發現被測軟件中類似的一般問題。
220）幫助新測試員獲得成功。實施步驟如下：
a爲新測試員找好地方，並在他上班前安排好（例如：提供計算機等硬件軟件及必要的公司項目文檔）。
b至少要安排一天的時間讓新測試員與有關人員見面，帶他參觀公司部門，向他介紹將在一起工作的每一個同事，通過面談瞭解他的希望和預期。
c爲新測試員指派一位指導者。指導者要帶新測試員各處參觀，並回答各種問題，檢查新測試員所完成的工作並提出建議，午餐請幾次客，這些都很有幫助。注意：指導者並不是新測試員的上級，並不向測試經理報告有關新測試員的任何事，除非是很重要的問題。
221）讓新測試員對照軟件覈對文檔。即，新測試員運行軟件覈對用戶手冊或在線幫助，這樣能讓他了解程序的所有部分。
222）通過正面測試使新測試員熟悉產品。當新測試員覈對完用戶文檔，已理解產品應該提供什麼功能後，應嘗試以簡單且實際的方式使用該產品，並列出使用類似的產品有可能做的事然後使用被測試產品，嘗試簡單地照樣做。
223）讓初次接觸測試的員工在編寫新錯誤報告前，先改寫老的錯誤報告。
224）讓新測試員在測試新程序前，先重新測試老的程序錯誤。例如：重現仍未關閉的BUG；重新測試已解決的BUG；重新測試已解決但還沒關閉的程序錯誤。
225）不要派測試新手參加幾乎完成的項目。因爲要花費大量時間編寫詳細的測試步驟等文檔供測試新手使用，且測試新手使用這些文檔會遺漏大量程序錯誤。
226）員工的士氣是一種重要資產。Napoleon指出“三分士氣一分體力”。如何營造提升員工士氣的氛圍，具體如下：
a禮貌地對待員工，尊重員工。
b關注他們的工作。
c稱讚好的工作、熱心和誠實努力。
d如果員工加班，測試經理也要加班。不一定要每晚，不一定每個週末，但要足夠經常，使得員工可以感到測試經理在觀察他們加班的情況。
e如果可能，爲員工指派他們感興趣的任務和項目。鼓勵他們說出自己的興趣，並給予考慮。
f如果測試員任務完成得不順利，可指派別人給予幫助、指導，如果有必要還可以考慮替換。
g提供培訓機會。表現出測試經理很看重技能和專業背景。
h測試經理要公平對待員工，並要求別人也公平對待他們。
j不要對任何一位員工產生誤導。如果測試經理不知道問題答案，就實話實說。
k不要對員工叫喊，不要利用自己的權力強制要別人接受自己的觀點。
l避免公開批評員工，但必須在私下指出其錯誤和問題。
m不要與員工私下議論其他小組內的員工。
n測試經理不要與員工約會。並在接受員工個人提供的方便或禮物時應特別小心，即使是小禮物。給的東西往往要多於接受的東西。
227）測試經理不要讓自己被濫用。注意：
a不要做自己做不了的事。很多經理不管員工已多努力工作，都按慣例試圖爲每位員工再增加10%～20%的工作。測試經理對於自己做不到的，不要陷入責任圈套，不要爲了過度工作而搞垮自己和整個團隊。
b軟件開發並不總是朝九晚五的工作。有時項目經理需要測試經理幫助時，如果測試經理能提供幫助，一定要想方設法儘量提供。但測試經理應該支持自己的小組，要選擇自己的節奏，並做出自己的承諾。記住此時測試經理是志願者，而不是犧牲者。
c測試經理不要承諾不可能做到的事，在這樣的事上不必說謊，更不必掩蓋問題。事實上，測試員工作的本質就是暴露問題，而不是將其掩蓋起來。不必，也永遠不應該在誠實上讓步。測試經理的力量來自於向需要了解真相的人說明真相，如果在誠實上讓步，就會使自己力量的一個核心支柱弱化。
228）不要隨意讓員工加班。長期加班會使員工體力透支、跳槽率升高、不信任別人、關係複雜、低效、工作草率，所以強烈建議測試經理要避免讓測試員長期加班。
如下措施，可避免讓測試員長期加班：
a在制定項目進度計劃時，不要指望員工能夠每天都8個小時集中在工作上。如果幸運的話，測試員可每天有6個小時專心辦公室工作，其餘時間用於完成其他必須做的工作（例如：參加會議、培訓、填寫人力資源要求的表格等）。
b不要同意自己知道的不現實的進度計劃，要儘可能準確估算完成不同任務需要多少時間。面對比自己估算時間短的進度計劃時，應該問清楚首先要完成哪些任務，哪些任務在時間有剩餘時才完成。如果項目經理堅持要求完成所有工作，則要問題清楚哪些任務可以完成得不那麼全面，並要求提供更多人手。面對不聽別人說明理由的項目經理，測試經理要明智地管理好自己的員工，否則會失去他們。
項目經理獎勵加班的人，認爲加班得多的人完成的工作更多、更好。測試經理的挑戰是找出一種方法，使更有效率的員工的工作效果能夠展現出來。
229）不要讓員工被濫用。
一方面，如果別人不善待測試員，也許測試經理該給員工做一些規定，爲員工提供精神支持，並解決各種不公正待遇。另一方面，如果測試員說出不恰當的話或做出不恰當的事時，管理上應禮貌地處理表現不當的測試員，私下向測試員明確說明這樣的表現是不能接受的。
230）創造培訓機會。例如：
a成立閱讀小組。每週一次或每月兩次。目標是閱讀一篇論文或專著中的章節並進行討論（測試員討論，測試經理參加但不要說很多話），這樣的活動要體現自願原則，所有人都不是被迫參加的。但要尋找某種方法獎勵經常參加活動並積極發言的人。
b召開午餐培訓會議。每週一次或每月兩次。有時測試經理要講話；有時邀請其它公司的測試經理或領域專家演講；有時某位員工可以介紹一種技術可測試某個功能時所遇到的挑戰。
c如果公司統一安排培訓，可搞清楚當地大學提供什麼相關課程，有什麼更好的與軟件有關的在線課程。測試經理不要告訴別人該選什麼課，但要指出自己認爲教得較好並與公司當前項目相關的，或對員工職業發展有益的課程。一般派出兩人或三人蔘加課程和會議，以便能討論所學到的內容，回來後，要向測試小組報告所學的內容。
231）錄用決策是最重要的決策。
--232）在招募期間利用承包人爭取回旋餘地。
233）謹慎把其他小組拒絕的人吸收到測試小組中。因爲更多的人頭數會影響下一次請求批准新員工的錄用，周圍的人也會認爲測試小組的能力應與員工人數成比例增加，測試員增加會招來新工作，如果有了新工作，而新的測試員又不能承擔，只會增加小組其他人的工作負擔。
234）對測試小組需要承擔的任務，以及完成這些任務所需的技能做出規劃。
235）測試團隊成員要有不同背景。
236）錄用其他渠道的應聘者。在非傳統場合尋找測試員，尤其是在人力市場很緊張的時期。例如：律師和會計他們有很強的分析技能；剛當上母親的高級程序員或項目經理需要放慢其工作節奏等。
237）根據大家意見決定錄用。讓測試小組中的任何全職員工及與測試小組工作關係密切的任何人測試候選人面談。所有參加面談的人都可以否決候選人，測試經理應細心、投入地傾聽員工所描述的觀點，並尊重員工的否決決定，除非員工的否決有歧視問題。
238）錄用熱愛自己工作的人。謹慎錄用對其過去的工作不滿的人。
239）錄用正直的人。測試人員的價格會影響客戶的信任程度。
240）在面試時，讓應聘者展示僱傭者所期望有的技能。通過應聘者詢問的問題、所進行的查詢以及把各部分信息綜合爲整體方法的方式，對其做出判斷。
241）在面談時，請應聘通過非正式能力測驗展示其在工作中能夠運用的技能。有些測試小組確實通過邏輯或數字腦筋急轉彎迷題，來實行某種非正式的能力測驗。我們並不反對這樣做，不過我們認爲這樣做並不像有些人想像的那樣能夠說明問題，因爲對於邏輯和數字腦筋急轉彎迷題，通過做大量實際練習會提高其更好地解答腦筋急轉彎迷題。
242）在錄用時，要求應聘者提供工作樣本。例如：自己編寫的代碼樣本、起草的錯誤報告、論文或報告。永遠不要要求提供機密材料，並保證應聘者提供的材料是非保密。
243）一旦拿定主意就迅速錄用。
244）要將錄用承諾形成文字，並遵守諾言。永遠不要承諾超出自己職權的事，例如：職業發展或提升等。
軟件測試職業發展
245）確定職業發展方向並不懈努力。測試方面職業發展的兩個一般方向是：技術和管理。
技術方向的測試包括：自動化測試結構分析員、自動化測試程序員、性能和可伸縮測試員、系統分析員、用戶界面和人員因素分析員和鑑定員、測試計劃設計員、專題測試專家、黑盒測試員。
測試員通過學習範圍相當寬的測試技術，並用領域知識加以補充，會使自己對當前僱主的價值得到提高，這樣的測試員可以要求明顯更高的工資。一條很實用的指導原則是，確定僱主（或行業）最需要的技能，並努力掌握這種技能。
管理方向的測試包括：測試小組組長、測試經理、測試主任或質量主任、內部顧問、外部顧問。
與程序員相比，測試員對產品有更廣、一般來說更淺的認識，並往往對整個產品有興趣、有影響力。結果很多熟練的測試負責人得到培訓並調到其他管理崗位機會：程序設計經理或項目經理、技術支持經理、產品經理、文檔編寫小組經理、銷售支持經理。
測試員的另一個發展方向是過程管理人員，包括：軟件指標專門人員、軟件過程改進專門人員。建議在向過程管理方向發展時應該小心，因爲這些崗位沒直接捆綁到任何產品的開發和收益上，可能更容易受到裁員的影響。
246）測試員的收入可以超過程序員的收入。具有專門技術特長的測試員比具有管理技能的測試員更受重視，而管理技能的測試員比黑盒測試員更受重視。
247）可大膽改變職業發展方向並追求其他目標。例如：如果想轉型爲程序設計員，在逐漸掌握了有關程序設計語言的基本技能之後，可向程序設計小組提出用自己業餘時間承擔一部分工作。
248）不管選擇走哪條路、都要積極追求。
職業發展方向是自己的事。應認真考慮自己的職業發展方向問題，搞清楚自己需要什麼，自己對什麼感興趣，這會使自己更有價值。
249）超出軟件測試拓展自己的職業發展方向。
花大量時間尋找並批評其他人的錯誤會變得俗套，嘗試做一些其他工作，掌握一些軟件開發的其他技能，這會使自己見識更廣、更靈活、更適合就業市場的需要、對項目團隊所面臨的挑戰和約束會更有見地。與只承擔過一項任務的經理相比，能夠發揮多種作用的經理常常難獲得更高報酬。
250）跨越公司拓展自己的職業發展方向。職業發展方向是自己的事，即使公司明天出現問題，自己的職業發展方向仍然還是原來的方向。軟件測試員羣體很大，我們可以通過不同的方式參加這個羣體。例如：出席軟件測試或軟件開發會議、參加當地的計算機學會、美國質量學會等。
251）參加會議是爲了討論。
a參加有關軟件測試或軟件開發的會議時，不要只是坐在分組討論會場中聽別人發言，應該參加很多分組討論，但還要花很多時間與參加會議的其他人見面，討論所做的發言或本領域中的一些問題。
b如果不認識很多與會人員，午餐時，與不認識的人坐在一起，聽其談話，尋找有興趣且有見地的人。
c在與這些人見面時，詢問他們的工作內容，瞭解他們在會上所討論的內容。他們發現了什麼重要的東西？
d經過一段時間後，就會結交一些在會議上見面的朋友，通過網絡與他們交流最新信息。
252）很多公司的問題並不比本公司的問題少。與其他公司的測試員建立聯繫，有助於自己的未來發展。
253）如果不喜歡自己的公司，就再找一份不同的工作。當前有工作幾乎總比當前沒工作更容易找到好工作。但如果現在的工作環境如此惡劣以至於影響自己對自己的看法，以及面談時對自己的描述那麼最好還是離職，休息一段時間，如果可能，可參加夜校給自己充電，使自己處於很好的精神狀態，以便更有效的爲下一個潛在僱主工作。
254）爲尋找新工作做好準備。例如：準備最新的簡歷、與一些很好的招募人員有不錯的關係、知道有哪些類型的招聘崗位、有哪些公司要招聘及其待遇等。
255）積累並維護希望加入的公司的名單。收集自己希望加入的公司信息，特別是通過網絡、會議和關係，與在那些公司中工作的人見面、交談
256）積累材料。積累能夠證明自己能力的一些代碼、文檔或其他的工作樣本，可利用這些材料顯示出其他應聘者不具備的能力。獲取這些資料的最好時機是：
a在裁員涉及到自己時，經理或人力資源的代表會解釋裁員條件。如果自己手中有特定的工作樣品，他們會樂意簽署文件，允許員工向可能的僱主或客戶出示這些樣本，以便獲得工作。
b離開公司半年到一年後，如果自己的前老闆還在原公司，則這個問題比較好處理。
c在會議上用作例子。
257）把簡歷當作推銷工具。目標是寫出針對恰當市場的簡歷。
a如果對有顯者不同的工作崗位感興趣，則寫出不同的簡歷。要突出最能夠說明自己的技能、興趣和背景。注意：要保證自己不同簡歷的有關背景和成就的描述是一致的。
b準備一份歷史簡歷。歷史簡歷要以時間順序描述自己的工作經歷，突出介紹在每個工作中取得的成就。
c準備一份功能性或關鍵詞簡歷。
d決不要誇大自己的背景、技能或經驗。誠信是自己的主要資產。
258）找一位內部推薦人。
259）蒐集薪金數據。通過www.salary.com這樣的網站，可查詢到現實的薪金預期值，瞭解這些信息，更好地準備面談。
260）如果是根據招聘廣告應聘，應根據廣告要求調整自己的申請。明確指出招聘廣告多項要求中自己已滿足的條目及還不滿足但很希望學習的條目。
261）充分利用面談機會。當應聘者接到不太感興趣的工作面談機會，應考慮接受這種面談，並以確實想要應聘工作的同樣熱情準備面談。因爲這種面談也是一個實踐自己面談技能的機會。
262）瞭解準備應聘的招聘公司。如果招聘公司爲電，要求進行電話交談，可向其索取以下信息：
a索取產品材料或公司介紹材料。
b索取他們發行的軟件演示版，或詢問公司所使用的開發和軟件測試工具。詢問公司所開發的應用程序類型。
c詢問從哪裏可以找到有關該公司的其他信息。
注意：如果公司寄來一些材料，一定要在面談前看完。
263）在應聘時詢問問題。應針對不同類型的人挑選不同的問題，如下是沉澱產生有意義回答的問題，例如：
貴公司提供什麼產品和服務？
我可以看一下關鍵產品的演示嗎？
貴公司提供的產品和服務有什麼特別之處？有哪些主要優點和弱點。
貴公司如何開發主要產品？有些什麼關鍵的開發綜合考慮？
貴公司的客戶、競爭對手有哪些？
貴公司如何瞭解自己的客戶或如何瞭解自己的客戶對整個產品、設計和缺陷的滿意程度？
請描述貴公司的組織圖（你們在什麼位置、我將在什麼位置）。
貴公司的工作情況怎樣？
你的工作是什麼？你提供什麼產品和服務？
你在產品開發過程處於什麼位置？
你對你的工作有什麼看法？
你想做一些改變嗎？
你怎樣安排時間與家人待在一起？
你對自己的工作有多大的控制力度？
誰來設計你所運行的測試？誰來運行你所設計的測試？
請談談你們的測試設計過程。
我可以看看一些測試計劃和測試用例嗎？
你對自己的待遇、老闆、同事有什麼看法？
去年你聽過哪些課，出席過哪些會議？
你還接受過什麼其他培訓？
你怎樣學習新技術？
請描述去年你所學到的三種關鍵技術。
在面談時，要集中注意力看着對方，認真地聽。從而獲取如下信息：
a面談者累了嗎？
b面談者和其他人對他們自己工作的看法是肯定的嗎？
c他們是否有很好的士氣和團隊精神？
e他們的辦公設備如何？他們在提高工程技術人員的環境舒適度和生產率方面的投資有多大？員工的辦公設備與經理的辦公設備有多大不同？
e測試員佔用多大的工作面積，設備和照明，更高層人員佔有多少?
f尋找所聲稱的工作條件和實際工作條件的差別。例如：工作時間。
264）就自己的工作崗位進行談判。談判是一種技能，必須實踐。在談判期間得到的信息越多，談判就越有效。關鍵的信息例如：知道自己想要什麼；知道他們想要什麼；知道他們的想法；知道他們作爲潛在僱主怎樣談判；知道自己的其他選擇。
以下是談判期間會出現並應該考慮的問題：
a在會談初期，要講清楚自己想要什麼（非報酬方面）以及自己對什麼感興趣。
b應聘者應拒絕提供以前的報酬信息，在僱主對自己感興趣前，婉轉地拒絕回答有關報酬期望方面的詢問。
c應熱心，但不要過於迫切。
d應使用他們的詞彙討論他們的產品。
e應聘者應該發現並指出自己能夠爲招聘公司提供幫助的方面，提出建議，給出自己想法的例子。
f應聘者要讓招聘公司知道自己想要哪份工作。
g如果應聘者沒完全達到該工作崗位的要求，但是又想得到這份工作，可作爲一種拓展機會坦率提出來，讓招聘公司知道自己多麼想得到這份工作，這份工作多麼適合自己的興趣和發展目標，及自己在該崗位上施展才華。
h當心潛在僱主員工帶有威脅味道的談判風格。
請注意：在談話和談判時，公司經理都會極爲檢點。一旦錄用後，他們不會更友善，不會減緩威脅口吻，不會更誠實，也不會更爲員工着想了。
--265）留意人力資源部。要與決策者談話，而不是與人力資源部談話。
266）學習Perl語言。或使用公司指定的腳本語言如：Python、Ruby。
267）學習Java或C++。積極運用所學到的知識，例如編寫自己的測試工具，來學習本公司使用主要開發語言，並在實踐中運用。
268）下載測試工具的演示版並試行運行。建議：熟悉本公司沒有使用的工具。
269）提高自己的寫作技巧。可通輯有關技術和勸導寫作方面的課程，並尋找其他途徑實踐來提高自己的寫作技巧。
270）提高自己的公衆講話技巧。
271）考慮通過認證。認證或許可以在應聘簡歷中很有用，但不要通過認證就以爲自己是專家。
272）不要幻想只需兩個星期就能夠得到黑帶柔道段位。很多人對認證很感興趣，但這與要成爲成功的工程師沒多大關係。
--273）有關軟件工程師認可制度的警告。
計劃測試策略：
--274）有關測試策略要問的三個基本問題是“爲什麼擔心”、“誰關心”、“測試多少？”。
275）有很多種可能的測試策略。以下是三種不同的測試策略：
a我們經過簡單內部評審，找出所有特別明顯的問題後，將產品發給友好的用戶。讓這部分用戶實際使用產品並告知我們需做哪些方面的修改。
b我們定義以用戶與產品交互動作序列表示的測試用例，這些測試用例合在一起，代表預期一般用戶使用產品的各種方法。還在此基礎上補充壓力測試和異常使用測試。首先要做的，是發現對比特定行爲的基本偏差，並關注該程序與用戶期望衝突的方式。還要考慮可靠性，但我們還沒確定如何最有效地評估可靠性。
c我們執行並行探索式測試，開發和執行自動化迴歸測試。探索式測試是基於風險的，並根據需要按覆蓋區域分配，我們每週都要重新檢查分配情況。自動化迴歸測試關注基本功能的檢驗，以提供涉及主要功能失效的早期報警系統。我們還注意利用大量隨機測試的機會。
請注意，每種策略都有不同的重點，都說明將如何進行測試。好的測試策略會給出要完成測試的令人信服的描述和論證。
276）實際測試計劃是指導測試過程的一套想法。這種想法很重要。是否記錄及怎樣記錄這些想法則完全是另一個問題。請不要把測試計劃與溝通管理該計劃的方式混淆起來。
277）所設計的測試計劃要符合自己的具體情況。Satisfice語境模型，五角形各個角上的圓圈表示測試小組的具體條件：資源與約束，這五個圓圈分別代表：開發、任務、需求、測試實驗室、測試團隊。五角形的中央表示測試小組的選擇。測試計劃的目標是所選的測試過程能夠使測試控制在項目環境中，同時又能充分利用資源，完成自己的任務。
給定五種資源和約束具體是：
a開發。產生將要測試的產品系統。如何接收該產品？該產品的可測試性如何？
b需求。成功產品的評判準則。該產品的風險是什麼？有關質量誰的意見最重要？
c測試團隊。能夠投入該產品測試的人員。有合適的人選嗎？能夠及時完成任務嗎？
d測試實驗室。使測試團隊能夠完成測試任務的系統、工具和材料。有合適的設備嗎？程序錯誤跟蹤系統的狀態是否良好？
e任務。測試團隊必須要按照客戶認可的成功標準分配任務。快速找出重要問題？對質量做好準確評估。
注意：測試小組的控制能力在於如何應對這些資源和約束：自己要有什麼樣的測試策略、保障條件和工作產品。
278）利用測試計劃描述在測試策略、保障條件和工作產品上所做的選擇。
好的測試計劃，不管是不是書面的，都要描述有關測試過程的一套選擇。測試計劃必須描述三類選擇：
a策略。如何測試產品以快速找出重要問題？需要對哪些部分進行特殊測試？要運用什麼手段創建測試？當程序錯誤出現時怎樣識別？測試策略要規定測試項目與測試任務之間的關係。
b保障條件。如何利用資源實現測試策略？誰來測試？什麼時候測試？要想成功需要什麼條件？
c工作。怎樣向客戶提供工作產品？如何跟蹤程序錯誤？需要編寫什麼測試文檔？需要編寫什麼報告？
279）不要讓保障條件和工作產品影響實現測試策略。即，測試策略常常被測試計劃其他部分掩蓋。例如：有些測試計劃文檔詳細給出進度計劃、團隊及交付件等信息，但幾乎沒談如何測試該產品。
280）如何利用測試用例。討論測試用例的內容，即討論風險和覆蓋率，否則不要利用測試用例統計信息，因爲知道得很少但是正視現實比知道得很少假裝知道得很多要好得多。
注意：測試用例就像箱子，只統計箱子個數而不管其中的內容是沒意義的。僅統計測試用例的通過與未通過比例說明不了任何問題，僅統計已實現/計劃實現的測試用例比例也說明不了問題，因爲也許最困難的測試用例被推到最後，最後10%的測試用例需要50%的時間完成，也許所計劃的測試用例數還根本不足以覆蓋重要的風險。
281）測試策略要比測試用例重要。因爲測試策略包含測試用例執行背後的理由，即它時總結產生測試用例的手段和目標概述。
282）測試策略要解釋測試。好的測試策略是：
a與具體產品有關。
b關注風險。顯示測試過程可以怎樣描述重要問題。將測試過程與這個項目的任務關聯起來。
c多樣化。多樣化測試策略要包含各種不同的測試手段或方法，逃脫一種測試方法的問題還可能被另一種方法捕獲。
d實用。測試策略必須能被執行。不要提出遠超出項目團隊能力的測試策略。
283）運用多樣化的折衷手段。執行達到相當水平的多種不同測試，要優於完美地執行一兩種測試，我們把這種原則叫做“多樣化折衷手段”。這個原則來源於軟件產品的結構複雜性。
284）充分利用強有力測試策略的原始材料。測試策略可利用的資源，例如：
a測試員運用各種測試手段的技能。
b測試員有關產品內部技術的知識。
c具有特殊測試或工藝技能的朋友。
d原始測試數據庫。
e各種測試平臺，包括多種操作系統和硬件配置。
f各種測試工具。
g實際用戶數據。
h植入產品中的可測試性功能（例如：日誌記錄文件、判斷和測試菜單。）
285）項目的初始測試策略總是錯的。
隨着對被測試產品及其失效模式認識的不斷深入，測試策略也應更新，應避免過早固定一種且只有一種測試策略，建議要根據風險確定測試策略。
286）在項目的每個階段，可自問“我現在可以測試什麼，怎樣才能測試好？”。
測試策略要考慮進行測試的項目開發階段以及測試結構層次（單元、子系統或系統），但並不是決定性的考慮因素。不要認爲特定手段只是在一定的開發階段纔是有用的。要使自己的測試策略能夠抓住更多的機會。在任何時候，測試任何值得測試的東西，使用任何能夠最好地滿足客戶要求的手段。
287）根據產品的成熟度確定測試策略。總體目標是隨着產品開發的進展，不斷調整測試策略，使得在產品開發整個過程中，重要錯誤的發現率都保持比較高的水平。
測試策略分四4個階段：
a項目初期，同情地測試。在這個階段不必進行深入的測試，因爲簡單的測試也會發現問題，程序員想知道的是剛剛實現的功能是否基本上能夠運行。
b項目中期，積極地測試。在這個階段需更嚴格、更復雜的測試，層層深入測試產品的各個部分，儘可能多地發現並報告錯誤。因爲此時產品逐漸成型，主要功能已實現，簡單測試已沒什麼作用。
c項目末期，多樣地測試。在這個階段可充分發揮自己的想像力和管理層所提供的支持，推行多樣化測試，因爲找出成熟產品的錯誤更困難些。例如：自動測試工具、查錯獎勵措施、啓發式測試等，持續測試多樣化可使曲線保持較高水平，直到想不出新的、更好的測試。
d項目最後，謹慎地測試。在這個階段測試的重點應該更具防禦性。要仔細測試每個變更，檢查這個版本要交付的所有文件。利用結對測試爲每個測試再增加一層保障。
288）利用測試分級簡化測試複雜性的討論。爲了在測試策略中簡化測試複雜性的描述，很多測試項目團隊都發現區爭測試級別會有幫助。例如：
0級，冒煙測試。顯示產品已經可進行獨立測試的簡單測試，如果0級測試失敗，可把產品直接打回給程序員。
1級，能力測試。檢驗產品每個函數能力的測試。1級測試的目標是保證每個函數都能夠執行其任務。1級測試應該避免採用曲折的場景、富有挑戰性的數據和功能交互。
2級，函數測試。檢查產品各個個體函數和子函數的能力和基本可靠性。使用邊界、壓力和錯誤處理測試，避免採用曲折的場景和功能交互。
3級，複合測試。包含多組函數間交互和控制流，以構成複雜場景的測試。評估的重點已擴展，可能要包括性能評估、兼容性、資源緊張程度、內存泄漏、長時間可靠性或其它類型的質量評估。
注意：這四級測試中的每一級，可能對應一些不同的測試技術或技術組合。總體思路是首先寬泛地、同情地測試，隨着測試不斷成熟，逐步進行深度和邊緣測試。對產品的早期版本執行第3級測試，而不首先執行第1、2級測試，可能會使程序員感到反感，更有可能的是，根本不能執行這些測試。
289）測試灰盒。灰盒測試的概念很簡單：如果瞭解一些產品內部工作情況，就能夠從外部進行更好的測試。與白盒測試不同的是，白盒測試需瞭解產品內部細節。在灰盒模型中，要從產品的外部測試，就像黑盒測試一樣，但所選擇的測試反映出測試員對內部組件操作和交互的瞭解。
290）在重新利用測試材料時，不要迷信以前的東西。即，在重用測試用例等任何測試材料時，不要將其當作黑盒使用。要先做一些瞭解，思考測試材料爲什麼採用這種方式設計。另一方面，如果對編寫將被重用的測試用例想法感興趣，可自問別人怎麼會知道該測試用例的含義，編寫這個測試用例的理由，以及這個測試用例該在什麼時候過時或更新。
291）兩個測試員測試同樣的內容，也許並不是重複勞動。重複測試工作幾乎都不會是浪費，因爲兩個測試員可能會注意到不同的問題。其實重點不是重複測試工作是否浪費，而是產品的某一部分是否值得進行重複測試。
292）設計策略時既要考慮產品風險，也要考慮產品要素。基於項目的測試策略所制定的原則如下：
a不要在測試員間的縫隙中遺漏錯誤。因爲這些遺漏會出現在兩個測試員（小組）任務間的邊界處，除非採用多樣化折衷測試手段。
b經常測試客戶要求測試的內容。測試員弄清他們的要求並至少完成一部分所要求的測試。
c偶爾測試客戶要求不要測試的內容。有時客戶要求不要測試產品的特定部分。這是個微妙的問題，有時被要求不要測試的正是最需要測試的。
d測試不夠清晰和矛盾的內容。任何有模糊和矛盾的地方，就會有很多錯誤。例如：程序員不太確定某個功能應該完成什麼任務；程序員是第一次使用這種技術；兩個程序員編寫相互間接口的單元。
e不要痛打落水狗。如果已清楚某個功能看起來有很多錯誤，就不要繼續測試了，除非要和程序員一起檢查。因爲程序的組件可能直接被替代而不是修改，所以發現的所有錯誤都會被一起歸檔，不必再費勁測試。
f更多變更意味着更多測試。理論上，產品中微小的變更也會產生大的全局效果。這意味着任何變更都可能潛在地使已經完成的該產品測試無效，所以測試員必須測試所做的變更。到項目快結束時，這部分的測試工作量很大。
293）把測試周期看作是測試過程的韻律。真正的測試計劃是實際指導自己實施測試的一套想法。計劃共包括7個任務主題。
a監視影響測試計劃的主要問題。確定影響制定實用、有效的測試策略中時間、工作量或可行性要素的風險、障礙或其它挑戰。要把握計劃的整體作用。在整個項目開發過程中，全程監視這些問題。
b明確任務。根據對具體項目的瞭解，爲測試任務目標排隊。對於所有適用的目標，找出可以用來評判的具體的成功指標。
c分析產品。瞭解被測產品及其內部技術。瞭解如何使用被產品。需要深入下去。分析什麼（用戶、結構、功能、數據、平臺、運營）；分析方式（執行探索式測試、評審產品和項目文檔、與設計人員和用戶面談、與類似產品進行比較）；可能的工作產品（測試覆蓋大綱、帶註釋的規格說明、產品問題清單）。
d分析產品風險。被測試產品怎樣以一種重要方式失效？分析對象（威脅、脆弱性、失效模式、失效影響）；分析方式（評審需求和規格說明、評審實際失效、與設計人員和用戶面談、對照風險啓發和質量評判大綱評審產品、找出一般問題和失效模式）；可能產品（組件/風險矩陣、風險清單）。
e設計測試策略。測試員可以做什麼？首先做出最好的策略，同時又要讓測試策略能夠在項目整個開發過程中改進。考慮五方面的手段（以測試員爲核心、以覆蓋率爲核心、以問題爲核心、以活動爲核心、以評估爲核心）；計劃方式（針對風險和產品域確定手段、可視化具體和實用手段、使測試策略多樣化，儘可能減少遺漏重要問題的機會、尋找通過自動化測試擴展測試策略的途徑、不要計劃得過死，使測試員能夠發揮自己的才智。）；可能的工作產品（逐項列出的每條所選測試策略及如何運用的說明、風險/任務矩陣、所選測試策略固有問題清單、針對沒有充分覆蓋的產品部分提出的建議、測試用例（僅當需要時））。
f條件計劃。測試經理將如何實現測試策略？測試策略會受到條件約束或指示的很大影響，努力爭取所需的資源，並儘量利用可用的所有資源。
g共享測試計劃。測試員並不孤獨，至少要讓項目關鍵成員參加測試計劃討論制定，從而得到他們的理解和隱含支持，以爭取實現測試計劃。目標：對測試過程有一致理解、對測試過程有一致承諾、測試過程合理參與、管理層對測試過程的合理預期。
測試計劃的質量準則：
a有用性。測試計劃會有效地支持其所提供的功能？
b準確性。測試計劃文檔是否準確地與事實描述保持一致？
c高效性。測試計劃是否能夠高效地利用已有資源？
d可適配性。測試計劃是否能適應項目中合理的變更和不可預測性？
e清晰性。測試計劃是否自我一致並足夠明確？
f可使用性。測試計劃文檔是否簡練、可維護並有很好的結構？
g兼容性。測試計劃是否滿足外部提出的需求？
h依據。測試計劃是否是有效測試計劃過程的產品？
i可行性。測試計劃是否沒超出必須使用該計劃的機構能力？
評估測試計劃的提示：
a避免編寫過死的腳本。除非有具體的、重要的理由需這樣做。測試策略應該包含合理的變化，並充分利用測試員的能力根據具體情況進行分析，將關注點集中到重要但沒預料到的問題上。
b根據需求測試。測試隱含的需求是很重要的，即要測試需求含義的全部外延，而不只是字面上的需求。爲什麼要提出每個需求？要找出原因，根據需求的內涵精神測試，而不僅是字面的意思。
c促進可測試性。與程序員聯繫，幫助他們構建更具可測試性的產品。
d測試計劃不要太通用。測試計劃應突出測試策略和測試項目非例行的，與具體項目有關的方面。因爲值得開發的每個軟件項目都會有其特殊的技術挑戰，好的測試工作必須解決這些問題，通過測試計劃反映出的是很弱的測試計劃過程。
e點明即可。測試計劃文檔應避免不必要的文字。不要陳述很明顯的事實，要使每句話都有意義。
f不要限制人員。手工測試應允許即興發揮和現場思考，而自動化測試適用於需要高度可重複性、快速、不需要人工判斷的測試。注意：手工和自動化測試並不是同一種測試的兩種形式，而是兩類完全不同的測試手段。
g受測試進度制約。提出和說明測試進度時，應突出與開發進展、產品可測試性、報告程序錯誤所需時間和項目團隊對風險的評估相關性。
h解決瓶頸問題。測試過程應儘可能避免佔據關鍵路徑。通過與開發並行進行測試以比程序修改BUG更快的速度快速找出值得修復的BUG可以做到這一點。
i快速反饋。測試員和程序員間的反饋環應儘可能緊湊。所設計的測試周期，應向程序員迅速反饋有關在着手進行完整迴歸測試之前的最新補充和變更的信息。
j測試員不僅僅是測試員。測試團隊應利用除正式測試之外的有關質量信息渠道，以便幫助評估和調整測試項目。
k評審文檔。所有歸檔測試文檔應由作者之外的人評審。
語境驅動學派的七個基本原則：
a任何實踐的價值都取決於其語境。
b在特定語境下有好的實踐，但沒有最佳實踐。
c在一起工作的人，是所有項目語境的最重要的組成部分。
d項目常常以不能預測的方式逐漸展開。
e產品是一種解決方案，因爲如果產品不是解決方案，它就不能發揮作用。
f好的軟件測試是一種具有挑戰性的智力過程。
g只有通過判斷和技能，在整個項目團隊中始終進行協作，才能在合適的時間做合適的事，以有效地測試自己的產品。
備註：
1）這裏的客戶泛指項目組其它角色（如：技術支持、開發、市場）和用戶。
2）序號前兩個橫線（如：--14））表示不理解的觀點。
本書涉及到的課外閱讀：
1）認識論入門書：《批判性思維的工具：心理學的元思想》Levy、《思考與決策》Baron、《研究的技巧》Booth Colomb Williams。
2）認知入門書：《曠野中的認知》Hutchins、《理論與證據：科學推理的能力的開發》Koslowski。
3）探索式推斷：《證明與反駁：數學發現的邏輯》Lakatos
4）建模：《通用系統思考引論：25週年版》Weinberg
5）探索：《基本理論的發現：定性研究策略》GlaserStrauss、《定性研究的基礎》Strauss Anselm Corbin、《探索式數據分析》Tukey。
6）探索需求：《探索需求：設計之前的質量》Gause Weinberg。
7）試探法：《如何解決它》Polya
8）重現問題的注意點：《測試計算機軟件》Kaner
9）《有效的執行經理》PeterDrucker
10）灰盒測試：《測試Web應用系統》Hung Nguyen
|
