遇到这样的开发人员，我该怎么办呢？

江潭素月

心情很不好...
怎么会有这样的主管？整天就这一句“客户不会这么操作的！”
今天有个问题，关于单位的选择，列表中有面积单位、质量单位、周期单位等等（如下图），我感觉像“面积单位”这样的是不应该被选中的。因为它们并不是实际的单位，只是个根节点。我把这个提交bug了，建议修改，因为之前其他项目中已经有类似的修改，参考一下就可以了。结果主管给我说，这个用户会根据需要选择的，过滤没意义。还说我是钻牛角尖。其实他暂时不修改也无所谓，但总是说“用户不会这么操作的，用户知道怎么做，没必要做限制”，如果用户都知道怎么做，电话格式、email格式、特殊字符、最长字段的限制等等都不用验证了。然后我就说得站在客户的角度做测试，客户什么样的操作都有可能做。然后他说我“不要从一个小问题就上升到测试的重要意义上去,太深刻,太尖锐了,太文革了...”
很无语，本来想继续给他说说来着，想想还是算了，毕竟人家是主管，胳膊拧不过大腿，万一惹急了人家，不自己找麻烦吗?
我就很纳闷，怎么会有这样的领导，普通开发人员这样说也就罢了，你一个项目负责人还这样，公司的产品质量可是靠你在把关啊...
我不知道该怎么办？按他说的办？像这样的人家认为客户不会犯的问题不提了？还是给他写个Email说清楚呢？

liangshi

我感觉很有趣：m/s是速度单位，不是面积单位；m^3是立方米（体积单位），也不是面积单位。开发主管是打算让用户从速度单位、体积单位、s/m（我看不出这是什么单位）中选出面积单位吗？如果这就是他的设计，我“代表”用户说一句：这个软件做得太烂了。

你的原始主张：“软件应该先排除无效的值，再让用户选择”是正确的。如果用户选择“面积单位”，会导致后台计算时发生异常，而这样的异常是可以避免的。

我的建议是将这样的问题提交到Bug管理系统。开发人员可以拒绝修复，但是测试人员从职责出发，应该记录自己发现的问题。把这个问题和开发人员说清楚：我的职责是报告问题，我希望能得到修复，你可以有不同意见。

对于没有质量意识的主管，不要与他较劲，不值得。可以考虑换一个部门或企业。如果他不重视你的工作，从长期看，对你的职业发展不利。

Jackc

四个字：做好本份

该提的Bug提了，该说的风险也说了，改与不改，确实不是测试员决定的。

上层说不改就不改了呗，其实有时候我觉得测试员闹着开发改Bug属于越权……那是error manager或PM的职责范围……

sakuna

顶楼上的一下
有一句话叫屁股决定脑袋，对于同样的一个问题，每个人看法肯定不一样，对于有的问题，PM不以为然并不奇怪，但是要记住一点，测试的立场不能丢
现实中，总是有公司不注重用户体验的，换句话说，叫他不在乎，爱用不用，不用拉到，这类公司，要么很强势，要么有关系
不过随着行业发展，很多公司也开始注重起用户体验来了，所以很多公司有了产品经理，有的公司有专门的用户体验工程师，这都是一种进步。
就跟回头看我们的测试的发展一样，也是一步一步慢慢发展起来的，说不定几年前你们公司还没有测试呢。
同样，说不定几年后，你们公司就有产品经理了呢，所以LZ不要生气也不要郁闷，我们要用发展的眼光看问题

[ 本帖最后由 sakuna 于 2010-8-10 15:27 编辑 ]

狩猎者

发现BUG提交不提交时测试人员的事，但BUG是否修改就不是测试人员的工作了
总之，做好该做的，改变可以改变的，接受无法改变的

archonwang

貌似没有产品经理，感觉这个地方可能不是一个良好设计，客户体验可能比较差。

客户能自主选择是正确的，但是并不是以一概全，客户可能更希望傻瓜式的处理操作，简单，一目了然，过多的选项无助于客户更好的使用软件。

——建议仅供参考。

千里

呵呵，对于单位那个。也许客户是专业人士，确实能看懂，而我们不是专业人士却看不懂。如果给我，我的做法是找产品经理或者项目经理协商下这个问题要如何处理，不过我会突出这个问题的解决不难，改一下不费时间。
又想到了一个邪恶的做法，就是把bug全部压着。等项目经理问的时候，就说没有任何bug，虽然发现一些，但是客户不会那么操作所以放过了。我觉得用他的话回复他，他会急的。然后要你不管bug巨细都要你提出来，这个时候可以和项目经理讲条件了。

纭纭_y

很有趣的说法：客户不会那么操作的。他能够代替客户做决定吗？说得轻松哦。。

说不定，客户比测试人员还挑呢。。

楠族开心果

