如何在需求阶段发现更多的缺陷

上一篇 / 下一篇 2012-08-20 08:53:22 / 个人分类：测试经验

　　你知道如何在需求评审阶段快速高效的发现高质量的需求问题吗？下面我将第一次公开分享我在工作中所原创的一种需求评审方法－结对需求评审法（在国内国外都是首创）

Wsu-E5j~F;`0　　无论在任何软件企业，都会存在需求评审的环节，在这个环节我们测试人员应该如何发挥更大的质量保障的价值，是很多团队都会尝试的事。因为大家都知道在需求阶段发现问题成本、定位问题成本，修复问题成本最少。要提升整个研发的效率，减少返工浪费，最好能在需求环节尽早发现需求问题。如何快速容易的发现需求的问题，软件测试业界其实一直苦于缺乏高效的实践方法。51Testing软件测试网&jN-j1?+P `8B

JZ7Kx*s:y9r4DR0P0　　09年时我也曾经接到过这样的一个任务：如何进行早期测试？如何进行缺陷预防。其中必须解决的一个问题就是：如何提高测试人员在单位时间内发现的有效需求问题数？虽然我们知道需求的质量也是有维度的：二义性、可测性、完整性、前后一致性、可实现性、必要性。我们应该从这些维度来发现需求问题，其中最主要的是二义性问题。但这只解决了What的问题，应该如何解决How的问题，如何发现这些类型的需求问题，就是测试技术或测试方法需要填补的空白。51Testing软件测试网-jYB?gH

[lav:fme0　　现在有两套方案推荐给大家：51Testing软件测试网 Ln'YD9~

　　方案一：Richard Bender的RBT基于需求的测试。

*tH;n3?(l XD:XhB {r0　　方案二：我原创的DZ结对需求评审法

　　如果你担心用得方法听起来太简单无法体现技术含量，而希望用复杂的过程及方法来体现技术的高精尖，你可以选择方案一；51Testing软件测试网0y%y;q6R-pEt

　　如果你希望用简单快速高效，不介意别人说你方法太简单的可以选择方案二。51Testing软件测试网t'MI H%`t

F}(?8zI0　　下面主要分享DZ结对需求评审法

0hq/te2t1{8bx6F0　　这个方法是我09年时与一位叫周博的同事，一起实践发明的。针对需求中问题数量最多，也最严重的二义性问题，体会到很难通过传统的评审会形式快速发现，而且发现效率也低。正好当时大产品团队正在实施结对编程（只对着一台电脑，一人写代码一人review代码）。我受此启发，某日灵感一现：想到结对需求评审这种形式。于是拉上周博同学，一起进行实践，实践方法如下：

　　1、两人只对着一台电脑、由1人作为引导员来操作电脑，记录评审结论

　　2、引导员控制时间节奏和维持结对需求评审的规则，两人针对每条需求，逐条进行固定时间窗（1－3分钟）范围内的理解

f-kwkm!mmCj+KA0　　3、2位评审人在单个需求的理解时间到时，直接说出每人对这条需求的理解。如果两人理解一致，就直接看下一条需求；如果理解不一致，不能进行讨论，而是由引导员直接记录下两个人的不同理解内容，这时说明这条需求至少已让2个人产生了二义性的理解，需求存在二义性问题。

　　关键技术活动点的理论支撑：

　　1、一条需求（1－3行文字）如果需要你使劲思考和理解5分钟以上还不能准确说出其描述的本意，那么已说明这是一段容易让人理解出错，容易产生二义性问题的文字描述；

　　2、如果一条需求已至少让两个人产生两种不同观点，那么就可能让更多的人同样产生二义性理解问题；

　　影响结对需求评审效果的关键：

E1g p*{#V9m0o[6_oL0　　1、多练习。对于方法的初次使用者，建议第一次先用1小时拿需求文档进行练习熟练后，再在正式的需求评审项目中进行使用（提高效率）。

　　2、参加需求评审的2名测试人员应该先了解过产品的背景和历史，才参与结对需求评审活动。（提高效率和产出质量）

)~r1|k;K M+C5W0HJzY0　　参考投入产出比：

　　某项目用2小时发现40多条需求问题；

PR k['\0　　某项目第一次练习应用20分钟发现4条需求问题；