解釋測試之走廊對話的法則
什么是走廊對話
解釋測試是一個很大的問題。在這里，讓我們集中精力在這個挑戰的一個部分：走廊對話。我是根據解釋的時機命名的，時機發生在一個軟件項目的自然過程中，例如，在一個工作日的走廊碰面。
我朝著我的座位走，亞當，開發經理，將朝著相反的方向走。他認出了我。
亞當說：“噢，詹姆斯，我們希望把時間縮短三個星期，我知道你的進度表要求在原代碼凍結后整整八周的時間進行測試。你能在五周完成嗎?我們可能沒有時間去按照我們希望的那樣去測試了?！?/P>
我的第一反應是他不能夠認真的對待質量，他是一個混蛋，然后我應該回擊他的無知。我離開了，我不需要如此……。這些第一反應不會對我們有所幫助，我讓他們走了。幾毫秒后，一個好的想法出現了：恐怕亞當認為測試進度表是由完全由我控制的因素決定的，如果這樣，恐怕我能夠直接的答復他。
詹姆斯說：“我的進度表并不在我的控制之中，亞當。八周時間只是根據產品的復雜度和我們能夠想到的我們以前遇到的困難所形成的表格，這可能會需要多于八周的時間去測試和修復，或者至少，更多的取決于當我們拿到產品的時候它的技術狀態?！?/P>
注意我是如何試圖提供一份進度表的影響因素的菜單，那么我們可以有效地盡量合理的縮短測試周期。我希望他可以詢問這些因素，在這種情況下，我就可以找出書寫板然后給他列一個很長的列表，這些因素并不需要是絕對正確的，僅僅足夠正確就好了，這樣我們可能就會討論我們所面對的整個情形，而不是僅僅傾向于給這位經理一個結果。
亞當說：“你不能預見進度表嗎?”
再次證明我的第一反應好像是沒有用處的：也許我是一個騙子，也許我應該能夠預見進度表，也許每個人都可以做到這一點，但是除了我。只要我在中學的時候那天沒有生病，我就應該知道進度表?這些不安全感對于我們這些努力做好本職工作的人是非常正常的，我也讓這些想法遠離我的大腦。
在這種情況下有效的回答應該是什么?在我看來亞當似乎期待兩種回答(也許只需要一種回答)，在這種比較復雜或者隱蔽的情況下。正如我的最初的回答一樣，我會試圖用一種方式將問題的層面擴大以便他和我可以更有效的交流，我將會使用一個強有力的工具：一個舉例。
詹姆斯說：“我不知道如何準確的預計進度表。這項工作可以迅速也可以緩慢，這取決于阿拉斯加州的項目，2642 個缺陷?還記得哪個嗎?在我們找到可以完全重復使用的案例以前花費了兩個星期，結果是該產品和一個受歡迎的防病毒掃描器相結合了。你知道你樂意在我們接手以前做那種結合，但是我們無法預先預見這個事情。”
亞當說：“我了解這個很難估計，但是把工作壓縮為五周是可能的吧?”
現在我對于為什么亞當可以將視線轉移到這個期限表示驚奇，他好像沒有聽我的。如果回答了這個問題并做出解釋，他將會比較惱火。走廊對話的關鍵是知道何時講演以及何時停止。在這種情況下，是時候聽從和領會了。
詹姆斯說：“我了解縮短進度表對于你的重要性，幫助我了解五周的重要性。那里有什么協議?”
亞當說：“嗯，在早期計劃中，一些高級經理人綜合考慮了他們的時間。我們所考慮的所有的時間一直認為是‘發布到生產’的日期是6 月30 日，現在的結果是那個日期是稅收時間，發布給生產廠商至少需要提前三周的時間以便產品能夠完成?！?/P>
詹姆斯說：“如果產品在那個時間沒有為生產廠商準備好那將如何?”
亞當說：“必須準備好?！?/P>
詹姆斯說：“如果沒有完成將會怎樣?”
我提出這些問題的目的是清晰的判斷形勢，從而我們能夠將現實和期望區別開來。然后我可以指出在這種情況下并不是只有一種選擇，而是很多。我做這些并不僅僅是為了有幫助，發現和辨認清楚可能性同樣也是測試技術的基本原理，而且每一次的交談是驗證測試者想法的機會。
亞當說：“副總裁不會允許這樣的”。
詹姆斯說：“嗯，有可能。但是作為一個測試人員，我的工作是提供信息，幫助組織者做出更好的決定。我覺得在這里不只一種選擇。把它歸結為一點，副總裁可能覺得一個推遲的產品比一個劣質的產品要好很多，或者他寧愿我們削減一些功能。”
亞當說：“為什么我們不能修改我們的策略而得到我們想要的呢?你說過你的測試可能需要不到八周的時間。我在為加緊整個進程尋找途徑，和我們一起工作吧?！?/P>
現在他聽起來似乎像是他自己要做，暗含接受了有多于一種選擇的想法以及使用這種方式去將他自己的計劃作為一種選擇方式。這聽起來是他經過選擇的論點，但事實上他已經選擇了自己。通過接受有很多的選擇，他不得不考慮影響我們選擇的因素，這些因素是我需要他做的，如果他要理解測試。
詹姆斯說：“好吧，讓我們一起工作。首先，我希望你能夠理解測試進度表我沒有唯一的控制權。當我們的質量標準很高，我們就需要更仔細的測試，如果開發提交的產品是很不穩定的，我們的一些測試將會被封鎖;如果開發提交的產品對于我們來講太難以了解，或者難以控制，那么測試將會進行得非常緩慢;如果我們發現的缺陷是難懂的和間歇的，我們的調查和報告將會花費更多的時間;
如果產品的變更沒有得到足夠的控制，我們可能不得不進行廣泛的重復測試;以及如果程序員需要花費很長的時間修改缺陷，那么它們將沒有辦法按時完成，不論測試還有什么工作沒有完成。你能理解我所說的嗎，亞當?如果你想要縮短計劃表，那么我們就不得不查看什么能夠驅動進度表?”
亞當說：“我理解你所說的，我能夠做些什么幫助你們呢?如果程序員幫助你們測試這樣有幫助嗎?如果我們能夠運行你們的一些測試用例呢?”
詹姆斯說：“我們沒有定義測試用例?！?/P>
亞當說：“真的嗎?但是如果你預先設計測試用例測試不是更容易組織測試嗎?如果按照哪種方式那么事情將會進行得更快嗎?”
現在我必須說明一個信念，那就是測試本身來自非測試。這觸發了一套無助防御思考：你的規格書是混亂的，但是你能夠期望我們寫出高質量的測試用例嗎?給我休息一下?除非我真的累了或者我聽到了我成為稅務檢查的對象，我通常讓這些想法離開。取而代之的是，我嘗試贊成他的說法：他是對的;有時預先定義一些好的測試用例是可能的;并且希望測試一直那樣做是可以的，不論環境是什么。
詹姆斯說：“是的，你這樣想有時可以準確的選擇正確的事情去做?？墒?，我們目前的情況是，我不知道怎樣開展這樣的工作，有太多的不確定。我們能夠創建測試用例，但是他們可能是很糟糕的測試用例。那些能夠充分的在產品生產以前就定義測試用例的人，或者是基于很穩定的、定義明確的技術上有能力的人，或者是沒有能力的在欺騙你的人。我們面臨的挑戰是要盡快地盡力定義具體的測試。”
亞當說：“那么你如何控制測試呢?你有沒有一個測試計劃呢?”
這是一個普遍存在的誤解，就是一個過程僅僅是由有文檔的計劃控制的。這是我引入另一種思維方式的機會。詹姆斯說：“在大多數情況下，我們使用一種探索的，基于風險的檢驗方法。
如果是基于你所說的引導測試過程的‘測試計劃’，是的，我了解它了。除非它值得記錄否則我不會寫在我的記事本上，但是如果你想聽的話我可以和你分享。
事實上，我希望你能夠告訴我，我們的計劃是否是在正確的軌道上，我們通過經常報告我們的測試狀況，然后調整我們的測試策略，這些都是基于管理者對于產品風險的節點控制的。換句話說，作為我們測試過程中的一個客戶，我希望你能參與到我們是如何控制測試的事情中?！?/P>
類似“探索的”和“基于風險的”這樣的詞語是強意詞也是誘餌，我希望能夠挑起他詢問更多的關于我們如何測試的問題，但是這也是一個危險的動機，如果我的語氣過分的強硬，就給人放煙霧彈的印象。
亞當說：“什么是探索性測試方法?”
他受到誘惑了!他可能會懷疑我在欺騙他。但是對他是有益的，引起了他的注意。現在我想總結的解釋和結束于一個強有力的建議，那就是他這樣做了就可以得到他想要的東西。
詹姆斯說：“這就好像在玩產品的‘二十個問題’。我們經過一系列的測試，
我們同時學習產品、設計測試，執行并報告缺陷，我們的測試覆蓋是基于一個產品模型，該模型和我們以前的相比是有所改進的。我們也會使用啟發式的測試列表，并且我可以現在就將它們展現給你如果你想了解，這是我所了解的測試一種新的不熟悉的產品的最快方法。你希望再將它們加快嗎?那么就讓我們開始讓測試者快速的了解該產品是什么和如何工作吧，讓我們用一個小時時間讓測試人員簡要了解產品，然后再花費一小時用在質量保證。然后當你在兩周內將講代碼提交給我們后我們會開始集思廣益的討論，產生更多的明確的測試策略。這樣如何?”
亞當說：“什么時候我們才能知道整個測試過程需要多長時間?”
詹姆斯說：“告訴你吧，亞當。讓我們現在就坐下來，然后仔細的檢查所有的因素：風險、各種測試任務、開發任務?這是全部吧。我們可能會找到簡化測試過程的方法，但是我們應該也要開發一些其他可供選擇的案例，盡管我們不希望測試和修復過程拖延。”
在這種情況下，他說什么其實都無關緊要。這是我最后和最好的提議，我想讓他得到他想要的，而且它的代價通過分析變得艱難前行，如果他拒絕了我的建議，我所解釋的所有事情仍然都是真實的。最后，如果組織決定將測試壓縮為“整整”五周時間，我將會做我能做的事并且真實的報告我的處境。我們或者是到那時之前都是完整無損，或者是在我們對于產品了解不多的時候將它推出。
這是一個典型的走廊會話，在自然環境中的解釋說明。它可能發生在一個項目會議中而不是走廊，但是原理是一樣的。注意這與你是否同意我的規則或者使用我的任何關于測試的想法是沒有關系的，加入你自己的想法。在這里我所闡述的是在這樣的解釋說明中如何交換意見和形成它的力量因素是什么。關鍵點是，我們很少會用超過幾句話解釋我們的工作，這就是為什么有一些例子說明(比如
缺陷的不好的例子)或者一個比喻(如“二十個問題”的游戲)是非常重要的。這就是為什么這有助于實踐得出影響的因素，這些因素將會使得你的測試失常。
沒有什么能夠替代實踐，但是這些知識可以幫助你建立自己的對話技巧。兩個幫助我成為一個更為有效的解釋者的是Gerald Weinberg 的“解決問題探討會”和“轉變”，這些涵蓋了整個做技術的小組。
一個好的走廊對話有九個法則：
1、從實踐中發言。保持真實，擁有自己的方式。如果你沒有完全明白其他人的言談避免使用它，因為持懷疑態度的聽眾將會反復詢問你，使它成為正在進行的項目以改善你對于測試技術的理解，通過將它們用于實踐觀察你是如何改變自己得想法的，并且使得你的想法影響其他人的實踐。
2、和他們聯系起來。比你的聽眾在某方面先進，將自己的身份放低。一個執行副總裁關心什么?一個技術支撐管理人員的一天是什么?一個項目經理的首要擔心的三個問題是什么?將你的企圖、知識和感興趣的方面調整到你聽眾的一邊。
3、查看你的條款。很多次我的解釋說明已經挫敗了意想不到的分歧術語。條款如測試、測試用例、測試計劃、回歸測試和缺陷，這些我稱之為危險術語，因為對于這些條款有很多不同的定義。如果你辯證的看待自己，考慮像以前一樣簡要定義這些條款。
4、展示出尊重。對待每個人好像他們都是非常聰明的人，并且他們和你一樣的關心質量。尊重異議和問題，我發現我有時候可以將處于敵對狀態的聽眾通過善意的，有洞察力的解釋轉變過來，這和他們是否真的有企圖和有洞察力是沒有關系的。我用這種方式對待他們，因為不這樣做肯定會失敗。
5、引出有趣的話題。你不可能向一個不感興趣的人有成果的解釋事情。引起你的聽眾一點的興趣他就會提出問題。如何這樣做的方法之一就是拋出一些顯而易見的不清楚的地方、行話或者和你的解釋說明矛盾的地方，如果你的聽眾詢問他們，你就回答說“好眼光，我非常樂意聽到你這樣詢問，這是個非常重要的問題?！比绻麄儾辉儐?，他們說“你或許沒有注意到這里有一個矛盾的地方，你將有權提出質疑?”不論是那種方式，繼續將該問題更好的解釋。
6、解釋問題發生后的事情。按照你的想法做了執行的差異是什么?你希望發生什么?如果我們接受了你的測試觀點我們行為有何不同?將注意力集中在你解釋后面的任務上。
7、迅速一點，找到關鍵。使用簡短的語句，那么也許你可以完成你的解釋，而不是在妙語連珠以前就被阻止。
8、展示出人人如何參與。我盡自己最大努力將項目的情況真實的描述：我們都在一起，我們都有貢獻，如果事情出錯了我們共同承擔。如果你發現解釋每個人所扮演的角色比較困難，那么停下來思考你是否能夠成功的解釋這個項目。如果只是牽扯你一個人，那么你將會使你的聽眾厭煩，如果只是牽扯進他們，那么你聽起來像是插足了不是你的業務范圍的領域。
9、準備充分。開發多種解釋的標準、預先的比喻以及不明白的時候要記錄。解釋測試的想法經常是在我真正在測試時，所以我準備了一個記事本用來捕獲這些想法，現在我有一大堆的記事本，上面寫滿了解釋的片段。
【編輯推薦】
