顛覆完美軟件：軟件測試必須知道的幾件事（讀書筆記5）

9、一種改善軟件測試溝通問題的模型（第十一、十二、13和14章）

　　本部分經過介紹薩提亞交互模型：攝取-->肯定含義-->肯定重要性-->作出反應，來應對軟件測試和項目推動過程當中的相關問題。

　　一、薩提亞模型

　　　　薩提亞模型將任何溝經過程都分解成四個階段：攝取、肯定含義、肯定重要性和作出反應。

　　　　攝取（Intake）：一我的從外部世界取得信息，攝取不是簡單的輸入，還包括信息的選擇過程。

　　　　肯定含義（Meaning）：某人會對感官攝取的內容進行考慮並給它一個含義。

　　　　肯定重要性（Significance）：肯定信息的重要性，可讓某些攝取及其含義得到優先權。

　　　　作出反應（Response）：一我的會構想出準備採起的行動。

　　二、信息攝取

　　　　攝取是一個主動的過程。要儘量地瞭解那些限制攝取的因素、信息的來源，以及數據如何得到了帶有誤差的含義。被動地等待別人給你的數據，也許不會讓你成爲受害者，但至少能夠潛在控制你會獲得哪些數據。

　　　　2.1 人們聽取的信息是有選擇性的

　　　　經理們尤爲選擇性聽取有關發佈和交付日期。若是測試人員說，根據目前發現和修復缺陷的速率，幾乎不可能在9月1日以前交付。經理可能會聽成，9月1日前交付。爲了不這類問題，有兩種方式：1.只採用書面形式給出和接受某個日期；2.不要給出或接受「點日期」，要這麼說，估計會在8月1日到8月21日發佈某個版本。

　　　　2.2 數據來源會影響到攝取

　　　　若是有些人不肯意接受你的測試報告，而願意接受其餘人遞交的報告。你能夠從本身找找緣由：1.本身之前是否是作過什麼讓你們認爲我不是一個可靠的信息來源的事。2.我應該作些什麼來提升他們對我做爲信息來源的信任。

　　　　2.3 提供信息的時機也會致使差別

　　　　別人將注意力轉向其它地方的時候會遺漏某些信息。若是沒有獲得別人的注意，就沒有什麼必要提供信息，由於對方不太可能接受這些信息。

　　　　2.4 人們會出現信息過載

　　　　人們受到過多信息，會中止或者在必定程度上減小攝取信息。好比缺陷數目太多，就是信息過載，這時候不知道應該先處理哪個缺陷。

　　　　好的方法是，將缺陷按照重要性進行分類。將缺陷報告類別分爲4個級別：0級、1級、2級和3級。

　　　　0級：阻礙其餘測試，未能在1分鐘內進行分類。

　　　　1級：該問題沒有解決，產品不能交付。

　　　　2級：該問題沒有解決，產品的價值會顯著下降。

　　　　3級：產品交付時有大量相似問題，該缺陷纔是重要的。

　　　　2.5 減小測試的數量能夠傳遞更多信息

　　　　經過回答「哪些測試會對未來的測試和開發產生最大的影響」這個問題能夠縮減可能的測試集合，進而經過不多的測試數量，就能夠傳遞很重要的信息。

　　　　2.6 尋找測試以外的信息攝取

　　　　測試以外，是否是有其餘緣由也會致使問題，好比靜電、震動、雷達等。一臺測試機器沒有按預期方式工做，多是別人使用後更改其狀態。

　　　　2.7 不要混淆理解和攝取

　　　　當人們根據隨機的一點數據，猜想這些數據的含義時，就會很是迅速地從攝取階段移動到肯定含義的階段。

　　　　2.8 使用數據質疑來過濾理解

　　　　當某人在你須要數據的時候向你提供對測試的理解，可使用數據質疑的方法：「你看到或聽到（或者聞到、嚐到、感受到）讓你產生這樣的理解？」，一般須要重複數據質疑，直到獲得你所指望的不帶含義的數據。

　　　　2.9 相關常識

