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

需求实例化是测试左移的重要一步，但是并不是做敏捷测试中需要尽早做的一步。虽然大家总觉得要是上来需求不要搞错，不就一了百了了么？然而哪里有那么简单的事情，如果连接近事实真相的最后一步都做不好谈什么左移呢？

在软件交付过程中右移测试往往是最简单实现的，只要在生产端进行和用户相同的操作即可带来质量的证明。这里要解决的无非是对用户环境数据的感染，通过多租户或者标签隔离数据，并且进一步隔离影子数据库。当然这些功能都会在尝试进行“全链路”性能压测的体系下逐渐构建，如果这些都还不能上升到最早开始加强的部分，那么左移的很多实践都不需要进行（因为涉及到的部门和转变更多）。

其次需要在需求实例化前落地的是持续测试。至少保证每一次CI（持续集成）都有基本的覆盖率单测保证，每一次CD（持续交付）都有完整的分层自动化覆盖率（代码、业务）保证。

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

需求实例化

测试设计来自于需求，而需求的可测试性决定了实现及验证过程，尽早的进行需求实例化可以有效的提升交付质量，但是这个有一个前提就是如果需求实例化错了可以很快发现并纠正，否则又会回到瀑布模式中的在自己能力不够的初期过早对交付的软件给出错误的定义。

需求实例化不是去用自己的认知改变PO或者BA对需求的描述方式，在做左移的时候并不是“卷”别人，而是更多从质量角度提供赋能，进一步团队进行敏捷实践。

毕竟不同的能力、角色带来了不同的认知和看法。

都没有错，但是我们要的不是争执，而是协同。

关于需求实例化其实行业内已经有很成熟的参考，然而我也忘了写了啥！

关于需求实例化我觉得比较重要的几个实践要点：

1. 让产品给开发、测试讲故事而不是讲需求实现
2. 团队共同确认验收标准
3. 团队流程梳理，明确完成定义
4. 围绕已明确的业务链构建迭代规划
5. 与研发并行的ATDD测试能力

在不断的优化过程中构建质量内建的交付模式，让需求的误差可以快速得到反馈。

等团队的磨合到了一定的境界，这时候可以一起继续左移寻找解决问题的本质问题，而现在是不是做实例化？还是做好持续反馈？这是大家应该考虑的问题！