故事PA-4: 作为一名客户,我想知道根据我所选择的货物送达时间,要花多少送货费,这样如果我觉得价格不合适也可以修改送达时间。 |
- l 测试人员:“有哪些送达时间可供用户选择?”
- l 产品负责人:“标准的是5天送达,还有两天送达和次日送达。”
- l 程序员:“我们可以先从只提供一种送达时间做起,算出费用。然后就很容易的实现另外两种方式了。”
- l 产品负责人:“嗯,这样分解任务很不错。”
- l 测试人员:“我们会采用BigExpressShipping的API,根据货物重量和送货地点来计算送货费用吗?”
- l 程序员:“这是最简单的实现方法了。”
- l 成员们出牌了,这位测试人员和以为程序员出了8,其他人都是5.
- l ScrumMaster:“你们俩为什么认为是8呢?”
- l 测试人员:“我们之前从未用过BigExpressShipping的成本计算API,我也不知道它会不会影响我们的测试,比较我们得先找到测试他们这个系统的方法。”
- l 那位出8的程序员:“我同意,我觉得对这个故事来说,测试要做的工作会比开发多不少。”
现在所有成员都同意把这个故事设为8点。
这个评估的工作可能在计划会议之前就做了,所以如果是在很久以前对这些故事做的评估,那么最好让团队成员们再确认一遍之前的评估现在是否仍然合理。因为现在的团队的组成可能已经变了,或者大家都更有经验了,这些因素都可能影响团队成员们对故事的评估结果。
很多时候,对某个故事要进行大量的测试,而编码的工作量却很想,另有一些情况却恰恰相反。所以全面考虑所有的情况是很重要的。
----摘自《敏捷软件测试:测试人员与敏捷团队的实践指南》
----(美)Lisa Crispin 、 Jant Gregory 著
---- 孙伟峰 崔康 译
---- 清华大学出版社