初建測試團隊應該注意的幾個方面

目前測試在越來越多的企業里受到了很多的注視，這是好事。但是目前很多公司的測試面臨問題：

　　● 新上的測試流程不規范

　　● 測試工具雜亂無章

　　● 測試用例和缺陷管理工具使用不規范或者根本沒有

　　● 大部分測試還已通過性和驗證性測試為主

　　● 沒有測試計劃，開發流程不規范，測試人員無所侍從

　　這些問題的出現直接導致一個問題，就是測試跟不上開發，甚至測試拖累開發導致發布進度放慢。因此很多新組建起來的測試團隊都不能得到公司領導的認可，從而變成棄子。

　　如何才能在各種環境都沒有的情況下建立好一個過硬的測試團隊？這是每個Test leader在團隊初期都需要考慮的問題。

　　針對上面說的情況，先把問題總結成幾個方面：

　　● 團隊文化

　　● 策略，計劃

　　● 用例，缺陷管理

　　● 團隊建設

　　● 交流

　　● 規范開發流程

　　團隊文化

　　無論測試和開發，都需要一個鮮明的團隊文化。所以在測試團隊初期就必須想好自己的團隊應該是一個怎么樣的團隊。一個有好風氣的團隊可能帶起來事半功倍。當然，很多時候團隊的文化符號的代表就是leader，leader是什么樣性格的人就可能帶出什么樣性格的團隊。所以，在團隊建設的初期，為了培養出一個好的團隊文化，leader必須以身作則，樹立表率。

　　策略，計劃

　　針對不同的產品制定測試策略和測試計劃是leader一上來就必須要考慮到的問題。

　　策略要針對不同的產品制定，主要制定出產品的測試重點和測試方法。測試策略可能一般人不太注意，可是如果一開始就沒有制定好策略，可能在以后的測試過程中抓不到重點，看不清方向。這也是很多測試失敗的最重要的原因。

　　計劃一定要盡量制定的細致，這點我和其他人的看法可能不同。一般認為測試計劃在一開始不需要制定的很細致，大概的制定到月就行，反正隨著項目的不同會有變化。 的確，可能測試計劃在項目實施的過程中是很容易變化的，但是我們必須一開始就制定一個最少到周的計劃，而且計劃中必須明確每個人在每周的工作內容。只有這樣，leader才能在制定計劃的過程中發現一些很細小的問題。在制定好計劃之后，必須同你團隊的成員一起review你的計劃，聽聽他們的想法。

用例，缺陷管理

　　測試用例和bug管理流程是在測試執行中必須要認真保證的一部分內容。打個比喻，測試用例就像開發人員的開發文檔，bug就象開發人員每天寫的code一樣。用例和缺陷在測試執行中要充分的重視，test case reivew， bug review要定期的做，而且是在整個團隊內部一起。一開始的頻率可能要高些，建議每天都留10分鐘的時間，團隊內部成員一起，談下今天的測試過程，遇到的問題，目前的測試用例的覆蓋情況。到了后期，頻率可以放慢。如果有機會，可以做些找bug競賽，這個方法不僅可以在短期內迅速提高一個feature的質量，也可以在過程中提高每個成員對產品模塊的認知程度。

　　團隊建設

　　每個團隊都少不了團隊建設這個要點，作為leader你理應知道你團隊的成員都做了什么事情，他擅長做什么方面，有什么方面需要提高。好的團隊，要有技術點，工作點和協作點，所謂技術點，就是團隊內部要有技術比較好的人能夠在測試過程中對一般成員給予一定的指導，工作點就是團隊內部需要能交給他放心做事情的人物，一個模塊的測試任務交給他，他可以很好的規劃自己的測試工作。所謂協作點，就是有良好的溝通能力和協作能力，能在技術公關的時候協住技術高手，能在測試模塊固定之后協助模塊owner找出潛在的bug。三個點的個性越鮮明，團隊的執行力就會越強。當然在日常的工作中，需要按照不同人的特點，幫助他們成長成團隊重要的一部分。

　　交流

　　之所以拿出這個來單講，就是因為在交流上吃的虧太大了。很多事情都是因為交流不暢，或者是交流不及時導致的耽誤進度，或者是一段時間的工作浪費。所以，在保證測試計劃執行過程的同時，必須要定時的和開發，市場等團隊做交流。了解新的情況，提前做準備。

　　規范開發流程

　　作為測試leader，很多問題可能是開發流程不規范導致的，如果是沒有開發設計文檔和需求文檔，那我們必須提出來的同時去通過溝通或者其他方式去解決。tester不是神，而且在目前的團隊配置上，我們的技術能力是最弱的，所以，我們必須要去要求其他的團隊協作，重視我們的測試過程。

　　其實一個項目的立項初期，測試能介入的時間越早越能夠保證產品的順利發布。開發人員可能會從開發的角度考慮問題，一些架構的設計不會去考慮測試的方便。但是我們必須在他們架構代碼的時候就要求他們提供一些方便測試的接口，或者設計結構，以便以后布置自動化測試，或者是降低測試模塊的偶合度。考慮提高測試的質量和效率