测试左移和右移

测试左移和测试右移理解

测试的理解：

1、测试在团队中是成本中心，什么叫做成本中心？就是一般从上级的角度，或者从公司高管的角度来看，测试团队里的人越少越好。

2、我们怎样给测试团队争取到更多的利益或者更好的发展前景呢？那就需要我们对老板的认知进行一些拓展：让老板从把测试团队当做一个必须付出的成本，变为认可测试团队也可以带来更多的价值。

就是测试是否一定要等到最后才去做一些必要的检查呢？如果我们只做必要的检查，那么老板愿意在测试方面付出的钱是非常少的。但是如果我们告诉老板说：我们可以把测试往左移、往前推，我们可以帮助产品经理提高所输出需求的质量；让项目中用更少的产品经理，给出更高质量的需求，让用户更加满意——那么这个价值就会大很多。

拉通上级管理的痛点，明确团队的目标 ，既要做好  研发领导沟通，产品领导、项目经理沟通向下团队的沟通【测试领导视界】

沟通的前提不是PK音量，而是拿出事实依据，用数据来分析，聪明的领导都是冷静的沟通。

测试左移测试右移：

对软件产品而言，传统的质量模式通过测试左移和测试右移被赋予更多的内涵，也承担起更多的职责。

■ 测试左移：测试左移，本质上是借助工具和测试手段更早地发现问题和预防问题。

• 需求：对需求、架构和设计模型的测试；
• 开发：着重增加对单元、组件和服务层的测试；
• 持续测试：自动化测试。

■ 测试右移：对测试同学来说，版本上线后需要持续关注线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。

• 灰度发布：新版本线上测试；
• 监控：合理的性能监测、数据监控和预警机制；
• 用户反馈：线上问题处理、跟踪机制。

测试可输出方向：

1. 测试任务跟踪

2. 建立代码分支管理规范

3.代码质量检测

4. 持续测试：基于XX平台实现接口自动化

测试左移的原则支持测试团队在软件开发周期早期和所有干系人合作。因此他们能清晰地理解需求以及设计测试用例去帮助软件“快速失败”，促使团队更早的修改所有的bug。

参与和理解会使测试人员获取产品完整的知识，彻底想清楚各种场景，根据软件行为设计实时的场景，这些都会帮助团队在编码完成之前识别出一些缺陷

有哪些活动可以提高质量上限（举例）：

健康的项目流程（合理并且严格遵守的项目流程）
合理的需求分析（评估需求的质量，分析需求的合理性以及完整性）
出色的系统架构
完整的系统设计（评估设计的质量，分析需求的合理性以及完整性）
充分利用静态代码扫描
进行研发标准的定义
更早的测试分析（先于开发完成需求的分析，做好各种评审的准备）
尽早的测试执行（提早参与测试执行，在集成前就发现一些问题）
有哪些活动可以提高质量下限（举例）：

健康的测试流程
优秀的测试用例
合理的测试计划
合适的自动化
适当的探索式测试
开发自测（TDD、BDD，测试提供更好的用例、技术支持）
团队质量意识的培养
 

对于测试右移，线上监控可以是突破点，举例：

闭环的线上问题反馈-检查-解决-更新流程
更便捷的日志查看、回传服务
丰富有效的log，便于问题的快速定位
丰富的监控指标（例如业务异常点指标）
成本监控（例如短信发送等）
关键指标每日监控（服务器指标）
生产数据监控（警报）（通过sql语句实现生产数据监控，例如是否有多个订单号一样的订单出现等）
因此对于测试右移，我认为可以围绕问题反馈、发现、定位、监控展开，参与人员则不仅仅局限于运维人员