浅谈软件测试团队规范建设
条件：
缺陷管理
首先正规测试团队至少会有一个缺陷管理系统，不管是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的工作开展。