一些已经从事测试工作三到五年的朋友正在积极的向QA Manager 角色转型，他们对于将来的发展方向也很一致，普遍观点大都是组建一支出色高效的测试团队。最近我也想了一些团队规范和成为具有出色团队称号的必要条件，自己从事测试工作也接近四年了，有些是我在原先工作中遇见并且总结出来的，写的我认为还谈不上全面以后还会逐渐补全。
条件：
首先正规测试团队至少会有一个缺陷管理系统，不管是Bugzilla还是Mantis 或是其它系统，因为软件测试过程本身就是围绕着缺陷进行的，这也是测试工作的一个重要组成部分。我个人还是比较青睐于使用开源工具。
测试用例谁来写
我不提倡测试新人去写测试用例，这些工作应该分配给那些经验丰富的测试人员去做。新人写测试用例存在一定量的风险性，例如考虑不周达不到预期覆盖率，延缓测试周期和上线时间。
Bug有owner
对于Bug来说，测试人员开启的Bug应该由本人来关闭。做到Bug也要有属主
测试工作量评估
测试工作量应该由测试人员本人估算，从下到上估算工作量，而不是从上到下分派工作量，如果遇到工期固定可以简化测试用例，测试分轻重
Bug描述
Bug一定要做到描述简洁清晰争取做到PD 一看就懂，减少不必要的交流。对于不容易重现的Bug可以清晰的描述操作步骤和具体操作时间产生什么类型的错误。通过以往工作经验个人认为没有不能重现的Bug。
开发人员对测试人员的测试结果产生疑议。如果测试人员根据自己的测试经验判定是个Bug，可以先组织测试人员内部进行缺陷讨论。判定Bug的严重级别后再进行相应处理。有不同看法是正常的，但是不要轻易妥协。
不要浪费测试人员时间。测试人员接到测试任务拿到需测试产品发现低级错误的数量以及功能的不完整性，有权退回。这是在浪费测试人员时间。
测试人员不要过于依赖测试工具
测试人员对测试工具的完全依赖是一种不好的做法，不要忘了最强大的是你的测试思想，在必要的场合采用工具确实能给测试人员带了意想不到的收获但是这只是一种测试手段不能代表测试的全部，如果需要使用工具，我建议往开源方面靠拢。
让测试人员了解产品背后的商业意义
整个项目中什么功能模块是最重要的，为什么要开发这个新功能，这个功能在整个项目中有何种意义，这可以让测试人员对该功能产生一个内心重要级别。对测试用例和以后的回归都起到很大帮助。
