如果说测试是一项团队工作，那么其实现在很多测试团队仍然是内部各自为战，手工测试任务分配后工程师各自按照所分的模块或者需求进入需求理解，测试用例，测试执行。也许唯一能说得上合作的可能是产品线间的接口测试联调，测试用例评审吧。
这个时候测试质量大多数还是靠了工程师的个人能力，一旦存在遗漏，是很难弥补的问题。这种情况很常见，无论如何这不能称之为团队工作。有人会提到用例评审，然而实际工作中由于效率原因，工程师们大多还是仅熟悉自己所负责的部分，这种情况下想给出高质量的评审意见则更像是理论情况。
那么谈到测试策略。手工测试组很多leader并没有真正涉足这部分或者跳过了这部分。经验丰富的测试工程师可以在这个环节给出大量宝贵的意见，甚至直接是错误推测。讨论的过程中大家也了解了彼此的工作范围。这里还有很多东西，在后续的测试前移还会再阐述。比如最简单的例子，不要总是觉得遇到莫名奇妙的环境问题浪费时间，这其实就是在测试策略阶段没有给自己列出来，xx日跟所有代码提交人沟通确认配置文件修改，本次版本内容包含了哪些环境，常用检查方案和顺序是什么？
如何制定测试策略？对于没有接触过这个的团队，我的意见是可以从这几个方面入手。
第一是测试范围，除了需求所列出来的以外，测试组需要借助其他角色的力量以及自身经验寻找可能关联的范围，全组讨论确定加入测试范围。
第二是测试顺序，想一想我们是按照以下顺序进行并引导开发按这个顺序修复的吗？基本主流程到分支流程到异常流程到交互到页面元素吗？
第三是测试重点关注。专门提出部分测试点的重要性会让工程师更加关注这些地方，如果列的过多则起不到效果。举个极端点的例子比如一个小需求可能1个小时就能测试完，但是策略制定的时候发现这个需求的开发和设计都是每个版本必出bug的人，那么我们重点记牢。适当多分配时间。
第四是测试准备。例如打包的应用列表，sql，配置文件等等，又比如各类问题的接口人列表等等。
