论不被重视的测试新手的悲哀

水水水货

最近发现了一些我认为是bug但是编程人员认为不是bug的bug，最后我也不知道我找到的是不是bug了，我找到的是命名规则问题，他们给出的理由是谁也不会去那样命名，而且页面太多，改起来会很麻烦，他们也不愿意改，属于多个人负责，意见也不会统一。最后我妥协了，测试嘛，发现这种不是bug的bug（我姑且认为是bug）理由上是站不住脚的，人家说东，你说西人家也不会理你的，你也只能说，对对，就是东。还有一些，本来应该有快捷方式的，不用那么繁琐的去点，可是编程人员没有加上，你给他提意见，他们还会认为你多事的。
悲哀啊。

chengning

做测试也是要看环境的嘛  也就是要了解公司做的软件的客户是什么？
假设是一般的网站，或者维护类的，当然对测试的要求要低一些
如果是做产品或者军工的 当然小的错误也是要尽量要求开发考虑去改

愚人

别人不重视不要紧，面对别人的不重视不进取才杯具……

swinfans

你很犀利

楠族开心果

我也是有问题就报，他们不理睬，我一般说：你是客户？？

crystal50112

我觉得跟公司的要求有关系吧。如果公司做出的产品本身就没那么高的要求，不需要事无巨细，那就可以考虑少报一些E级别的bug。如果公司本身就对产品要求很高，那我们的原则就是，有问题就要报！呵呵

peag

原帖由 sakuna 于 2010-8-5 10:20 发表
你说的很对，但是对于一个新手而言，基本是不可能做到这样的，所以他要多提bug，打回又有什么关系，经验就是这么积累来的，对于新手，我的观点是犯的错越多越好，不犯错我还不放心

觉得这个说得不错，很多时候BUG的话你提出来应该要给领导审批了才分配给开发，不管重要轻重。但是你应该把这些BUG分个轻重缓急的，这样有个紧急级别的区分，这样开发就不用再花时间去考虑先改哪个~~~

chengning

万事需求为基准  不要去想当然 你想当然也可以  但是不能要求别人跟着你想当然
需求没有要求那么多  就可以暂不考虑 要是需求有要求的 那一定要改
另外  就楼主说的那些BUG 应该是不会影响软件的功能的 所以 可发是有权暂缓的

zhangting85

正确，必须树立自己的权威性。但是报bug的策略上，你可以不仅仅用自己的话来报bug。狐假虎威地在报告里引用现在公司里已经有权威的人士的言论也可以增加你的bug报告说服力。这类事情是讲方法的。比如开发人员眼中非常小的界面问题，我发给界面设计人员，第二天他们就敦促开发改掉这个bug了，界面友好性上的小bug可能开发不关注，但是你们的产品经理或者客服人员却非常关注，你说服不了开发可以让他们“代替”你去说服开发。

另外，没有任何人关注的bug报告是没有意义的。一个bug的存在总会引起某些人的烦恼，所以它才被称为bug。

[ 本帖最后由 zhangting85 于 2010-8-5 10:39 编辑 ]

davy_chen

测试需要学会妥协和争取，原则问题要坚持。所以
确认此命名规则问题是bug，但是不属于高级别bug，开发可以不予修改。

sakuna

你说的很对，但是对于一个新手而言，基本是不可能做到这样的，所以他要多提bug，打回又有什么关系，经验就是这么积累来的，对于新手，我的观点是犯的错越多越好，不犯错我还不放心

千里

有一句话叫人微言轻，我觉得当一个人在别人心目中的地位不高的时候，往往他说话的分量也是不高的。
虽然说bug报告的说服力是测试人员体现功力的地方，如果楼主只是简单的有bug就提。其结果我想会是开发觉得大部分bug是不重要的，继而形成该测试提出的bug可以不当回事的惯性思维，以后你再有说服力，他已经惯性思维了。
我觉得策略一点，是先要在开发人员中建立自己的威性。另外站在开发的角度上着想，他也很忙，没有足够的时间修复你提出的bug，提出一堆无价值的bug只会让其更烦躁。
书上也说了：不是每一个bug都需要修复，既然不是每一个bug都需要修改，那么那些不值得修改的bug我会选择不汇报给开发。

zhangting85

在bug报告里给出这个bug需要修复的理由也是测试人员工作的一部分。如果不能给出具有说服力的理由，bug经常会被打回。不同的测试人员提同一个bug也往往有不同的结果，bug报告里的具有说服力的理由就是测试人员体现自己功力的地方。

sakuna

楼上的两位，不要如此打击人家的积极性嘛
有一种说法，测试只管提bug就行了，但是至于改不改不是你决定的。先不管这种说法有没有道理，楼主先做到这一步吧，如果你老是纠结于开发不改你的bug，那你的活就没法干了。
你会发现随着你经验的积累，开发对你的bug会越来越重视，慢慢摸索吧

风逝

非常赞同千里的观点，如果在公司里面，你不能提出有份量的bug，那么你也一般不会受到开发人员的重视。有时候，连你提出的观点也是一样。

千里

bug有严重级别的，修改bug也有轻重缓急。
像你说的命名规则，这是一种规范。你直接汇报给开发经理就可以了。
至于快捷方式，这种应该属于bug第五级建议性类型吧。
开发不认可你，是因为你提出的大多是轻微的bug，
如果你能够提出一些严重级别比较高的bug，你才能在他们心目中有分量。
否则他们会觉得你总纠结于一些鸡毛蒜皮的事情，而不能提出实质性的意见。