不想干掉leader的测试，不是一个积极的好测试。
每一个测试小白，都是从基层做起，成为leader之前要先成为一个优秀的测试工程师，优秀的测试能够在日常工作中年不断累积经验，及时反思总结，为自己将来能够成为一个合格的Leader打下基础。
如何提高团队配合默契度？
Leader需要具备的潜质很多，其中之一就是：如何提高团队配合默契度？
在开始如何提高团队的配合默契度之前，先了解下测试工程师在日常测试过程的活动范围。在日常测试工作中测试工程师需要贯穿整个团队，上对产品，下对开发。除了给开发提代码缺陷外，也需要给产品提需求设计缺陷甚至用户体验优化建议等。
下图粗略的对日常测试提交的缺陷按“面对对象”进行了分类，可以分为三大类：（个人观点，仅供参考）
- 用户体验：从用户使用产品的角度提出体验相关的建议
- 优化类型：产品需求设计缺陷或不完整
- 代码漏洞：开发代码设计缺陷
1、用户体验
针对需求文档未明文规定，开发未设计或自主发挥设计的细节功能，测试工程师从用户体验角度出发提出优化体验建议。
该类型的缺陷的规范化处理流程如下：
*确认结果优化*
*确认结果不优化*
2、优化类型
针对需求设计缺陷或设计不明确且影响功能逻辑的，给产品提交设计优化类型的缺陷。
产品针对该类型的缺陷的规范化处理流程：
3、代码漏洞
开发人员在代码逻辑不符合需求设计时产生的缺陷，统一归类为【故障】。
该类型的缺陷的规范化处理流程如下：
4、规范化工作流程
新人入职时，需要及时掌握团队的协作方式，以便于快速融入团队，且在日常团队协作过程中，需要彼此磨合逐步约定规则，才能快速提高合作默契度。以下为个人在工作过程中与团队形成的协作规范，可供大家参考：
1）针对产品
在开发阶段，经由测试人员提出的需求疑问确认结果，要及时同步给开发，并更新需求文档，保证“信息同步，节约返工成本”。
2）针对测试
- 用例评审阶段
在开发与产品同时在场的情况下突出评审重点，提高评审质量，增强开发和产品对测试用例的重视。
a) 当面确定需求会议之后变动的需求内容
b) 着重提醒开发需求理解易出现歧义的地方
- 测试阶段
提交缺陷时，尽可能一步到位提交缺陷内容，减少开发和测试沟通成本，提高开发修复缺陷效率。
- 图+文+日志描述
- 提供前置条件：账号/异常数据信息
- 提供调试数据：备用可供开发修改缺陷进行调试的测试数据
3）针对开发
在测试阶段，开发修复缺陷后需要在缺陷上注明相关内容，确保测试验收顺利，提高工作效率和产品质量。
- 缺陷原因/影响范围
- 已修复时间/版本
- 已修复缺陷及时指派给对应的测试人员，以便测试进行代码部署之后验收回归测试
减少沟通成本，节约工作量。
5、总结
测试工程师在整个团队中，可以说是食物链的底层，也可以说是食物链的顶端。当产品出现缺陷，第一个被问责的就是测试工程师，这就是食物链的底层。
当决定是否能满足上线标准，以及跟进产品进度时，首选是测试工程师，这就是食物链的顶端。（这是当前很多公司里面的普遍现象，仅代表个人感触~）
所以作为一个测试工程师，除了找~找~找BUG之外，还需具备及时反思、善于总结制定工作流程规范等额外的超能力，及时调整与团队其他成员之间的协作流程，改善团队默契度，减少沟通和返工成本，提高工作效率，为将来成为一个合格的测试Leader打下基础~
源自公众号 自动化软件测试