(五)敏捷測試指引-用面向技術的例子批判產品

 為了幫助討論和理解，我把“敏捷項目中的測試”這一主題分解成4個區分的主題。今天，我將完成矩陣的右邊部分：面向技術的產品批判，而不是面向業務的。

        我選擇探索性測試作為面向業務的產品批判的工具。但是雖然它也可能找到安全性問題、性能問題、通常在壓力下才出現的bug、可用性問題（例如對色盲人士的適用性）等，但是我不會依賴它來完成這些方面的測試。而且，這些非功能性的問題或非功能性的需求很難用例子來詳細說明。所以看起來預防或找出這些bug目前為止還未納入到我們的故事中來。幸運的是，還有矩陣的最后一個四分區之一。

        我想關鍵是，找出這樣的非功能需求的bug更多的是技術性問題。你不能隨意地就能知道一些安全性的知識。性能測試可以說是“妖法”?？捎眯圆皇莻€“需要你知道很多計算機知識”的技術性的話題，但是它要求你知道很多關于人的知識（Mark Pilgrims的Dive Into Accessibility ，見http://diveintoaccessibility.org/，是個針對這方面的豐富知識的入門介紹）。

        雖然我老是說敏捷項目需要“通才”，但是這里的區域則需要的是“專才”。如果安全性是對于你的項目來說很重要的話，找個安全專家，在很多安全領域擁有豐富經驗的人。（也就是說，安全知識要比領域知識重要。）這些人能教會項目組怎樣構建安全的產品、并測試安全性是否被構建到產品中。

        （有趣的是：這些區域給我的印象是在設計和批判的角色之間的分離沒有產品功能開發那么明顯。Jakob Nielsen既寫關于可用性設計的東西，也寫可用性測試方面的東西。安全性方面的人物也是類似的，像Gray McGraw和Bruce Schneier，除了James Whittaker好像專注于安全測試方面。我不知道我的印象是否正確？對于性能測試人員好像沒那么正確，雖然我知道很多優秀的性能測試員也能出色地設計出高性能的系統。）

        因此，敏捷好像沒有給這些人帶來什么東西。這些專家繼續存在，他們發展成不同的等級，他們值得進一步的發展，他們掌握了很多好的東西?？赡軙蝗缦胂笾械恼_，但是我想他們應該就這樣繼續保持著。

        看起來我好像完成了我的關于敏捷測試的未來指引的系列。但是還有一個問題：究竟，在敏捷項目中是否應該有測試員？對于這是個熱點問題，我應該覆蓋到。

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