需求实例化实践-Qecon2021分享总结

需求实例化是测试左移的重要一步，但是并不是做敏捷测试中需要尽早做的一步。虽然大家总觉得要是上来需求不要搞错，不就一了百了了么？然而哪里有那么简单的事情，如果连接近事实真相的最后一步都做不好谈什么左移呢？
听着《夜的第七章》从不在场证明（生产故障）、作案过程工具（持续测试）逐渐左移推倒作案动机（用户需求及愿景）吧。

夜的第七章(KTV版伴奏),周杰伦
在软件交付过程中右移测试往往是最简单实现的，只要在生产端进行和用户相同的操作即可带来质量的证明。这里要解决的无非是对用户环境数据的感染，通过多租户或者标签隔离数据，并且进一步隔离影子数据库。当然这些功能都会在尝试进行“全链路”性能压测的体系下逐渐构建，如果这些都还不能上升到最早开始加强的部分，那么左移的很多实践都不需要进行（因为涉及到的部门和转变更多）。
其次需要在需求实例化前落地的是持续测试。至少保证每一次CI（持续集成）都有基本的覆盖率单测保证，每一次CD（持续交付）都有完整的分层自动化覆盖率（代码、业务）保证。

通过右移测试完成高质量用户交付优化，通过持续测试完成质量基本内建，大多数的测试工作可以从执行回到设计阶段（超过50%的时间回归设计），那么这个时候可以开始深入需求实例化优化设计的上游。

需求实例化

测试设计来自于需求，而需求的可测试性决定了实现及验证过程，尽早的进行需求实例化可以有效的提升交付质量，但是这个有一个前提就是如果需求实例化错了可以很快发现并纠正，否则又会回到瀑布模式中的在自己能力不够的初期过早对交付的软件给出错误的定义。
需求实例化不是去用自己的认知改变PO或者BA对需求的描述方式，在做左移的时候并不是“卷”别人，而是更多从质量角度提供赋能，进一步团队进行敏捷实践。