　　　　1.你須要對接受的信息進行選擇，不要來了什麼信息就去接受。

　　　　2.測試工做中獲得的信息中有99%是沒有用的，你要有一雙慧眼，從大量數據中捕獲有用的信息。

　　　　3.不要混淆攝取和含義：

　　　　　　在肯定數據以前，數據時沒有意義的；對相同的數據，不一樣的人會給出不一樣的含義。

　　　　　　先收集數據，而後坐下來考慮這些數據可能具備的至少三種含義。

　　　　4.不要禁止測試人員在某些地方尋找缺陷，應擴展測試人員的思惟。

　　　　5.要爲測試人員提供充足的設備和工具。

　　　　6.有些昂貴的測試工具自己設計有問題、而且不可靠，那就大膽的拋棄它。

　　三、肯定含義

　　　　數據自己是沒有意義的，須要由接收的人給它加上含義，而不一樣的人會給出不一樣的含義。因此對一樣的數據最好給他多種可能的解釋。若是對測試結果不能想出至少三種可能的解釋，就說明思考得還不夠。

　　　　3.1 對缺陷要思考多種含義

　　　　對缺陷進行解釋以肯定含義須要勤奮和開放的態度。同時對缺陷而想到的含義應該越多越好。

　　　　3.2 解釋含義以前應弄清楚指望的是什麼

　　　　若是不清楚一個程序被指望作什麼，就永遠不能肯定地說它是錯誤的。在你給測試報告賦予含義以前，先要弄清楚你指望的是什麼。

　　　　3.3 不知道指望時的作法

　　　　若是在解釋測試結果時不清楚產品被指望要作什麼，能夠提出下列問題。

　　　　1.它是否完成了重要的人但願它完成的工做？

　　　　2.它是否沒有作重要的人不但願它作的事？

　　　　3.這些測試結果告訴我哪些與這個兩個問題有有關的狀況？

　　　　3.4 使用已經得到的信息

　　　　肯定測試報告的含義時須要考慮測試報告中未包含的信息。可是在盲目地要求更多的信息前，應該從已經得到信息入手。要充分地利用已經得到的信息。

　　　　3.5 使用間接信息

　　　　間接信息包括：每一個測試運行的日期和時間，報告提交的日期和時間，測試是誰運行的，每份報告是誰提交的，測試的軟件及其版本的明確標識，使用的操做系統、瀏覽器、計算機、配置，測試工具和原始開發語言，對較早缺陷報告的引用，及各類形式的補充說明。

　　　　只有利用這些彷佛是附屬品的數據纔有可能理解不少最困難的缺陷。

　　　　3.6 使用未得到的信息

　　　　根據缺失的信息推斷含義。

　　　　3.7 一樣的話可能具備不一樣的含義

　　　　3.8 「相同」可能並不同

　　　　表面相同，但實際來自於不一樣來源的事物進行理解時要保持懷疑的態度。

　　　　3.9 某些時候不精確會更好

　　　　在試圖對含義進行溝通時，有時候使用模糊的語言更有效。

　　　　3.10 相關常識

　　　　1.根據「三法則」，在採起行動以前至少考慮三種可能的含義。

　　　　2.在測試以前，要記錄好對測試結果的預期。

　　　　3.不要徹底靠本身肯定含義，要讓整個團隊都參與進來，從而下降忽略某個重要結論的可能性。由於不一樣思惟會肯定不一樣的含義。

　　　　4.肯定數據含義時使用「三法則」是不夠的。對不一樣的人而言，一樣的含義可能具備徹底不一樣的重要性。不一樣的思惟會肯定不一樣的重要性。　　　

　　四、肯定重要性

　　　　重要性是由負責決定要如何對缺陷進行處理的人賦予該缺陷的價值。每一個人由於思惟的不一樣，所肯定的重要性都是不同的。若是咱們注意情緒，認真聽取，先解決重要的事情再解決不重要的事，就能夠對得到的數據作出最好的處理。　

　　　　4.1 不一樣人會給一樣的信息賦予不一樣的重要性

