一个优秀的测试人员是否需要对缺陷定位负责？(02-06-06）（获奖名单已公布）
本周的问题为“一个优秀的测试人员是否需要对缺陷定位负责？”
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单
奖项获奖名单奖励答案链接
一等奖TesterChen50移动充值卡2#
二等奖san300论坛积分18#
三等奖ffan1027100论坛积分 14#
本帖最后由 TesterChen 于 2012-5-30 13:27 编辑
一个优秀的测试人员是否需要对缺陷定位负责？
问题的答案我觉得应该是肯定的。
首先，从字面意思来说，我觉得测试人员应该对缺陷的定位负责，尽量在报告缺陷时将自己对于缺陷的理解（或缺陷产生的原因）写入到缺陷的备注信息（或缺陷主体）中。在个人能力、资源许可的情况下，尽我们所能的去提升我们的工作质量，做到100%的自我负责，因为我们的目标不是做完成就可以，而是追求优秀！！！
其次，软件测试人员的责任角度来说，在测试人员具备这样的个人能力，且通过他们掌握的资源可完成对定位缺陷，那么最好是提供对缺陷的定位给开发人员或产品人员。这样即方便开发人员去定位问题、解决问题，也便于后期缺陷的追溯与回归。同样，部分缺陷可作为产品人员对产品进行优化的参考。
但是，如果对缺陷的定位很困难，通过测试人员所掌握的资源与知识在短时间（如一个小时、半天）内无法完成对缺陷的定位，我们最好是向开发人员反映，并表示期望得到他们的帮助，共同对发现的缺陷进行定位，定位后要记录在缺陷的描述中；
如果在交流过程中测试人员和开发人员一致认为此问题很复杂，需要开发人员内部进行排查的问题，那么此时测试人员可以终止缺陷定位，交由开发组人员进行处理，测试人员只需要对后期缺陷产生的原因进行了解、对缺陷进行回归测试即可，测试人员可考虑参加他们的讨论。
将问题的定位转至开发人员层面之后，如果涉及到更加深层次的问题，开发经理（项目经理）会向他们的上级或同行请求协助，测试人员可考虑参加他们的讨论。
另外，我们要考虑的一个问题就是具体问题具体分析、能随机应变。如果测试组的成员有很重的测试任务，在规定的时间内对所有内容完成测试任务的可能性都不大，那么我想测试人员也没太多时间去找寻缺陷出现的具体原因。但在这里仍然要强调的是缺陷的重现步骤、涉及到的数据等信息一定要记录全面，这样方便开发人员在调试时更快更准确的重现问题、找到问题、解决问题。
同时，我觉得适量的对具体问题进行深入探讨，即有利于我们了解被测系统的业务，也有利于提升测试人员的工作技能。同时也加强了开发人员与测试人员之前的相互沟通和协作。
最后，我认为优秀测试人员不仅要善于找出现在系统已有的缺陷、对发现的缺陷进行问题定位、提出对缺陷的修改意见或建议。更要能预知未来系统可能会出现的缺陷，并提出自己的看法、同时设法对它进行验证。 既然说是优秀了最好什么都懂什么都能负责 这个问题有点矛盾：
首先优秀的测试人员是应该对问题进行定位，这是高级和优秀测试人员的体现价值，But 缺陷定位问题是属于开发的工作，要说负责，开发的责任。
当然测试也会在前期提交bug的时候进行bug的定位，但是这是不能说明是定位准确的，因为此问题会提交到开发这边，开发人更清楚问题的所在，也会modified bug，如果你根据测试定位的去更改，更改错了，那我只能对这个开发无语了
还有一个问题就是一般bug会记录定位此bug是由谁定位的，当然也会写定位的原因的，所以呢，根据这个来判断谁负责更有决策性。
但是我还是想说明的是，软件是开发开发的，把错误位置定位扔给测试是不合理和准确的，毕竟不我测试写的，测试的目的和找原因，到了一定阶段的测试会有定位和解决bug的能力，但并不一定代替开发 真正要找到root cause 真正要找到root cause, 需要看code
感觉让测试工程师去做code 工作,事半功倍.不划算/ 发现BUG、重现BUG是测试过程，定位BUG、修复BUG是开发过程。有时候重现BUG的过程跟定位BUG过程很难分辨，那最好是让测试跟开发一起配合来解决 如果定位问题是测试人员的职责，那测试的职责可能还包括给开发人员端茶送水——《完美软件》。这就是职责划分不清了 测试人员不应对定位缺陷负责（不管里多优秀），不过可以在定位过程中提供帮助。 同2#所说
个人认为，测试人员是不需要对缺陷定位负责的，但在自身能力允许的情况下，可以尽可能去定位，这样不但对测试人员自身能力的提升有较大的帮助，同时可以提升缺陷修复与回归的效率。同时，还要看公司资源是否允许，对于比较难定位的缺陷，去定位是很花时间的，但是项目周期都很紧急，测试时间也非常有限，如果为了定位一个很难的缺陷而影响了测试的进展是得不尝试的。 好好看看，非常好的帖子 目前公司实际情况是，测试负责发现并竟可能重现bug，并且协助开发搜集资料去定位bug，如果能力强，也可以将bug定位，交给开发，但是还是得由他们确定，验证。
说到负责，我们可以有我们的立场和建议，但是否被接受？如果是重大问题，会通过会议讨论~~ 一个优秀的测试人员是否需要对缺陷定位负责？
这个问题涉及一个团队中各个角色的职责问题，既然定义是测试人员，个人觉得不需要对缺陷定位负责。优秀的测试人员，应该是能够尽可能的发现软件的缺陷，并且能够清晰的描述缺陷重现的场景（包括缺陷出现的前置条件，现象，带了的后续问题等），虽然这类描述尤其是前置条件等，可以帮助开发人员尽可能的定位缺陷，但是缺陷定位不是测试人员的职责。个人愚见，欢迎大家讨论。 本帖最后由 ffan1027 于 2012-5-24 18:06 编辑
以下是我的见解 ：）
作为一名优秀的测试人员，能够对发现的缺陷进行准确定位，对与产品线或项目组来讲是非常有利的事情，可以给出研发人员修改建议，提高研发人员的工作效率。但是针对此题目“一个优秀的测试人员是否需要对缺陷定位负责？”我认为答案是否定的。测试人员有责任对缺陷问题进行定位，负一部分责任，但是缺陷定位的第一责任人应该是研发人员。
测试人员的职责包含：制定测试计划、撰写测试用例、执行测试用例、总结测试报告、缺陷管理。开发人员的职责包含：制定研发计划、根据需求实现功能开发，使之满足需求定义，并正确的运行。缺陷定位可以划分在缺陷管理中，当我们发现一个bug时，会详细记录bug的复现步骤。如果能找到缺陷的根本原因那是最好的情况，但是有很多情况下，如产品成本控制，不要求测试人员对代码级的分析和测试，无法通过调试代码来定位缺陷问题，那么定位缺陷的就由功能开发者完成，毕竟是自己写的代码，最熟悉的还是自己。测试人员可以针对缺陷给出问题定位建议，对于问题定位是否正确，是否接纳测试人员的修改建议，研发人员有自己的见解，应对自己研发功能的缺陷定位负责，并根据缺陷定位修复bug。
虽然上面我讲由研发人员对缺陷定位负责，但是对于测试人员的自身素质来讲，缺陷定位是非常重要的一项要素。工作时只发现问题表相，描述缺陷仅包含步骤，没有对缺陷的分析，“做了什么操作，系统报了错误，无法进行……”，我们所做的工作缺乏了一些挑战和难度。如果能在发现缺陷后，对缺陷进行定位，如“缺少配置文件x.config”、“执行sql不正确，where条件关联关系错误，xx.id 应与cc.id关联，不是与a.id关联”、“sql语句错误，开头是应该为 like ‘xx%’，现在写为了like ‘%xx’ ，同理’结尾是’sql也错误”。这些是几个简单的例子，开发人员看到bug后，清楚明了，可以直接修改代码，提高了我们测试工作的趣味，同时也提高项目组的工作效率。 这个问题我觉得回答是肯定的，一个优秀的测试工程师需要具备这样的能力，一个优秀的测试工程师的不是发现bug最多的那个，而是使更多bug修复的那个。
我们考虑这样一个场景，在测试过程中你发现了系统的数据表会死锁，当重启系统会变好，但是你并不能确定是哪个操作造成了这个问题，你如何描述的bug呢？这个问题在开发的环境中是很难重现的，他们总是开发编译然后会频繁重启很难发现是哪里出了问题，这时测试是否能定位问题就是至关重要的了。
我想作为一个团队，我们把任务划分的如此分明并不好，开发和测试有个共同的目标就是是我们的软件更加的完善， 所以不管是开发和测试都对bug的修复有着责任，所以我觉得尽我们所能的定位问题也是工作的一部分，也是我们必不可少的责任。 本帖最后由 zhusaisai 于 2012-5-24 21:13 编辑
一个优秀的测试人员是否需要对bug定位负责？
我的观点是测试人员不需要做bug的定位工作，所以更谈不上负责。
我们先确定一下，什么是测试？测试的定义我记得是这么说的，通过运行程序发现错误的过程。那测试这个行业的主要工作应该是发现问题，客观的描述问题。也就是说测试人员的主要职责是发现问题。所以优秀的测试人员应该是最少的时间内发现更多的问题。
项目团队有开发有测试，我们的分工本来就是不同。测试人员负责发现问题，客观的描述问题；开发人员负责确认问题、解决问题。这样分工的好处是专业的人干专业的事情，效率会高很多。测试人员在完成本职工作的同时能够定位到问题，帮助开发人员尽快的完成工作，我觉得是个积极的团队成员。但是，前提是本职工作尽职尽责完成，前提是对定位的问题准确。如果这些前提都不存在的话，很可能起到相反的作用，自己的本职工作没有做好，拖后了测试进度，误导了开发人员或者局限了开发人员的思路，很可能影响团队进度。
最后，我个人觉得，可以学一些架构、数据结构和表结构相关知识。目的是更了解项目的内部运行过程，更快速的发现深层次的问题。 兴趣所致，心生负责，心有多大，舞台就有多宽！ 狭义的说，不需要！广义的说，depends。
这个其实以前考虑和讨论过的。
说不需要是从合作分工的效率上来说。专职的测试出现是软件工程化之后，出于提高生产力和提高合作管理效率，必然的结果就是行业分工。这和其他行业工程化的体系框架相似。测试，开发，项目管理，需求，架构师，分别代表和承担着软件开发过程中的不同方面。专职的分工能提高工种的专业性和过程平衡（不至于忽视了某一方面），在绝大多数情况下这是提高效率的有效手段。我们可以定义测试人员的职责是：证明没问题，或者发现问题，或者预防问题。无论从这些传统的任何一个定义，其实都没有必要去定位问题，只是需要确定和重现问题。当然，定位问题的能力，在某些时候能有助于我们发现和分析，但这不是必须的。如果只是为了解决修复，让熟悉代码的SE来，效率会更高。
说depends是因为，分工合作是基于某种工程模式的。也就是我们常说的开发模型。任何工程模型的两个核心都是过程与分工。不同种软件模型都是在解决相同的软件问题：需求的抽象/变更，设计的预见/适度/变更，过程的估计/变更，而波动和变更的体现就是风险。在不同的工程模型中，我们可以设定专门的角色掌控风险，也可以把风险掌控的职能放到其他不同角色中。所以一个角色的职责，需要做什么或者不需要做什么，取决于工程模型的设定。我们的模型一直在发展演变。一些团队在刻意模糊淡化研发测试的界限，一些团队拓展了测试的职责。测试可以不仅仅对产品质量负责，也可以对需求质量负责，可以对过程质量负责，可以对代码质量负责。对代码质量负责的测试团队，或者运用底层测试技术的团队，往往需要进入代码层，或者说他们本身测试的颗粒度就很小，这样不但能更容易捕捉到代码的变化，容易维护，其实也一定层度定位了问题。另外一个特例是性能测试。性能测试最困难的地方其实是场景和分析。这里，分析和定位问题，然后重新设计更有针对性的场景就是QA的职责了。
总的来说，测试是可以定位问题的。但定位和解决问题在分工上真不是测试本来的出发点。如果还有测试这个职业，他依然应该围绕质量这个中心。只是随着分工形式和技术发展的演化，我们运用的方法也能一定程度上能定位问题。最后，从职业发展来看，测试人员的职责定位也会随着工程模型的演变不断发展，提高技能与时俱进还是有益的。 谢谢哦，辛苦辛苦！ 没有应不应该，想做好测试，让自己乐在其中。就可以去定位问题。跟开发交流。其实是中经验的积累。
我建议测试都这么干。长期的积累你终将受益菲浅
