(六)敏捷測試指引-敏捷項目中的測試員

敏捷項目中是否應該有測試員呢？
 
        首先：替換測試員的是誰？是讓非測試專業人員（程序員、業務專家、技術文檔編寫人員等）來執行這樣的活動：幫助創建指導性的例子和對產品進行批判？還是，反過來，讓測試員來做編程、業務分析、技術寫作等工作呢？把“測試”僅僅作為技能的集合而存在，在項目中擁有充足的數量，用于服務所有需要這些技能的任務。
 
為什么非專業測試員會是個壞主意？這里是一些可能的原因：
        測試技能很難學到。如果你嘗試作為測試員同時是程序員，或者作為測試員同時是技術文檔編寫人員，你不會擁有所需要的最少的技能來成為足夠好的測試員。
 
        假設你是世界上最好的籃球運動員，同時是最棒的洗車工。你可能還是愿意讓別人幫你洗你的車，因為比起你自己洗車省下的錢，你可以賺取更多的時間來打籃球。這就是相對優勢的一個例子。因此，為什么不讓一個懂得測試的訣竅的人只是做測試，而讓一個在編程方面相對強的人專注于編程呢？
 
        測試雖然說不上是是一種天生的技能，但是某些人就是喜歡吹毛求疵，有些人則不擅于批判。
 
        很多人在找自己工作的錯誤時會有困難。因此把測試和其它任務混在一起的話會測試得很糟糕。中間存在太多情緒上的利益沖突了。
 
        測試員能從“有用的無知”得到很多益處。不知道實現的細節使得他們更容易從用戶的角度看什么類型的錯誤是用戶容易犯的。
 
論據
        讓我首先解釋一下“最小所需技能”和“相對優勢”。這些論據在面向技術的產品批判中是最強的，像安全性測試或可用性測試。在一個實際的項目，我一定能看到專門的安全性測試員。在小一點的項目，我能看到臨時出現的安全性測試員。
 
        對于我在面向業務的產品批判中所依賴的探索性測試員，我不那么確信。探索性測試員發現的這么多的bug中，很多是程序員可以預防的，如果他們能經?？纯茨切゜ug并使它們內在化。把bug內在化的最好的途徑是把程序員納入到尋找bug的行列，而不僅僅是修改bug。如果測試人員來寫其中的一些代碼，則bug會少些。因此這個論據是反對擁有專業的測試員的。
 
        換言之，我認為人們都有最小所需的探索性測試技能。
 
        我想相同的原因適用于矩陣的左邊-面向技術的檢查性例子（單元測試）和面向業務的檢查性例子（客戶測試）。我把這些方面的東西教給測試員。程序員也可以做。業務專家也可以做，雖然可能很少有人有機會達到最小技能的水平。那是為什么面向業務的例子是被團隊創建的，而不是仍過墻的。實際上，團隊溝通是如此的重要，以致應該把所有相對優勢的影響淹沒。
 
        現在，讓我們看看所謂的“天生的能力”。當Jeff Patton給我們展示以使用為中心的設計的例子時，其中一個練習是為一個假想的會議文件評審系統創建角色。我當時創建了類似“不情愿的文件評審者”、“過度疲勞的會議主席”、“拖延的作者”等角色。有些人評價說，“你能看得出Brian是個測試員”。我們都輕笑為什么我會傾向于悲觀的例子。
 
        但是最重要的是 – 那是學術行為。我這樣做是因為我有意識地去找出那些會跟開發人員希望不一致的操作系統的人。我的預感是我天生比別人更傾向于批判，但是我學著成為一名合適的測試員。我想普通的程序員也可以。我還沒有碰到過一名程序員是過分樂觀主義者，以致認為其他人的軟件是世界上最好的。
 
       

原文轉自：http://www.anti-gravitydesign.com