今天一同事在找产品验收需求时候，发现产品和测试与开发的理解不一致，导致这个版本功能白做了（没有达到需求的目的）；测试与开发一致认为产品的需求没有写清楚，作为旁观者的我觉得这并不是一个产品需求没有写清楚的问题。
如何做到测试与开发的理解与产品对齐：
- 最开始接触需求内容的时候是产品的需求评审上，我们大家对需求有个大致的了解，可能每个人对需求有着自己的理解，有问题尽量在需求评审时候提出，因为后面可能就忘记了这个事情；
- 在测试设计测试用例时候，根据测试用例的设计方法（比如等价类、边界值、场景法等等）全面的设计出自己的测试用例，并且标记出有疑问的地方；然后组织会议拉上对应的产品、开发进行测试用例评审，在会上大家再次对需求进行了理解和业务的梳理，针对性的提出问题，对测试用例有问题的地方进行统一；
- 不是说测试用例评审就能够全部解决问题，有可能对需求的不断加深理解，产生了其他的需要讨论或者确认的地方，这时候就需要我们测试人员执行以下动作：
- 有问题就和产品确认需求，慢慢对齐，不断完善测试用例
- 先完善测试用例后，再组织一次测试用例评审
一般介于会议室比较紧张而且占用整片时间比较困难，工作中会采用零散的时间内有疑问就去确认和对齐的方式完善测试场景和用例
备注：
有时候在正式的测试过程中也会遇到这样那样的问题，但大部分都是体验上的问题，这种的优先级就比较低，可以提出来看产品是否需要优化；
还有极少数的问题是影响到当前需求功能的实现或者其他业务线的使用上（实际上很少遇到新功能影响其他功能的），这种可以提高优先级指出来，需要告知产品和开发，一起讨论如何低成本解决掉，如果当前版本没有时间的话，是否需要找个小版本迭代带上去；
延伸：如果以上都考虑到了，理解和意见对齐了，生产上出现了没有预料到的问题，这个其实不能甩锅给测试的，因为这个过程中大家都没有发现或者指出来有问题；但是现实中可悲的是只要有问题就都会甩锅给测试，不管是什么原因，测试没有测到这个问题就是测试的锅~~~