我直接说：你怎么知道用户不会那么操作呀？你能代表所有的用户么？？？

千里

原帖由 楠族开心果 于 2010-8-10 17:37 发表
我直接说：你怎么知道用户不会那么操作呀？你能代表所有的用户么？？？

这样说是解决不了问题的，只会让矛盾更加激化。

zhangting85

事实是，测试人员说的话代表不了用户，而开发人员在这个问题上占据了主动，所以需要测试人员来证明这个bug需要改而不是让开发人员证明这个bug不需要改。

楼上多位朋友认为测试人员不用管bug改不改，这点我是不同意的。

这个牵涉到一个测试人员最基本的职业目标。我们要的是提高质量，不是单纯地发现bug。
一个好的测试人员不是报最多bug的人，而是能让最需要修复的bug被修复的人。
一个bug会不会被修复，很大程度上取决于bug报告怎么写。你写XX地方一个文字错误，用户不应该看到这个单位名称。我敢说10个开发9个不会改。但是你要是说某个地方一个文字错误，用户由于这个错误会造成误操作导致XXX，XXX的严重后果，一般的开发都会改。又或者，你可以发信给其他相关的人，尤其是比你更能代表用户，比你更能给专业意见的人，把他们的意见写进bug报告，也可以促使开发修复bug。方法有很多，简单来说就是要做有效沟通。

ringbaobao

楼上说得非常有道理！

msnshow

所谓测试人员应该站在用户的角度想问题，那么在遇到与开发人员有分歧的时候，最好是看看用户的意见

chengning

就我所了解 测试不能代表客户  开发也不行  领导还是不行
这种情况下 还是谁了解需求 谁了解业务 听谁的
测试在需求不完善或者没有的情况下 最多也是在猜想客户有什么样的操作 就我个人所遇到的 来说 ，因为我们公司是做医药软件的，有些东西测试真的是在想当然 ，因为专业的医疗人员就不会那样做，而你自己非要坚持这样去测，就算最后B改了 ，意义也不大。
另外 ，建议楼主不要有主管在测试上一定要比你强的概念， 他能当主管肯定会有过人的一面 资格老也是一种资本 ，还是心放平点
祝好运

archonwang

主意太狠，仅供参考。

Jackc

呵呵，确实是一个很敏感的话题。

测试本身就是一个多角度的矛盾综合体，侧重于不同的因素就会培养出不同的测试员。（当然，均衡的测试员也不是最好的）

#11楼的朋友提出了两种非常好的改进方案：提高缺陷描述技能和寻求第三方技术支持。

不过，即使这样，测试人员也只是停留在“提供修改意见”层次，无法逾越到“决定修改”的高度。

测试人员可以收集更多的信息支撑自己的意见，不过决定权还是在别人。
主要是因为普通的测试员对“修改价值”无法达到较全面的认识。（比如：修改难度、客户体验度、回归缺陷风险、修改成本等）

所以，正确表达自己的态度并寻求支撑信息是属于测试技能范畴和职责范围的。但是，强行要求开发人员修改某个缺陷是不可取的。
请测试朋友们区分“建议”和“要求”的区别。

而像LZ测试的那个软件，也许项目主管定义的产品质量标准真的很低，像2#朋友说的，“m/s是速度单位，不是面积单位”。估计这软件真的只有“专业人员”才玩的转了。

最后，作为测试人员，除了需要保持自己的立场外，还需要“换位思考”。对于这个问题，至少得理解项目主管的立场是什么。Bug太小？没人力资源？也或其他。（理解对方也是属于交流的基本技能）

说了这么多，废话也很多，简单来说也只有4个字：全面思考

坚强的豆腐

体积（m³）/速度（m/s）×时间（S）=面积单位 你们主管肯定是怎么考虑的

遇见这样的主管 做好本职工作 不管改与不改 BUG先提交上 有记录可查以后责任就不在咱了 万一上头追究下来 就叫他找开发去呗

江潭素月

m/s是速度单位，不是面积单位；m^3是立方米（体积单位），也不是面积单位.
这个确实...但是没法控制，自己想输什么就输什么。用户可以自己填写或删除。关于那个问题我提交bug了，被打回了，说不用修改，用户会自己选对的

江潭素月

现在bug出现争议的时候，有技术总监决定改不改

江潭素月

原帖由 sakuna 于 2010-8-10 14:21 发表
顶楼上的一下
有一句话叫屁股决定脑袋，对于同样的一个问题，每个人看法肯定不一样，对于有的问题，PM不以为然并不奇怪，但是要记住一点，测试的立场不能丢
现实中，总是有公司不注重用户体验的，换句话说，叫 ...

谢谢您。我们公司现在的情况是起步阶段，各阶段不规范，虽然客户单子不多，但是开发人员整天忙，因为客户需求总是在变，所以一些不痛不痒的错误就不愿修改了