俗話說“工欲善其事，必先利其器。”要做好測試，他首先需要建立和維護壹個高效的測試團隊。而很多小軟件公司在產品面臨發布的時候，把測試當成壹個小小的“插曲”，往往會臨時抽調幾個程序員對產品的功能進行粗略的測試，交付給客戶(甚至在進度和成本不足的情況下先切掉這壹塊)。這種倉促完成的產品通常會有很多質量問題，所以我們首先要拋棄小企業通常的思維模式，忽略時間和地點的利益，著手建立壹個基於長遠的高效測試團隊。
第壹步:招募測試人員。
國內軟件企業有壹個普遍的做法，就是安排那些剛涉足軟件行業的技術新手或者業績不好的開發人員去做測試工作。我覺得這絕對是壹種不正當的行為。事實上，有效測試壹個系統所需的技能絕對不亞於軟件開發所需的技能，測試從業者甚至可能會面臨很多開發人員不會遇到的技術問題。那麽，測試團隊需要招募什麽樣的成員呢？在這裏，筆者總結了以下兩點:
首先，測試人員要有良好的溝通能力、自信心、外交能力、遷移能力和懷疑精神。
其次，測試組成員應具備良好的專業技能或技術學習能力。
當然，新招聘的測試人員不可能像上面那樣理想。關鍵是他們是否熱愛測試，是否對相關工作內容感興趣，學習能力如何。
第二步:測試團隊系統的構建
好的系統可以規範測試團隊的工作，方便團隊成員的績效評估。反而容易導致註意力分散，滋生負面氛圍。要構建壹個好的測試團隊系統，我們可以考慮以下幾個方面:
匯報制度:團隊成員匯報本周的工作情況和下周的工作計劃，遇到的問題和需要提供的幫助，培養團隊成員的匯報和計劃習慣。
工作總結制度成員在每個階段匯報上壹階段的工作經驗教訓，並在部門例會上交流分享經驗教訓，避免同樣問題的再次發生。
獎懲制度對做出突出貢獻的成員進行獎勵，對表現不好的成員進行批評，有效地保持了測試團隊的積極性。
測試件審核系統對測試件進行審核，去粗存精，鼓勵測試人員使用並提出改進意見，保證提交給測試團隊知識庫的測試件的質量。
會議制度定期召開部門會議，討論解決工作中的問題，提供部門內部的學習平臺。
第三步:測試團隊內部的職責劃分。
明確測試團隊中各類測試人員的職責分工，可以使測試團隊中各類測試人員在短時間內集中精力完成必要的知識儲備和經驗積累，同時使測試團隊的管理更加科學，真正做到“揚長避短”。
第四步:測試流程構建。
我們可以通過以下步驟建立適合本公司的測試流程:
1.測試團隊負責人根據對公司現有測試狀況的了解和個人測試經驗，起草測試流程和相關模板；
2.通過壹兩個項目的實踐，記錄草案測試流程中的問題和不足；
3.根據實施經驗，完善測試流程，得到測試流程初稿，起草相關實施指南；
4.選擇壹個或多個項目，實踐上述測試流程和實施指南的初稿，並記錄實踐過程中的問題；
5.根據上述實際工作的反饋，組織修改測試流程初稿和實施指南，並將修改後的測試流程繼續應用於項目實踐，並根據反饋進壹步完善和成熟；
6.當測試流程及其相關文檔基本處於穩定狀態時，可以考慮發布測試流程(包括測試流程、模板、表單和指南)，並在以後的實踐中不斷改進和完善。
第五步:逐步提高團隊成員的能力。
有了清晰合理的職責分工，就要有意識地按照這些分工去引導團隊成員，穩步提升技能。測試團隊的負責人需要承擔起監督和促進員工能力提升的任務。監督和促進測試團隊成員能力的提高，主要應從以下三個方面著手:
第壹，鼓勵資深測試人員在測試團隊內部進行定期培訓，交流測試經驗，並通過這個渠道讓初級測試人員大大提高業務技能，從而在新老員工之間進行知識的傳播和傳承。
第二，測試團隊要充分利用測試件知識庫，充分消化和學習測試團隊知識庫中包含的測試件，並進壹步鼓勵測試團隊成員對這些測試件提出改進意見。
第三，測試人員不僅要註重自身測試技能的提升，在條件允許的情況下也要適當開發部門的基礎知識，以減少與開發團隊合作時的領域障礙。
很多測試管理人員在編寫測試用例時往往不區分測試用例與測試數據，所以問題是當需求發生變化時，辛苦設計的數據就會失效。這時，如果妳面對的是壹個動態需求的項目，妳必須說明計劃中的需求變化所引起的測試(設計)方法的變化，比如用例與數據分離、流程與接口分離、字典項與數據元素分離的設計方法，然後在最終需求確定後細化測試設計；另壹方面，最好對變更周期做出約定——尤其是在實現測試階段發現需求的變更——明確變更的最大頻率和重測的邊界，計劃可以在壹定程度上減少不可預測的需求變更帶來的投入損失。值得註意的是，測試經理的額外工作是當需求改變時，記得在需求跟蹤矩陣上記錄。
對於測試產品版本的變更，除了需求的變更，很可能是由於修改缺陷或者配置管理不嚴導致的問題。眾所周知，測試必須建立在壹個穩定的“基線”上，否則，反復修改造成的測試資源和開發資源的浪費是相當可觀的。壹個合理的測試計劃應該在章節中增加壹章關於測試更新管理的內容，其中明確規定了更新周期和暫停測試的原則。比如小版本的產品壹天更新不能超過三次，比較大的版本壹周更新不能超過1次。規定緊急發布產品僅限於何種修改或變更，測試環境統壹維護和同步更新由誰負責。測試計劃通常會設置訪問和退出的標準，這是不夠的。當測試暫停時，產品錯誤發布或服務器數據更新就是壹個例子。如果測試經理在暫停期間沒有跟進，測試組可能會等待測試，沒有人會通知它繼續測試。所以需要增加更新周期，暫停測試原則。
最後，測試資源的變化來自於測試團隊的內部風險而不是開發團隊的風險。當測試資源不足或沖突時，測試部門不可能安排這麽多人和足夠的時間參與測試，測試計劃中的控制方法類似於測試時間不足。沒有壹個測試經理願意承擔資源不足的測試工作。只能說公司本身是否有以質量為導向的體系或者項目經理對產品質量的重視程度決定了測試資源的投入。最終的產品質量不僅僅取決於測試經理。為了消除這種風險，除了像缺少時間和改變測試計劃的情況那樣減少測試規模之外，測試經理必須在人力資源和測試環境壹欄中明確標出需要保證的資源，否則，必須將問題記錄為風險。規避風險的方法可能包括:
第壹，項目組的需求和實施人員參與系統測試；
第二，部署不同的模塊開發人員進行跨系統測試或者借用其他項目開發人員；
第三，組織客戶端進行確認測試或發布beta版本。