昨天我作为一个测试人员参与了一次一个小型开发团队（大约7人）集体进行基于用户故事的工作量评估的会议。会前开发人员已经针对每个故事都建好了任务，并估计了每个任务的工作量。会议主要分为两部分。第一部分针对总工作量比较小的故事，直接简要描述故事和任务，参看工作量，而不对每个任务进行现场的工作量估算，进展得比较快。第二部分则针对比较复杂的故事，先简述故事和任务的拆分思路，针对每个任务让有能力对此评估的几个开发人员各自独立选择任务点数，同时翻牌。对于估算结果分歧比较大的任务做进一步讨论，并现场修改新的估算结果。个人感觉整个估算活动还是比较有效果和有效率的。现将自己感受比较深的几点做个简要记录。

　　1、开发团队开展这一活动的好处

　　（1）各自翻牌的方式比较公正、公开

　　　　* 多年前PMBOK里看到的宽带Delphi终于得见在实际工作中的应用了

　　（2）促使每个开发人员及时了解需求细节、尽早考虑设计方案及实现的复杂度

　　（3）有时能及时发现遗漏的任务

　　2、测试人员参加这一活动的好处

　　（1）及时发现可能遗漏的测试点：由于开发人员在考虑任务时对需求的影响面从实现的角度有不少有益的补充，这些补充往往反映到了任务里，但没有更新需求。所以，测试人员在参加这一活动时能拾取这些有价值的信息用于测试活动。例如，需要对老数据打data patch.

　　（2）帮助测试人员对测试风险有更准确的判断：例如，由于重写和复用的工作量不同，当测试人员认为可以复用的逻辑或者界面应该工作量较小的时候，一旦发现开发人员估计的工作量超出预期，就可以和开发人员进行讨论，从而了解看上去类似的逻辑其实处理上有何不同，避免测试人员基于假设错误划分测试等价类。还有一些实现复杂度超出测试人员想象的，包括为什么会如此复杂的一些原因信息，都是测试人员更好地把握测试风险和重点的重要输入。

　　（3）可以站在测试的角度对于开发的优先级发表自己的见解。比如，有些开发简单，但测试却要大费周章。又或者，同样的开发工作量，前台出现缺陷的概率远大于后台，从而测试人员在探索测试和报告缺陷方面的精力也更多，需要更多的测试时间。测试人员如果能在开发做工作量估计的环节就提出这些建议，相信对于后期减少测试瓶颈，提高团队整体效率是比较有益的。

版权声明：本文出自 zdlzx 的51Testing软件测试博客：http://www.51testing.com/?56882

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。