51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 10253|回复: 23
打印 上一主题 下一主题

[原创] 测试人员应该参加需求调研

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-11-6 08:48:08 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
现在有许多测试人员被调去做调研,好多人都说不应该去,这是不对的应该去做,第一可以多学习一点东西。第二可以对程序有更深的了解。何乐而不为!!
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

24#
发表于 2012-8-16 17:00:19 | 只看该作者
我觉得测试人员参加需求调研是扯蛋,,这个事情应该是产品人员去做,测试人员获得需求的路径应该是从产品那里来的。如果非要把这个搞的这么混乱的话只能说你们公司岗位职责不清晰,会出问题。
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2012-8-13 18:51:21 | 只看该作者
及早参与,及早发现问题,对需求可以从测试角度理解问题!
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2012-8-9 14:29:30 | 只看该作者
我们现在也面临这个问题,只是没经验,估计去了也提不了什么建设性的意见
回复 支持 反对

使用道具 举报

该用户从未签到

21#
发表于 2010-11-22 20:07:39 | 只看该作者
关键是成本
调研是要占人时,花差旅的
如果需求足够精细,就不必调研了
回复 支持 反对

使用道具 举报

该用户从未签到

20#
发表于 2010-11-18 22:35:19 | 只看该作者
其实参加调研是对一个测试人员有比较高的要求的。
测试人员要有比较高的总和能力和理解沟通总结的能力才能发挥好的效果。要不然对于测试来说去了也是浪费时间。
回复 支持 反对

使用道具 举报

该用户从未签到

19#
发表于 2008-11-26 10:31:37 | 只看该作者
同意楼上的观点,受教了!
我往往把需求调研、需求分析、需求评审混作一谈,现在进一步意识到这些区别。
测试人员为了更好地进行测试,需要参与到需求阶段的工作中,但应在需求评审阶段介入。在需求调研阶段介入的确会有楼上所说的问题。

至于为什么会由测试人员介入调研,我猜想是不是有这样的客观原因:
测试人员在一些企业往往带着点文职工作的形象,可能是想让测试人员做需求调研中的一些文字工作。实际上想用的是测试人员的人力而不是测试人员本身的能力。
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2008-11-25 20:42:13 | 只看该作者
对于需求调研, 这个一个过程产生的是CRS, 主要是从用户的角度用用户能理解的词汇描述需求, 包括用户想要什么以及为什么想要, 这应该是需求调研要做的事情. 至于谁应该去做的问题, 可能国内外有比较大的分歧, 国外在产品开发过程中都有严格的角色定义(过程中的角色需要做什么事情, 如何做, 输出什么), 而国内几乎都是项目经理一脚踢(既做CRS, 又做SRS, 既做设计, 又做coding), 在这种一人担任多个角色的情况下, 往往会出现这样一个问题, 就是各种子过程混在一起, 输入输出不明确, 项目监控过于困难. 至于测试人员是否应该参与需求调研这个问题, 我觉得, 如果测试人员具备了需求开发工程师的能力, 鼓励去做调研, 如果不具备, 还是在SRS评审会议时介入比较好, 这个的理论依据: 项目的启动是从SOW的下发开始, 而测试活动的介入是从SRS开始(如果说错了, 请大家纠正), 实践依据是测试人员具备了多年的测试经验, 在脑海里会积累了大部分的技术概念以及词汇, 在与实际客户沟通的时候, 可能会存在较大的障碍, 比较难引导客户将出显示或隐式需求(毕竟不是做需求开发出身). 在SRS的评审阶段, 测试人员可以对SRS进行review, 从用户的角度进行理解和分析, 找出问题后, 让需求开发人员汇总并与客户确认, 形成一次完整的需求开发迭代. 打个比方, 如果测试经理参与到需求调研过程中, 那意味着CRS的完成是有测试参与参与的, 那么在SRS评审的时候, 就会少了一道验证(缺少了测试经理本身应该具有的评审效力, 三方评审少了一方).

总结一下, 鼓励有志愿向需求开发转型的测试人员参与到需求调研过程, 不提倡测试人员参与到需求调研过程中.

可能上述陈述有部分言语冒失或错误的地方, 请大家包涵.

Thanks in advance.
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2008-11-22 13:51:42 | 只看该作者
应不应该去和能不能去,有没有这个条件去,又是另外一回事。
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2008-11-19 17:17:00 | 只看该作者
同意楼主的说法,但郁闷的是,因公司小,测试三个,但谈需求的时候从来不带上我和另外一个测试,但测试的时候却让我们测,以至于我们要一边看需求一边测,
回复 支持 反对

使用道具 举报

  • TA的每日心情
    慵懒
    2016-4-26 13:27
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    15#
    发表于 2008-11-13 17:31:40 | 只看该作者
    就看给多少钱了!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2008-11-13 15:21:21 | 只看该作者
    我所在的公司有时候也会有这种情况发生。调查到后来总是会发现这是在更新需求的时候没有及时地与QA沟通所造成的。
    要解决这种情况,我想利用文件服务器会是一个比较好的方法。把文档放到统一的地点,这样大家就能够比较及时且统一地更新需求了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2008-11-13 15:16:31 | 只看该作者
    我觉得测试人员应该去了解需求,更准备地说应该是了解需求的“总结”,而不是去参加需求调研这个过程。诚然参加调研这个过程可以让QA更早并且更确切地了解客户需求。但是要求不具备专业知识的QA去做这样的事情,我感觉对于公司来说是入不付出的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2008-11-13 10:47:14 | 只看该作者
    去是应该去,可是真正参加的很少啊,我们测试不了解需求,有的时候提bug开发就会说“需求如此”,很是气愤啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2008-11-7 16:34:50 | 只看该作者
    测试人员是应该去参加需求调研了,这样会对后续的测试工作有很大的帮助,也可以减少后期的沟通成本!强烈建议!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2008-11-7 10:23:41 | 只看该作者
    我觉得测试人员是否应该参与到需求调研,这不是问题。
    问题是测试人员参与到需求调研,应该如何做?是一个方法问题。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2008-11-6 22:40:07 | 只看该作者
    实施律很低应该说.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2008-11-6 20:15:51 | 只看该作者
    肯定应该去啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2008-11-6 10:31:08 | 只看该作者
    一般来说,在大公司,“需求调研”都由专门的需求分析人员去做。目前国内很多企业,都没有单独的需求分析人员,一个人干多个人的事情,我觉得如果有时间,我建议测试人员参加需求调研,这样对需求了解会更深刻,是好事情,鼎立支持!!!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    6#
    发表于 2008-11-6 10:27:16 | 只看该作者
    建议参加需求调研,如果实在不能参加,就参加业务说明会议或是需求评审会议。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-26 05:50 , Processed in 0.090034 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表