楚迷城 发表于 2014-5-7 14:09:36

扒一扒某些奇葩的程序猿的某某观点

如下是某些程序猿的论点。。。。。
一、本来只是小BUG,到你这儿测成更大的BUG了
二、连这种不是BUG的BUG你都测出来了
三、这个还不算BUG，等客户提出来后再解决吧
：
：
：

zhangyi910918 发表于 2014-5-7 16:44:06

排好队哈:lol
四、这个问题在我的环境中并没有发现
五、这是数据引起的问题，不算问题
六、你这操作有问题， 实际中客户都不会这样操作的
七、产品的需求规格中并没有这样要求

缘来是你_cong 发表于 2014-5-8 17:13:14

呵呵...左耳听，右耳冒吧，没办法..........

forever_jun2_ 发表于 2014-5-9 11:42:11

确实有些研发好的话会说这是问题，并且找到原因，但有些就...:(如上所述了

jin_002 发表于 2014-5-13 11:10:49

在提交一些隐性需求的BUG时，可以在后面加上可能导致的结果和建议。

TesterCC 发表于 2014-5-13 17:18:32

三、这个还不算BUG，等客户提出来后再解决吧。
这点要理解，比如你测出来的bug其实是需求方要求这么设计的，开发是按照设计要求来，的确很纠结。
当然你还是要告知他们，而且最好有记录。

冰爽果冻130 发表于 2014-5-15 19:25:13

真的，有时候由于一个bug问题跟开发确认了好久，最后得到的结果就是上述几种情况。真的感觉好无语啊

晓舞露痕 发表于 2014-7-29 11:29:29

有的时候不仅研发会这样说，连产品经理都会说！！尤其爱说“用户不会这样操作的”

Miss_love 发表于 2014-7-29 11:40:04

:lol说的很现实

anywhereanytime 发表于 2014-7-29 15:21:52

回复 2# zhangyi910918


    作为一个由测试转开发的来看，你这几点确实是这样的，很多问题确实是由环境的原因，软件需求说明书未提及，操作方式导致，不能归属开发的问题。
这也就是为什么BUG有多种类型了，软书未提及但确是问题的话那就是设计缺陷，操作方式之类的可依影响情况及改动大小来论是否需要修改。
那么环境及数据的问题就需要更具体的确认了。如正确的历史数据有问题那就肯定是开发的原因：未考虑历史数据的情况。但还有可能其中的某些数据是手工后台修改导致。
页: [1]
查看完整版本: 扒一扒某些奇葩的程序猿的某某观点