51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2576|回复: 18
打印 上一主题 下一主题

[原创] 谈谈测试人员和客户之间的问题

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-8-23 16:08:38 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
在不少公司在项目过程中都会碰到测试人员和客户直接交流,难免都会碰到一些难缠的客户,这种情况下你们会如何处理呢?他们又都问了什么问题呢? 大家拿出来分享下吧~~~
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-8-23 17:48:07 | 只看该作者
你这个问题比较广,比较难回答。暂时我也没碰到过,关注下别人回答的结果。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-8-23 21:38:34 | 只看该作者
测试干嘛要和客户叽歪
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2009-8-23 21:44:37 | 只看该作者

回复 3# 的帖子

客户支付钱娉请你测试,难道就不要和客户沟通吗?
不过这个是说针对有些项目需要和客户有communicate,比如说你的用例可能需要客户去review等等,中间一定会有些客户不理解的等等.
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2009-8-23 21:58:34 | 只看该作者
哦,是测试外包么?客户付钱就是买测试服务,还是买软件?
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2009-8-23 21:59:15 | 只看该作者
up!up!up!
比如说客户觉得你的用例设计思路不符合他的思路,而且你已经写了上百个的case了,现在和你说不符合,你启不晕死了!
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2009-8-23 22:07:02 | 只看该作者
如果给客户提供的是软件,干嘛要和他review自己的测试用例。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2017-9-20 12:50
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    8#
    发表于 2009-8-24 09:45:52 | 只看该作者
    我没有直接和客户沟通过,但是有一次客户看了我的一个用例说我写的不全面,让开发(负责项目的)拿回来让我重写,我就和开发说,我全分开了,他不能只看一两点就说写的不全之类,我和开发列出来,然后他直点头,我说哪你让他们提出来吧,提出来我改,结果也没有提,就不了了之啦
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2009-8-24 09:49:09 | 只看该作者
    我们遇见过这么一回事
    客户要做1000人的并发性能测试,但实际上我们通过之前的业务量的分析在做性能测试策略的决策的时候,发现这个是不可能存在的,于是就跟客户沟通,但客户就是要做,最后我们只能请市场出面协调
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2009-8-24 11:19:41 | 只看该作者
    我们原来都是做的政府机构的网站。为了沟通方便或者说得更直白些,就是为了给开发省事,就由测试于客户进行直接联系的!!
    我们主要是对于客户在看过系统后、类似于β测试的时候,了解他们的需求变更问题的收取及回馈!
    感觉每个项目下来,系统都跟刚开发的时候变动了好多好多!面目全非了!!
    而且不懂装懂的客户最让人头疼!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2009-8-24 16:39:51 | 只看该作者

    令人头疼的客户常见,但是能够摆平这种客户的测试人员却不常见!

    其实有一个观点要实现明确。不论是开发人员还是测试人员,与客户接触,只有一个工作,就是需求调研。不论是讨论如何实现,还是以哪种形式展示,或者用什么样的测试方法,达到什么样的测试标准,归根结底就是需求问题。
    解决这些问题,就看你的需求调研能力的强弱了。
    做需求调研工作有一个前提是必须明确的,即:用户可能知道他的需求,也可能不知道他的需求,就是存在明确的需求以及隐藏需求之分。这个时候就需要需求调研人员通过与客户的交流,深入挖掘出用户的潜在需求,同时得到用户的认可。
    不要企图将计算机行业规范或思想强加于客户,这样只能让事情变得更糟。用户仅仅是该行业的业务专家,绝不是计算机行业的专家。要想说服客户接受你的观点,只能是你先接受用户的观点,之后,站在该行业内部的原则基础上,用行业内部的标准来说服客户。这个时候,客户本身就有了判别能力,在这个时候你告诉客户你打算如何解决这些问题,一般都能够得到用户的支持的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
     楼主| 发表于 2009-8-25 12:43:59 | 只看该作者

    回复 7# 的帖子

    是的,我也碰到过,其实客户不怎么会去看用例的我觉得.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
     楼主| 发表于 2009-8-25 12:52:11 | 只看该作者
    大家都发表发表吧,在实际工作中,我们可能碰到很多问题,这些问题都会让怎么很郁闷,比如我今天碰到的一个问题:客户也在提BUG很多时候她提的会和我提的重复,这个时候你会告诉客户说请你每次提BUG的时候先看下是否已经重复了或者让她提BUG之前应该怎么怎么的?
    其实这样那样的问题多了去了,客户给了钱,买的确实是我们的服务,她提了BUG可能是基于更全面,但是这样会给我们自身也带了不便.重复,重测试,等等
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2009-8-25 16:52:09 | 只看该作者

    回复 13# 的帖子

    如果你的先提交了,并且客户跟你提的问题一样的话,可以将客户的问题resolve掉,然后将状态设置为duplicate,再注明与之前的那个问题重复了。

    如果优先级有差异的话,可以通知项目经理调整优先级。

    但是如果有差异(需求变更),那可以将你之前的问题关闭然后以他的为准。

    [ 本帖最后由 123ewq321qwe 于 2009-8-25 16:53 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2009-8-25 17:06:07 | 只看该作者
    原帖由 cdxfujian 于 2009-8-25 12:52 发表
    大家都发表发表吧,在实际工作中,我们可能碰到很多问题,这些问题都会让怎么很郁闷,比如我今天碰到的一个问题:客户也在提BUG很多时候她提的会和我提的重复,这个时候你会告诉客户说请你每次提BUG的时候先看 ...

    客户干嘛要去看你们提交的bug?客户只管提出他们认为有问题的地方。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
     楼主| 发表于 2009-8-27 12:43:22 | 只看该作者

    回复 14# 的帖子

    我们有QA的经理,所以我认为这个应该是leader来做的,而不是测试人员,你觉得呢? 还有就是很多时候我们并没有太多的时间去关注或者说去留意客户所提出的BUG.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2009-8-27 14:47:46 | 只看该作者
    该忍则忍 要是有很难缠的BT 就绕圈子
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
     楼主| 发表于 2009-8-29 21:52:02 | 只看该作者
    原帖由 41832990 于 2009-8-27 14:47 发表
    该忍则忍 要是有很难缠的BT 就绕圈子

    我不同意面对不合理的工作就要忍,应该提出来的,不是吗?所以大家的意见呢?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2009-8-31 18:29:36 | 只看该作者
    不合理的工作就应该要提出来,但是如果在提出的同时给予一定的解决办法,我想效果会更好
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-27 23:53 , Processed in 0.083549 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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