開發模型變了，工作模式不可能一層不變。如果想要在不同的模型中都獲得成功，自是要對不同模型對人員的需求有所瞭解。通過很多科學家及實踐證明，敏捷開發是所有開發型中最高效的。如果結果不盡如人意，想來就是實施應用的不對了。下面就是敏捷開發中的測試之我見了。
1. 敏捷開發模型的自適應性對開發和測試人員的要求。
- 測試要深入需求變化
隨着需求的變化，產品設計和實現也在做相應的調整。如果測試人員只能從黑盒角度看到變化，那麼一則bug發現總是在較晚時期，二則測試任務將是無底洞式的。因爲永遠循環的重複測試，才能保證新的改動實施正確且沒有影響到已經穩定了的功能模塊。所以，測試人員要深入產品的設計與實現。這和計劃驅動方法下的軟件測試方法區別很大。因爲，我們不在侷限於按計劃按時按預算完成工作。
- 自適應性要深入技術開發層面
如果僅僅從項目管理層面實行敏捷開發，而忽略了技術層面，敏捷開發也很難得以成功。
從開發角度看，自測試代碼（Self-Testing Code），持續集成（Continuous Integration），重構（Refactoring），和簡潔設計（Simple Design）等等這些技術層面上的方法都需要應用執行才能達到開發的自適應。
2. 敏捷開發的引入將引起測試領域的革命。將底層測試人員和高級測試人員徹底劃分開來。這是自動化測試等非手動功能測試方法做不到的。因爲敏捷開發小組要求人員的平均素質，而不是一個將領一羣兵。這也將使軟件開發國際化真正實現—發展中國家脫離外包工廠的名號，進一步發揮人的主觀能動性。
我們知道在中國，或是印度等相對發展落後的國家，大多數的IT工作都是重複的簡單的非核心的勞動。這點在《世界是平的》一書中解釋的很詳細。不難想象，這些人拿到設計說明書，按步驟執行實現需求的功能，這是不需要發揮太大人的主觀作用的，大多數工作人員只是按事先規定好的方法和流程做事情。但是，製作軟件的全過程都是人在參與，人的主觀能動性如果沒有得到發揮，將是大大浪費了資源。當然，這項的實施是需要整體人員的綜合素質的。
- 首先，看看微軟是怎麼劃分測試人員的職責的：在微軟的測試體系中，主要的測試人員分爲兩種，一種是SDET（Software Design Engineer Tester），一種是STE（Software Test Engineer）。對SDET編程能力的要求和對開發人員的要求基本上是一樣的。他們都須有紮實的計算機基礎知識和編程能力。區別可能在於開發人員對算法更加精通，或某一方面的技術鑽研的更深入一些。而微軟亞洲工程院要求SDET的技術面很寬，要能使用很多種技術，比如可以用C、C#、腳本等來寫程序。如果測試人員懂開發，有紮實的編程能力，那麼他們能夠做一些普通測試人員做不了的工作，比如可以將源代碼打開做代碼的靜態分析，還可以做測試用例的代碼覆蓋率調查。所謂的代碼覆蓋率調查，是指考察測試用例能否將所有的源代碼都調用到，是一種對測試質量的初步評估標準。而這些恰恰是敏捷開發所需要的。
- 從公司管理的角度看測試人員的劃分：引自“測試人員招聘的尷尬”
測試人員的崗位有很大區別，包括做UI功能測試、系統測試、數據庫測試、自動化開發、環境管理和項目管理等，對技術要求不一樣。爲了更好地找到合適的測試人員，有一些比較好的辦法，例如：
1.對於功能測試，技術含量低，但要求悟性好、思維能力好、溝通能力和理解能力強等，可以面向高中畢業生和大專生，通過良好的培訓，就可以滿足崗位要求。他們的穩定性好、肯幹。
2.對於UI適用性和易用性測試，爲了打破單調性、習慣性，可以找些合同工、週末鐘點工，人員的來源可以根據軟件產品的涉衆範圍決定，包括暑假的教師、政府的公務員（週末鐘點工）和在校的大學生等。
3. 可以招大學應屆畢業生，通過4－5個月公司內部的專業培訓，可以從事技術要求比較高的測試工作，如API測試、自動化腳本開發。
4. 通過前幾項省下來的預算，可以用更好的薪水招聘具有豐富編程經驗和測試經驗（4－5年以上）的工程師，從事技術要求更高的系統測試、數據庫測試等。
我想如果是敏捷開發，大多測試分佈在整個產品測試階段，並且很難劃分。因此需要測試人員具有綜合素質。這種模式下，功能測試、可用性測試、穩定性測試、系統測試、數據庫測試等等都是一起進行的。因此，單一素質需求，在這裏就不是很試用了。
3. 溝通-成敗的根本
溝通在任何開發模型中都很重要，在敏捷開發中尤爲重要。甚至關係成敗。可是，它也是最難寫出來量化的東西。有些好的方法可以借鑑，但是實際中的一些細節問題還是要做事情的人本身去思考去琢磨去總結，然後去做好。以下是引用Martin Fowler試圖從理論層面達到好的溝通譯成中文的一段話。
“溝通的確是一個非常重要的環節，它是敏捷方法的核心。在敏捷方法中，單元測試是程序員和代碼組件的溝通，功能測試是程序員以及QA和系統的溝通，故事牆（Story Wall）和回顧（Retrospective）是團隊和成員之間的溝通，功能演示（Showcase 或者 Demo）是團隊通過產品和最終用戶的溝通，持續集成（Continuous Integration）是產品和企業計算環境的溝通。溝通好了，什麼事情都可以妥善解決，溝通得不好，好事也會變壞事。和廣大技術愛好者交流溝通也是酷殼存在的目的和意義。”
