QA人员需要知道最原始的需求，以便判断bug对客户的影响程度，从而决定产品是否具备上市的条件

好像说黄瓜可以减肥
我们大家都生吃黄瓜
我是不是可以熟吃黄瓜？
嘿嘿。
其实看任何问题都可以从他的GAOL触发。
测试人员为什么要参加需求开发？
1、因为我们的角色界面不完全清晰，在这种情况下
某些设计思想不能仅仅通过文档进行传递，也许大家尽早的介入这件事情，
有利于设计思想的传递；
2、某些业务领域可能是测试团队没有接触过的，需求开发的过程其实也是一个学习业务的过程。
特别是某些复杂的业务逻辑和业务规约；
3、测试人员验证的是啥？测试人员就是验证需求的。
测试人员参加需求开发，可以保证需求的可测试性，
另外也可以从测试人员的敏锐视觉中识别需求开发中的异常，
从而尽早的发现缺陷；

公司领导正打算从需求分析开始就让测试介入，以便更好写测试用例。

参加比较好

条件允许的话,参加更好!

是啊,我也觉得参加比较好,有以下好处:
1,在和客户调研过程中的交流沟通,是一个很好的理解熟悉整个系统的方法,而且能非常熟悉系统是怎么运作的,用户关注的主要功能在哪些地方,那么在测试时就可以有的放矢.
2,光靠阅读开发团队提供的需求文档,肯定是不如更用户交流沟通形成的文档来的深刻,来得清晰.因为开发团队经过理解写出来的东西,跟测试人员理解的不完全一样.
3,业务逻辑的理解,只有跟使用该业务的用户交流,才是最正确的理解.

但我们公司,不可能这样做,因为公司舍不得开支.另外就是测试人员少的可怜.

测试人员是应该参加的，确切来说测试人员应该主要负责，然后整理出需求文档，SA根据需求文档来做系统分析。只是目前很多公司出于很多考虑没有这样做而已
测试人员的参加，会使测试用例错误覆盖率更高。

能参加那当然最好了，一般来说，越接近客户那么组织的测试用例也就会越有效

我们公司测试员是需要参加的

我们公司是不可能参加的!sdlkfj8

条件允许，当然时参加的好啊

需求调研应该是开发人员的事啊

测试人员应该介入的～
比较能了解客户真是需求
也是对需求测试的依据

引用:

原帖由 jkdragon 于 2007-4-16 20:08 发表
需求调研应该是开发人员的事啊

不是开发人员的事情
是需求调研负责人和架构组的去弄的
如果没有需求负责人就应该是pm去把握
开发人员要去也是派代表列席 有问题回来讨论
当然参与的测试人员也基本不参与调研时的提问与回答工作

参与的越多当然是越好的,至于实际情况,还是需要衡量利所占的比例.

当测试人员不清楚需求时，他能够提出有效的改善方案吗？
客户可能存在某种需求，但是无法给出鲜明的表达，这时我想需要测试人员进行引导。

这也是个增长知识的过程
对于新人,倾听还是很重要的.

我们公司还有一个BA的角色，business analysist，这个人会主要的负责跟business沟通需求，整理需求，然后开发跟qa会在需求分析阶段跟BA频繁的沟通，开发根据需求写FS，qa会根据需求写出相应的test requirement

测试活动是从开发一直到交付都有的活动，对于accepte test，validation 这样的测试活动，测试人员早期参与，也可以节约后期的开支