　　　　做爲項目經理，工做就是將全部見解放在一塊兒進行權衡，並得出這個缺陷對於整個項目的重要性。--前提條件是它確實是一個缺陷。

　　　　4.2 公共的重要性也許和我的的不同

　　　　若是每一個人都是合乎邏輯的、公正的、開放的，對重要性的評估就會很簡單。可是，可能每一個人對缺陷問題作出重要性的回答時都參雜了我的打算在其中。若是項目經理想對重要性作出明智的估算，就要想辦法消除全部這些我的打算，包括項目經理本身在內。

　　　　4.3 重要性依賴於上下文環境

　　　　重要性不只取決於單個缺陷和單我的的一項性質，還依賴於上下文環境。

　　　　1.某段代碼，第一次出現缺陷和屢次出現缺陷，評定第n次缺陷的重要性是不一樣的

　　　　　　某段代碼，第n次出現問題，可能意味着之後還會發現更多的錯誤。這就是記錄全部缺陷的緣由。

　　　　2.對某個用戶可能碰到的程序缺陷的可能性進行猜想

　　　　　　一百億用戶中只有一個用戶可能遇到這種缺陷，重要性如何呢？

　　　　4.4 不能老是根據金錢來肯定重要性

　　　　好比說人的生命。

　　　　4.5 不要採用過細的尺度

　　　　由於全部對重要性的度量都是主觀的，不要愚蠢地讓本身相信重要性是客觀的。

　　　　將評定重要性的類別數量變爲4個，該評定類別可讓測試人員從測試角度肯定重要性。

　　　　0級：該問題阻礙了其餘測試。

　　　　1級：若是該問題不解決，咱們的產品就沒法使用。

　　　　2級：若是該問題不解決，咱們產品的價值就會顯著下降。

　　　　3級：只有在產品交付時還存在大量相似問題時，該問題纔是重要的。

　　　　4.6 首先解決重要問題

　　　　對已發現的故障，應先解決重要性高的故障。而經過對測試的重要性進行估計，首先執行那些重要的測試。

　　　　4.7相關常識

　　　　1.混淆重要性和修改的難度。

　　　　　　好比，系統崩潰的問題多是不重要，而某個拼寫錯誤確實是災難性的。

　　　　2.認爲有「理性的」或者客觀的方法來評估重要性：

　　　　　　也許可使用數字和算法來爲評估重要性提供幫助，可是最終的評估步驟老是要度量人對那些數字的情緒反應。

　　　　3.得到新信息後也要從新評估重要性。

　　　　　　重要性是整個系統的一種性質，包括用於構建該系統的系統或過程。常常回顧對重要性作出的評估，並作好改變它的準備。

　　　　4.不要讓廢話影響到對重要性的評估：有意或無心使用，某些會掩蓋有意的信息的詞。

　　　　　　好比，某人說「反應應該會很是快」的時候，究竟是什麼意思呢？「應該」，「很是」和「快」給表達的信息添加了什麼含義。

　　　　5.測試人員會對本身發現的缺陷不會在下一版本中進行修復而感到失望。

　　　　　　沒有人但願本身的工做被忽視。可是要儘量區分開忽視某些缺陷和有意識地選擇不修復某些缺陷的行爲。

　　五、作出反應

　　　　對缺陷正確的反應是：發現（find）他們；評估（figure）他們；修復（fix）他們。項目早期，會這樣作。可是發現的缺陷愈來愈多，咱們應該如何作出反應？

　　　　除了從一開始就採起正確的項目管理作法，沒有那種反應能夠挽救項目。若是項目進行到測試以前都沒有得到良好管理，大部分良好的反應都沒法使用。

　　　　5.1 運氣很差？管理不善？

　　　　成功項目和失敗項目對比，是管理不良致使項目失敗。

　　　　因外部緣由破壞軟件配置，經過恢復安全的備份，便可以投入工做。團隊一半成員請病假，結對編程和技術評審提供的冗餘信息，容許人們繼續在關鍵路徑上工做。　　

