昨天和老大讨论了下目前测试的现状，敏捷迭代中，业务需求比较饱和，如果在特定测试开发比下，如何释放测试的精力，又能提交产品质量。回顾下，敏捷研发流程中，测试关注的地方：
1.需求评审
2.设计评审
3.测试方案
4.测试用例编写
5.测试执行
6.参与 codereivew;
7.测试脚本编写；
8.测试回归
9.上线 review；
10.产品验收；
11.上线发布
12.项目复盘；

以上环节，在持续交付的敏捷研发流程中，这样的快节奏流程，如果每个环节测试都参与，往往都做的不精细，不深入；反而生产上线质量下降，测试人员精力疲惫.......

如何解决这类问题，测试左移，左移的目标，肯定是集中测试优势，关注哪些环节必须测试参与，哪些有开发，产品参与；从上面的 12 步骤里，抽象出三部分
1、测试用例开发；-基本能力
2、测试脚本开发；-升级能力
3、QA 质量体系监控；--数据可视化

这两部分才是测试重点关注的地方，但要把 12 部分内容释放出来：分两部分实践：
第一部分：其实有一些团队已经做了实践： showcase, TCDD 等, 协调整个研发团队承担产品的质量；但这个过程是需要测试去推动这种 TCDD、showCase 的落地
。
第二部分： 测试工具开发：测试用例快速生成、接口测试脚本自动生成、测试问题自动识别、测试过程质量数据度量等等，更升入 - 单元测试代码自动生成、代码与业务功能抽象转换；

以上是讨论话题，也是是测试痛苦转换的过程。

车到山前必有路 ->条条大路通罗马-> 柳岸花明又一村。。