俗話說“工欲善其事，必先利其器”，要做好測試工作，首先需要建立并維護一個高效的測試團隊。然而，許多小型軟件企業(yè)卻將測試作為產(chǎn)品面臨發(fā)布時的一個小“插曲”，往往臨時抽調幾名程序員對產(chǎn)品的功能粗略測試一下即交付客戶（甚至在進度和成本不足時首先砍掉這一塊）。這種倉促完成的產(chǎn)品通常質量問題很多，所以我們首先應拋棄小企業(yè)慣常的思維模式，不計較一時一地之利益，立足長遠，著手組建高效測試團隊。

第一步：招募測試人員

在國內的軟件企業(yè)中有一種普遍做法，那就是把那些剛涉足軟件行業(yè)的技術新手或業(yè)績不突出的開發(fā)人員安排去做測試工作。筆者認為這絕對是一種欠妥當?shù)男袨?。事實上，對一個系統(tǒng)進行有效測試所需要的技能絕對不比進行軟件開發(fā)所需要的技能少，測試從業(yè)者甚至可能面對許多開發(fā)人員都不會遇到的技術難題。那么，測試團隊需要招募什么樣的成員呢？這里，筆者總結了以下兩點：

首先，測試人員要具備良好的溝通能力、自信心、外交能力、遷移能力以及懷疑精神。

其次，測試組成員應具備良好的專業(yè)技能或者技術學習能力。

當然，新招募的測試人員不可能像上面說的那么理想。關鍵是他們是否熱愛測試這項工作，對相關的工作內容是否感興趣以及他們的學習能力如何。

第二步：測試團隊制度建設

良好的制度可以規(guī)范測試團隊的工作開展，同時也便于對團隊成員進行業(yè)績考評。相反,則很有可能導致人心渙散，滋長負面風氣。建設良好的測試團隊制度，可以考慮以下幾個方面：

· 匯報制度 團隊成員匯報本周工作情況及下周工作計劃、遇到的問題以及需要提供的幫助，培養(yǎng)團隊成員的匯報及計劃習慣。

· 工作總結制度 成員每個階段匯報上階段工作經(jīng)驗和教訓，并在部門例會上交流、分享經(jīng)驗及教訓，避免同樣的問題重復出現(xiàn)。

· 獎懲制度 對于貢獻突出的成員予以獎勵，對于業(yè)績差的提出批評，有效地保持測試團隊的工作熱情。

· 測試件審核制度 對測試件進行審核，去粗存精，鼓勵測試人員使用和提出改進，保證提交到測試團隊知識庫的測試件的質量。

· 會議制度 定期召開部門例會，討論、解決工作中的問題，并提供部門內的學習平臺。

目前，已有不少軟件企業(yè)推行給測試人員區(qū)分級別的制度，獎優(yōu)罰劣。這無疑是一個好的做法，但成員業(yè)績的具體考評辦法，目前尚無可供參考的標準文件，所以筆者建議應盡量做到公正客觀，以免挫傷團隊成員的工作積極性。

第三步：測試團隊內部的職責分工

明確測試團隊內部各類測試人員的職責分工可以使測試團隊內部各類測試人員能集中精力在較短的時間內完成特定崗位必需的知識儲備和經(jīng)驗積累，同時也使得測試團隊的管理更科學，真正做到“用其所長，避其所短”。

第四步：測試流程建設

我們可以通過以下步驟來建立適合本單位的測試流程：

1. 測試團隊負責人員根據(jù)對公司現(xiàn)有測試狀況的了解，及個人的測試經(jīng)驗，起草測試流程及相關的模板；

2. 通過一到兩個項目的實踐，記錄測試流程草稿中的問題及不足之處；

3. 根據(jù)實施經(jīng)驗，完善測試流程，得到測試流程初稿，并起草相關實施指南；

4. 選擇一個到多個項目，實踐上述測試流程初稿及實施指南，記錄實踐過程中出現(xiàn)的問題；

5. 根據(jù)上述實踐工作的反饋，組織修改測試流程初稿及實施指南，并把修改后的測試流程繼續(xù)應用到項目實踐中去，根據(jù)反饋進一步完善成熟；

6. 測試流程及其相關文件基本趨于穩(wěn)定狀態(tài)時，可以考慮發(fā)布測試流程（含測試流程、模板、表格、指南），并在以后的實踐中不斷改進和完善。

