2，测试人员职责是发现软件中存在的问题，将问题告知PM及项目组成员，由他们决定是否需要修改。（当然如果实在看不下去的话，应该据理力争）。 to qtest:这招毒，毒，毒。。。 第一,公司制度完善;
第二,bug客观准确且严重级别定位恰当;
第三,沟通得当.
最后的结果:搞定BUG!!! 有的时候，企业内部的沟通要比对外还要难，这个时候，你要保证你提出的错误是存在的，然后才可以提交，通知程序员的方法，我不知道大家是怎么做的，但我认为没有必要直接去找程序员，大家在一个缺陷管理平台上，将错误反映上去后，然后通知程序员即可。
在项目进行中，要注意那些大的BUG，一定要使其处于关闭状态。如果在结束的时候还没有封闭，那么作为一个测试人员，有必要将此情况向上反映。对于小一些的BUG，如果在结束的时候还没有封闭，可以汇成一个清单，到时候如果出了什么问题，也有所依据。
不过有个问题也想和大家探讨一下，就是作为一个测试人员，从公司管理角度来讲，应该处于什么位置。各位在单位有没有一个专属的测试部门，部门的名称是什么 bug的关闭与否应该有ccb讨论决定 我们公司是由测试组定期进行绩效考核，在进行BUG票整理的时候，同时提交BUG修改率与BUG修改延迟时间度，
关乎他们的生存大计，看他们改不改！ 不改就不改嘛，修改Bug要由项目负责人规定修改期限的，不是无限期的，而且还要高兴才改不高兴就不改，那样怎么能行！到时候会以这个因素去考核他的，他总是赖着不改，对他好像没什么好处，呵呵！ 或许这些在他们眼里不是bug
只是一点小问题
无关痛痒，但是，我还是觉得软件还要完美点好~
所以，要让他们改~！
Bug 到底改不改
在针对某一个问题是否Bug时，存在争议是正常的。因为有些Bug是显然的，比如实现和流程（标准）不符合，对于这些Bug因为有明显的依据，应该是无争议；对于另外一类bug，比如界面的风格，这些问题往往公婆各说，难以界定。出现扯皮是可以“接受”。测试不仅仅是发现问题，测试要对一个版本负责，测试一个版本过后，应该知道这个版本是否可以发布，他的薄弱点在哪里，哪些需求没有实现。
从楼主述说来看，好像公司没有一套版本（需求）管理的流程，对于bug的界定没有一个开发和测试公认的标准。 一般来说，对于一个项目中的bug，最后打开和关闭的权限还在项目内部处理，公司里即使成立了一个什么组织也没法决定这种具体的事务，关键还是沟通了。测试人员在处理上如果无法说服开发人员，最妥协的方式也应该是把这个缺陷推迟，而不是简单关闭，头痛之处其实在写测试报告时候，到底要不要反映这一问题，这个还要和项目经理沟通。
然后那位要嫁给程序员的MM，深以为此法不可行，一是如果多个程序员拒不改正，没法同时嫁给这么多人；二是连软件的bug都懒得改正的人，生活中的bug更不会改正了，后悔一辈子的怕是自己了。 沟通，处事方式都有影响
有时你找的bug总是一个程序员的，而另外一个程序员的bug就很少
人家就对你不爽 如果提出的BUG与程序员有分歧，可以沟通了，再不行就把所有有问题的bug开会评估一下了 我提交BUG时候，分BUG和建议，开发人员认为不是BUG的，就给设计人说，如果设计人同意了，就让他更改设计，开发人员要按照设计更改程序的，他就不得不改了！ 还是，公司有个正规的测试流程是主要的。是不是bug,将权利交给了谁的问题。 这是一个测试流程的问题。当Release的时候是有一定标准的。（比如可以有多少级别的bug等），他们要违反流程的话，让PM去协调，把压力给那些PM。 我的想法是：测试人员是为了发现问题，提交BUG，跟踪BUG的修改，但不是去企求开发人员给我们修改，调试修改是开发人员的事情，但在这个过程中我们要运用技巧，沟通的技巧，软硬兼施，嘿嘿，要把问题和问题的严重性描述清楚，定期做个统计，提交给领导，由领导给他们压力比我们要有权威的多啊，而且也可以让领导看到我们的工作了，嘿嘿。 拖出去打一顿！ 如果公司有PM的话,就由PM决定了.
我认为测试人员不用想这些的,这是测试人员的职责之外了.
这是我做测试一段时间的深刻体会. 怎么办要具体看公司的流程怎么规定……
他实在不改就不改好了，你做你该做的，拿你该拿的就行了……
