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