第五步：團隊成員能力的逐步提高

有了明確、合理的職責分工后，需要針對這些分工對團隊成員進行有意識的引導，穩(wěn)步提升團隊成員的技能。測試團隊負責人需要負起監(jiān)督和促進員工能力提升的任務。監(jiān)督和促進測試團隊成員能力提高，主要做好如下三個方面的工作:

一是，提倡資深測試人員在測試團隊內部進行經(jīng)常性的培訓和測試經(jīng)驗交流，通過該渠道幫助資歷淺的測試人員大幅提升業(yè)務技能，做到新老員工之間的知識傳播和繼承。

二是，測試團隊應充分利用好測試件知識庫，對于納入到測試團隊知識庫的測試件應充分消化和學習，在此基礎上進一步鼓勵測試團隊成員對這些測試件提出改進性意見。

三是，測試人員除了需要注重自身的測試技能提升，在條件許可的情況還應適度開發(fā)部門的基本知識，這樣能減少與開發(fā)團隊協(xié)同工作時的領域障礙。

許多測試經(jīng)理在編制測試用例時往往沒有把測試用例和測試數(shù)據(jù)進行區(qū)分，因此，造成的問題是當需求變化時辛辛苦苦設計的數(shù)據(jù)就作廢了。在這時，假使面臨一個需求動態(tài)的項目，必須在計劃中對需求變更造成的測試（設計）方式變化進行說明，例如采用用例和數(shù)據(jù)分離、流程和界面分離、字典項和數(shù)據(jù)元素分離的設計方式，然后等到最終需求確定后細化測試設計；另一個方面是最好制定一個變更周期的約定――尤其在執(zhí)行測試階段發(fā)現(xiàn)需求的變更――定義變更的最大頻度和重新測試的界限，計劃從一定程度上能夠降低不可預期需求變化造成的投入損失。值得注意的是：需求發(fā)生變更時測試經(jīng)理額外的工作是記住要在需求跟蹤矩陣上做記錄。

對于測試產(chǎn)品版本的變更，除了部分是由于需求變更造成之外，很有可能是由于修改缺陷引發(fā)的問題或配置管理不嚴格造成。眾所周知，測試必須是基于一個穩(wěn)定的“基線”進行，否則，因反復修改造成測試資源和開發(fā)資源的浪費是可觀的。合理的測試計劃在章節(jié)中應增加一個測試更新管理的章節(jié)，在此章節(jié)明確更新周期和暫停測試的原則。例如，小版本的產(chǎn)品更新不能大于每天三次，一個相對大的版本不能每周大于1次，規(guī)定緊急發(fā)布產(chǎn)品僅限于何種類型的修改或變更，由誰負責統(tǒng)一維護和同步更新測試環(huán)境。測試計劃通常制定了準入和準出準則，這是不夠的，要考慮測試暫停的時候，產(chǎn)品錯誤發(fā)布或者服務器數(shù)據(jù)更新就是一個例子，暫停的時候如果測試經(jīng)理不進行跟蹤，可能發(fā)生測試組等待測試而沒人通知繼續(xù)測試的情況，所以，增加更新周期和暫停測試原則是很有必要的。

最后，測試資源的變更是源自測試組內部的風險而非開發(fā)組風險，當測試資源不足或者沖突，測試部門不可能安排如此多的人手和足夠時間參與測試時，在測試計劃中的控制方法與測試時間不足相類似。沒有測試經(jīng)理愿意承擔資源不足的測試工作，只能說公司本身是否具備以質量為主的體系或者項目經(jīng)理對產(chǎn)品質量的重視程度如何決定了對測試資源投入的大小，最終產(chǎn)品質量取決因素不僅僅在于測試經(jīng)理。為了排除這種風險，除了象時間不足、測試計劃變更時那樣縮減測試規(guī)模等等方法以外，測試經(jīng)理必須在人力資源和測試環(huán)境一欄標出明確需要保證的資源，否則，必須將這個問題作為風險記錄。規(guī)避風險的辦法可能有：

一，項目組的需求和實施人員參與系統(tǒng)測試；

二，抽調不同模塊開發(fā)者進行交叉系統(tǒng)測試或借用其他項目開發(fā)人員；

三，組織客戶方進行確認測試或發(fā)布β版本。