　　　　5.2 項目趕進度的緣由

　　　　主要同管理的質量有關。

　　　　管理不良的軟件項目具備以下特徵。

　　　　1.經理們不瞭解測試、查明和除錯之間的區別。

　　　　2.因爲不瞭解這些區別，因此認爲這些在項目中遇到的大部分問題都是測試致使的。

　　　　3.因爲他們會認爲測試會致使問題，更傾向於儘量推遲全部類型的測試。

　　　　4.因爲他們選擇在開發過程當中推遲測試，測試成爲了第一次進展不利的時候。

　　　　5.因爲選擇在開發過程當中推遲測試並出現信息免疫，即使測試發現問題還繼續僞裝一切順利。

　　　　6.因爲他們出現了信息免疫，在項目早期的各個階段一切都會看上去進展「順利」。

　　　　7.因爲經理們出了問題，缺陷到後期測試的時候纔會顯現出來，而其中不少從最初的需求開始就隱藏在產品中。

　　　　8.因爲整個系統中的缺陷不少都難以查明，因此很難應對大部分的缺陷。

　　　　9.開發人員在最後期限的壓力下試圖修復新發現的錯誤，同時也會製造新的錯誤，他們脾氣上升，缺勤增多，同時會議也越開越長，開發策略事與願違。

　　　　10.因而參與者得出結論：「測試以前沒有任何問題，是測試弄糟了全部事情」

　　　　錯誤管理的其餘類型包括：過於雄心勃勃的承諾，太差的工具、人員職位安置不當。全部這些都會形成進展緩慢，致使最後削減測試和修改的時間。

　　　　對缺陷最初也是最重要的反應是要預見他們會出現。沒人會僥倖地不遇到缺陷，因此從項目一開始就採起正確的作法。

　　　　最那些少許遺留下來的缺陷，當即開始FFF（發現-評估-修復）方法。

　　　　5.3 接近項目結束時應如何反應

　　　　管理良好的項目中，在交付日期臨近時仍然存在一些缺陷，按照以下方式進行。

　　　　1.中止全部測試，開始爲最後階段作計劃。

　　　　2.根據重要性對剩餘的已知故障排序。

　　　　3.估算剩餘的時間內，按照重要性由高到低能夠修復多少缺陷。

　　　　4.從交付計劃中去掉沒法修復的特性。

　　　　5.若是步驟4中有些特性會讓產品變得不可接受，就取消交付並從新制定交付計劃。

　　　　6.接下來按照步驟2中肯定的缺陷重要性進行修復。

　　　　5.4 對測試所需時間的估算與現實差距很大的緣由

　　　　項目開始時的不良估算極可能是在項目結束時要趕進度的一個緣由。常見的計劃偏差以下

　　　　1.好天氣偏差

　　　　按照項目按計劃進行，沒有缺陷進行修復來估算時間。

　　　　2.不切實際的過程模型

　　　　會忽略掉查明缺陷、修改缺陷，而後從新測試缺陷的時間。

　　　　3.低質的過程數據

　　　　4.沒有過程數據

　　　　5.5 錯過全部能夠改變的時刻應該怎麼辦

　　　　1.按照現狀交付產品；2.把故障當成一種特性；3.能夠向用戶提出有關這些故障的警告；4.能夠撤回某些部分或者整個產品；5.能夠從問題開始的地方從新開始。

　　　　5.6 相關常識

　　　　1.運氣老是寵愛管理良好的項目。

　　　　2.不要由於趕進度而減小分配給測試的時間和資源，若是不關心質量，爲何還要測試。

　　　　3.在測試提供了有關產品實際狀態的信息後應調整進度和估算的時間。

　　　　4.注意收集過程數據。對犯錯的位置和時間越瞭解，就越容易發現、查明、定位和修復他們，或者在下一次出現相似的狀況避免錯誤。

　　　　5.測試在產生項目概念甚至更早的時候就已經開始了。若是不瞭解這一點，就根本沒法瞭解測試。