营造测试气氛
开发人员开发完功能后需要自测，然后再交送给测试人员，共同把好质量关。开发可能会说我写出来的东西我自己还要测试那还要你做什么。如果开发的产品连正常流程都无法跑通就交给测试被一次一次的打回，这样不光影响项目进度，还可能会导致该测试人员会你开发出的产品有情绪抵触，质量很难得到保证。
测试技术学习
测试团队可以定期拿出一个课题由部分专人负责研究，然后定期Share研究成果组织团队人员研究讨论，促进工作学习两不误。
测试人员不够
如果碰到时间紧任务重测试周期被缩短的情况。我不建议省略写测试计划，测试用例，测试报告去闷头测试。测试可以分轻重，可以申请安排开发做辅助测试。也不能省略那些书面文字。不是走形式。测试人员要彻底认识到这些东西是非常有价值的，在适当时候可以保护你。
先写测试用例再测试不是死规矩。事实上应该是这种工作流程，但是有些时候当没有测试用例思路时，可以先手工运行一遍功能，想到什么写什么，最后形成完整规范测试用例。做到灵活测试。
测试人员有义务向PM阐述对功能的流程以及易用性方面自己的想法。如果是为了功能的可伸缩性那就不仅仅是测试人员需要参与讨论有可能还有PD OP DB等等。最初目的是为了以后如何更方便的开展自动化。让自动化能覆盖的更多更全面。
为了保证产品质量测试越早进行越好。不仅是功能测试，其中也包含性能。
了解当前产品质量
测试人员每个人都应该了解当前产品质量，知道哪块薄弱，知道自己该干什么，提倡每个人都可以提出建设性意见。
开发人员告诉测试人员你应该如何测试。
这种现象可以从多方面理解：
1、作为测试人员你做的不够好，长时间来你充当一个喊话筒的角色，从你以往提交的Bug来看没有任何深度。想受人尊敬受人重视还是要靠自己踏实争取。
2、测试团队不规范，或者说根本就没有测试团队。让开发领着干活自己又不会写代码心理不好受抱怨多多。
更多时候还是需要自己多努力，知识要靠一点一滴的积累。很难重现的Bug你能重现，能告诉开发哪块功能将来可能产生问题，指出系统瓶颈等等类似很多。这些都是需要经验积累。渐渐的你会发现自己在团队中起到了应有的价值得到同事以及上司的认可。
测试环境维护
测试环境由谁来维护其实我觉得并不重要，这里指的谁可以是运维可以是研发可以是QA，但是最好要保证专人来维护，不要谁都可以插手。再没有打招呼的前提下擅自发布新功能或者修改是不可取的。保证版本的统一性很重要。要做到正式发布功能之前OP可以在测试环境下抓取项目整包进行发布。当然对于极小功能小修改可以例外。
收集需求文档
测试人员为了写出一份还算完整的TestCase东奔西跑到处收集信息。开发文档和产品需求文档出炉后请第一时间送交的QA 手里，保证QA的工作开展。
