qileilove

10種使測試人員陷入困境的行為趨勢

這篇文章的作者是著名軟件與網絡測試實驗室Quardev的高級顧問，做過測試經理、測試承包商、為微軟等公司做過顧問，并為很多雜志寫過文章，且時常在各種測試大會中做演講。在10年的時間中作者組織、管理了超過400次的測試崗位面試，這些面試都是以項目模擬的形式進行的，從對這些面試中面試者的表現，作者總結了限制測試人員發揮其測試技能的10種傾向，并提出了如何避免這些傾向的建議。

　　作者組織這些面試的目的是讓面試者們暴露他們的優勢與不足，從而決定他們是否適合在Quardev的工作。面試的流程如下：先是通過電話面試了解求職者的工作經歷，然后通過郵件提供給求職者一個產品，并要求在20分鐘之類對其進行測試寫出至少一個bug。接下來，會邀請求職者去實驗室，對他們的工作經歷進行一次面對面的深入調查。項目模擬是最后一步，項目模擬的過程如下：

　　作者在白板前介紹測試任務，然后在白板上寫下Bugs和Issues/Questions。

　　求職者在Bugs下記錄他們發現的問題，每條記錄必須少于20個單詞。Issues和Bugs的區別在于，測試人員可能不是很確認這是否是一個bug，他們不確定是否原本就是這么設計的。比如"在主目錄下沒有setup.exe"，事實上可能是一個bug。這與求職者對于程序設計原理的了解程度和自信心等級有關。

　　如果求職者過于謹慎，在測試過程中沒有在Bugs下有任何記錄，或者過于自信，不認真考慮具體的實際情況，將自己發現的問題都記

　　錄為bug，我都會特別關注。我希望在謹慎和自信直接找到一個平衡點。

　　作者告訴求職者，當他們發現一個問題的時候有三個選擇：1）記錄為一個bug；2）記錄為一個issue；3）提一個問題。然后作者寫下Test Ideas和Tests Run。Tests Ideas是由于執行時間過長而不當場執行的測試，Tests Run則是求職者當場執行的測試。

　　白板上的內容如下圖：

　　然后作者給求職者一臺筆記本電腦，上面有一個目錄存放著被測軟件，軟件目錄如下：

　　這是一個檢查三角形類型的程序，輸入用逗號隔開的3個數字，點擊Check按鈕后，會有5種可能的輸出：“scalene” (three unequal sides), “equilateral” (three equal sides), “isosceles” (two equal sides), “invalid”, and “Not a Triangle.”。軟件的UI如下：

作者讓求職者開始進行測試，并在進行過程中接受求職者的提問。在項目模擬過程中，作者關注求職者的以下一些能力：

　　Questioning：他們是否通過提問來構建他們的測試，還是直接進行測試

　　Resourcing：他們是否索要項目相關的文檔、用例、郵件的資源

　　Modeling：他們如何關注提供測試的目錄？是否打開每一個文件夾？并對每一個進行提問，并圍繞他們設計測試

　　Recording：測試過程中是否進行記錄

　　Conjecturing：推斷，如果他們沒有向我進行提問，他們對產品的設想是如何的？并且如何進行測試？

　　作者在求職者的測試過程中尋找所謂的“The 3 C’s”：caution， critical thinking， and curiosity。

　　如果他們向我進行提問，我們會以開發、項目經理、測試lead、CEO等角色中的一個對他們進行回答。有時作者會給以善意但是誤傳消息的回答，有時回答又會自相矛盾，這些都是真實項目中會出現的情況。

　　作者的目標是觀察求職者的技能，并使他們陷入作者自己或者身邊的人曾經遇到過的困境。通過這些面試，作者總結了最常見的10種使測試人員陷入困境的行為趨勢：

　　10、Stakeholder Trust

　　測試人員對利益相關者過分的信任，認為他們擁有所有必須的信息，并且所有他們提供的信息都是正確和中肯的。

　　如何避免：盡可能多的形式收集信息：閱讀、提問、交談、測試...

　　9、Compartmental Thinking

　　思維局限性，測試人員僅從自己的或者近似的視角出發考慮問題，而沒有用其他的、對立的或者正交緯度的視角出發，這樣會導致漏掉一些

　　系統級的bug，或者漏測某個完整的特性。

　　如何避免：嘗試Brute Cause Analysis

　　8、Definition Faith

　　測試人員沒有意識到諸如“回歸測試”、"測試用例"、"功能"、"特性"等對不同的人來說意味著不同的事情。結果會導致，測試人員自認為測

　　試已經完整了，而實際上測試卻還沒開始。

　　如何避免：牢記相同的單詞可能有不同的含義，使用與你作為測試人員所服務的合作伙伴角度出發最合適的定義來理解。

　　7、Inattentional Blindness

　　非注意盲視，和思維局限性有所不同，測試人員以自己的視角發現了某些事情，但是卻沒有處理這些信息，而是直接忽略了。

　　如何避免：全面獲取信息，而不是指關注自己認為會引起問題的那部分。situational awareness態勢感知，在大規模系統環境中，對能夠引起系統態勢發生變化的安全要素進行獲取、理解、顯示以及預測未來的發展趨勢。

　　6、Dismissed Confusion

　　由于困惑而駁回自己的意見，測試人員不自信，認為開發軟件的人員比自己更聰明，導致問題的不是軟件本身的bug。

　　如何避免：增加自信，遇到困惑的時候提出問題或者記錄下來

　　5、Performance Paralysis

　　面臨選擇的時候害怕犯錯而遲疑不定。

　　如何避免：嘗試P.I.Q.cycle：Plunge-In-and-Quit，從某處開始考慮一個問題，當思考的過于復雜或者抽象而讓你頭疼的時候，退出來休息下，然后回來以新的視角考慮這個問題

　　4、Function Fanaticism

　　功能狂熱，只通過對UI判斷，程序能做什么、不能做什么，以此來直接進行測試。而不考慮程序的構成、如何運行、如何被使用及有哪些依賴項。

　　如何避免：使用啟發式思考或者checklist

　　3、Yourself， untested

　　測試人員沒有從合作伙伴的角度評估自己的工作。給合作伙伴提供了不準確的信息：bug報告、測試說明等。

　　如何避免：test your testing，評估自己的測試技術、策略、計劃、風險等

　　2、Bad Oracles

　　Oracles 指識別問題的原理和機制。這里相當于用例是否通過的標準。測試人員使用了錯誤的標準或者不知道使用什么標準來評判一個用例是否通過。

　　如何避免：聽取其他合作伙伴的已經，以判斷問題是否為bug。

　　1、 Premature Celebration

　　提前慶祝，發現問題后不深入尋找原因，而是提前拋出問題。

　　如何避免：遇到問題立即進行分析推斷，而不是馬上下定論。

posted on 2013-06-09 11:48 順其自然EVO 閱讀(165) 評論(0)  編輯  收藏