一些已經從事測試工作三到五年的朋友正在積極的向QA
Manager 角色轉型，他們對於將來的發展方向也很一致，普遍觀點大都是組建一支出色高效的測試團隊。最近我也想了一些團隊規範和成爲具有出色團隊稱號的必要條件，自己從事測試工作也接近四年了，有些是我在原先工作中遇見並且總結出來的，寫的我認爲還談不上全面以後還會逐漸補全。
條件：
首先正規測試團隊至少會有一個缺陷管理系統，不管是Bugzilla還是Mantis 或是其它系統，因爲軟件測試過程本身就是圍繞着缺陷進行的，這也是測試工作的一個重要組成部分。我個人還是比較青睞於使用開源工具。
測試用例誰來寫
我不提倡測試新人去寫測試用例，這些工作應該分配給那些經驗豐富的測試人員去做。新人寫測試用例存在一定量的風險性，例如考慮不周達不到預期覆蓋率，延緩測試周期和上線時間。
Bug有owner
對於Bug來說，測試人員開啓的Bug應該由本人來關閉。做到Bug也要有屬主
測試工作量評估
測試工作量應該由測試人員本人估算，從下到上估算工作量，而不是從上到下分派工作量，如果遇到工期固定可以簡化測試用例，測試分輕重
Bug描述
Bug一定要做到描述簡潔清晰爭取做到PD 一看就懂，減少不必要的交流。對於不容易重現的Bug可以清晰的描述操作步驟和具體操作時間產生什麼類型的錯誤。通過以往工作經驗個人認爲沒有不能重現的Bug。
開發人員對測試人員的測試結果產生疑議。如果測試人員根據自己的測試經驗判定是個Bug，可以先組織測試人員內部進行缺陷討論。判定Bug的嚴重級別後再進行相應處理。有不同看法是正常的，但是不要輕易妥協。
不要浪費測試人員時間。測試人員接到測試任務拿到需測試產品發現低級錯誤的數量以及功能的不完整性，有權退回。這是在浪費測試人員時間。
測試人員不要過於依賴測試工具
測試人員對測試工具的完全依賴是一種不好的做法，不要忘了最強大的是你的測試思想，在必要的場合採用工具確實能給測試人員帶了意想不到的收穫但是這只是一種測試手段不能代表測試的全部，如果需要使用工具，我建議往開源方面靠攏。
讓測試人員瞭解產品背後的商業意義
整個項目中什麼功能模塊是最重要的，爲什麼要開發這個新功能，這個功能在整個項目中有何種意義，這可以讓測試人員對該功能產生一個內心重要級別。對測試用例和以後的迴歸都起到很大幫助。
營造測試氣氛
開發人員開發完功能後需要自測，然後再交送給測試人員，共同把好質量關。開發可能會說我寫出來的東西我自己還要測試那還要你做什麼。如果開發的產品連正常流程都無法跑通就交給測試被一次一次的打回，這樣不光影響項目進度，還可能會導致該測試人員會你開發出的產品有情緒牴觸，質量很難得到保證。
測試團隊可以定期拿出一個課題由部分專人負責研究，然後定期Share研究成果組織團隊人員研究討論，促進工作學習兩不誤。
測試人員不夠
如果碰到時間緊任務重測試周期被縮短的情況。我不建議省略寫測試計劃，測試用例，測試報告去悶頭測試。測試可以分輕重，可以申請安排開發做輔助測試。也不能省略那些書面文字。不是走形式。測試人員要徹底認識到這些東西是非常有價值的，在適當時候可以保護你。
先寫測試用例再測試不是死規矩。事實上應該是這種工作流程，但是有些時候當沒有測試用例思路時，可以先手工運行一遍功能，想到什麼寫什麼，最後形成完整規範測試用例。做到靈活測試。
測試人員有義務向PM闡述對功能的流程以及易用性方面自己的想法。如果是爲了功能的可伸縮性那就不僅僅是測試人員需要參與討論有可能還有PD OP DB等等。最初目的是爲了以後如何更方便的開展自動化。讓自動化能覆蓋的更多更全面。
爲了保證產品質量測試越早進行越好。不僅是功能測試，其中也包含性能。
瞭解當前產品質量
測試人員每個人都應該瞭解當前產品質量，知道哪塊薄弱，知道自己該幹什麼，提倡每個人都可以提出建設性意見。
開發人員告訴測試人員你應該如何測試。
這種現象可以從多方面理解：
1、作爲測試人員你做的不夠好，長時間來你充當一個喊話筒的角色，從你以往提交的Bug來看沒有任何深度。想受人尊敬受人重視還是要靠自己踏實爭取。
2、測試團隊不規範，或者說根本就沒有測試團隊。讓開發領着幹活自己又不會寫代碼心理不好受抱怨多多。
更多時候還是需要自己多努力，知識要靠一點一滴的積累。很難重現的Bug你能重現，能告訴開發哪塊功能將來可能產生問題，指出系統瓶頸等等類似很多。這些都是需要經驗積累。漸漸的你會發現自己在團隊中起到了應有的價值得到同事以及上司的認可。
測試環境維護
測試環境由誰來維護其實我覺得並不重要，這裏指的誰可以是運維可以是研發可以是QA，但是最好要保證專人來維護，不要誰都可以插手。再沒有打招呼的前提下擅自發布新功能或者修改是不可取的。保證版本的統一性很重要。要做到正式發佈功能之前OP可以在測試環境下抓取項目整包進行發佈。當然對於極小功能小修改可以例外。
收集需求文檔
測試人員爲了寫出一份還算完整的TestCase東奔西跑到處收集信息。開發文檔和產品需求文檔出爐後請第一時間送交的QA 手裏，保證QA的工作開展。
