敏捷实践 测试左移 - 测试过程左移
昨天和老大讨论了下目前测试的现状，敏捷迭代中，业务需求比较饱和，如果在特定测试开发比下，如何释放测试的精力，又能提交产品质量。回顾下，敏捷研发流程中，测试关注的地方：
1.需求评审
2.设计评审
3.测试方案
4.测试用例编写
5.测试执行
6.参与 codereivew;
7.测试脚本编写；
8.测试回归
9.上线 review；
10.产品验收；
11.上线发布
12.项目复盘；
以上环节，在持续交付的敏捷研发流程中，这样的快节奏流程，如果每个环节测试都参与，往往都做的不精细，不深入；反而生产上线质量下降，测试人员精力疲惫.......
如何解决这类问题，测试左移，左移的目标，肯定是集中测试优势，关注哪些环节必须测试参与，哪些有开发，产品参与；从上面的 12 步骤里，抽象出三部分
1、测试用例开发；-基本能力
2、测试脚本开发；-升级能力
3、QA 质量体系监控；--数据可视化
这两部分才是测试重点关注的地方，但要把 12 部分内容释放出来：分两部分实践：
第一部分：其实有一些团队已经做了实践： showcase, TCDD 等, 协调整个研发团队承担产品的质量；但这个过程是需要测试去推动这种 TCDD、showCase 的落地
。
第二部分： 测试工具开发：测试用例快速生成、接口测试脚本自动生成、测试问题自动识别、测试过程质量数据度量等等，更升入 - 单元测试代码自动生成、代码与业务功能抽象转换；
以上是讨论话题，也是是测试痛苦转换的过程。
车到山前必有路 ->条条大路通罗马-> 柳岸花明又一村。。
柳暗花明又一村
道理我都懂，做起来就不是这回事了
TCDD 是啥？第一次听。
...产品参与；从上面的 12 步骤里，抽象出三部分
1、测试用例开发；-基本能力
2、测试脚本开发；-升级能力
3、QA 质量体系监控；--数据可视化
这两部分才是测试重点关注的地方，但要把 12 部分内容释放出来：分两部分实践：
是有错别字么？一会两部分，一会三部分，表示没看懂。然后这个抽象也没懂，12 个步骤怎么能抽象成这 3 个部分。
1、TCDD: 测试用例驱动开发，但对测试要求比较高，也是老大力推的一个概念。百度不出来这个关键字；
2、抽象出三部分，前两部分是测试重点关注的；这块笔误。
3、抽象成 3 部分 - 其实从需求评审到发布上线， 在敏捷开发过程中，其实考验的是测试的基本功和测试脚本转换能力，划分的 12 个部分，只是我们象征性要参与这么多事情。本质上，测试需要贡献的价值： 质量和效率.....，这块跨的步子有点大，后面把思路拆小点。🙏
feidou1113
回复
TCDD（测试用例驱动开发）这个新概念，可以扩展说下具体是什么意思么？和 TDD、ATDD 这些有什么不同？学习学习下
然后你这两个部分，感觉相比前面的 12 个步骤，会不会有点过了？。需求质量、代码质量在你抽象后都没了，这个我理解应该是你标题说到的 测试过程左移 的核心之一。
陈恒捷
回复
尝试谷歌了一下 test case driven development，搜不出这个概念，老外似乎也不这么叫，应该就是楼主公司的内部叫法，结合上下文猜测就是说 TDD 吧
“然后你这两个部分，感觉相比前面的 12 个步骤，会不会有点过了？。需求质量、代码质量在你抽象后都没了，这个我理解应该是你标题说到的 测试过程左移 的核心之一。” --这个话题想表达，站在 2/8 原则的角度，测试应聚焦自己的专业能力，然后又遐想了一下
。左移的目标，其实就是将测试手中的工作释放，团队对质量负责，杜绝保姆式工作，12 个步骤具体做哪些事情，是质量体系建设的工作、后续可以再总结下