我们大家都生吃黄瓜
我是不是可以熟吃黄瓜?
嘿嘿。
其实看任何问题都可以从他的GAOL触发。
测试人员为什么要参加需求开发?
1、因为我们的角色界面不完全清晰,在这种情况下
某些设计思想不能仅仅通过文档进行传递,也许大家尽早的介入这件事情,
有利于设计思想的传递;
2、某些业务领域可能是测试团队没有接触过的,需求开发的过程其实也是一个学习业务的过程。
特别是某些复杂的业务逻辑和业务规约;
3、测试人员验证的是啥?测试人员就是验证需求的。
测试人员参加需求开发,可以保证需求的可测试性,
另外也可以从测试人员的敏锐视觉中识别需求开发中的异常,
从而尽早的发现缺陷; 公司领导正打算从需求分析开始就让测试介入,以便更好写测试用例。 参加比较好 条件允许的话,参加更好! 是啊,我也觉得参加比较好,有以下好处:
1,在和客户调研过程中的交流沟通,是一个很好的理解熟悉整个系统的方法,而且能非常熟悉系统是怎么运作的,用户关注的主要功能在哪些地方,那么在测试时就可以有的放矢.
2,光靠阅读开发团队提供的需求文档,肯定是不如更用户交流沟通形成的文档来的深刻,来得清晰.因为开发团队经过理解写出来的东西,跟测试人员理解的不完全一样.
3,业务逻辑的理解,只有跟使用该业务的用户交流,才是最正确的理解. 但我们公司,不可能这样做,因为公司舍不得开支.另外就是测试人员少的可怜.
应该参加
测试人员是应该参加的,确切来说测试人员应该主要负责,然后整理出需求文档,SA根据需求文档来做系统分析。只是目前很多公司出于很多考虑没有这样做而已测试人员的参加,会使测试用例错误覆盖率更高。 能参加那当然最好了,一般来说,越接近客户那么组织的测试用例也就会越有效 我们公司测试员是需要参加的 我们公司是不可能参加的!sdlkfj8 条件允许,当然时参加的好啊 需求调研应该是开发人员的事啊 测试人员应该介入的~
比较能了解客户真是需求
也是对需求测试的依据 原帖由 jkdragon 于 2007-4-16 20:08 发表 http://bbs.51testing.com/images/common/back.gif
需求调研应该是开发人员的事啊
不是开发人员的事情
是需求调研负责人和架构组的去弄的
如果没有需求负责人就应该是pm去把握
开发人员要去也是派代表列席 有问题回来讨论
当然参与的测试人员也基本不参与调研时的提问与回答工作
学习
参与的越多当然是越好的,至于实际情况,还是需要衡量利所占的比例. 当测试人员不清楚需求时,他能够提出有效的改善方案吗?客户可能存在某种需求,但是无法给出鲜明的表达,这时我想需要测试人员进行引导。 这也是个增长知识的过程
对于新人,倾听还是很重要的. 我们公司还有一个BA的角色,business analysist,这个人会主要的负责跟business沟通需求,整理需求,然后开发跟qa会在需求分析阶段跟BA频繁的沟通,开发根据需求写FS,qa会根据需求写出相应的test requirement 测试活动是从开发一直到交付都有的活动,对于accepte test,validation 这样的测试活动,测试人员早期参与,也可以节约后期的开支