我前面的发言一直在避免英文字母缩写就是因为现在任意三个字母拿来以某个顺序都似乎能有个意思，还各有各的解释，挺好玩的。
这个论坛有很多帖子解释概念，可以找找去，这里，QA指质量保证，主要针对流程，不是测试员；而测试员这里用QC来指称，S是软件的意思，记得有个帖子讨论硬件测试，里面有区分。其实有的地方把测试员是叫做QT的。
不管怎样解释，你的：
软件测试人员——QA
软件质量保证人员——SQA是有问题的。
不扯远了，回到这个帖子的问题，赞同 kpxl 和 steedhorse 的观点，看得出来他们是有着实战经验并富于思考的。 如果只是个按计划操作的测试操作员，只要完整了计划的执行并有效，他就没有责任了，如有遗漏是计划的问题。
可事实上所有这里的朋友，做测试的，都希望自己不是这样的测试员，希望自己能做更多的事，责怪公司不给这样的权限，不给机会锻炼能力。
获得权限得到机会的同时也要承担责任，在大环境如此的情况下，甚至要先承担起责任来，然后才有机会得到权限，得到锻炼机会。所以，先要改变自己的思维方式。 我在这里再说一下我的观点吧：
作为测试人员——一个经常背黑锅的角色，还是不要去拦那么多本不该我们负的责任！很多公司很希望我们去负责(通过测试保证质量——但测试只能有限的保证质量)，但却不会给我们权力，我们没有市场发言权、没有开发决策权、没有产品设计权，有的只是测试权。费尽心机争来的那点权力（评定权）真的很重要么？ 我举个很简单的例子，以前给别人讲过。
窗明几净的大厅里有一口痰，给访问的来宾留下不好的印象。
谁的责任？
简单分析一下，为了分析方便，把前提固定，痰是一个员工吐的，大厅有专门的清洁人员，大厅的经理负责管理。
我们先看清洁人员。
吐痰的人肯定要负责，但是大厅有清洁人员，经过他们的清扫还是发现一口痰，他们要负责。他们不是负吐痰的责，而是负没有清扫干净的责。
如果清洁人员以“吐痰的人不对”为由推卸，逻辑上是行不通的，否则他们可以看到痰也不去清扫，他们可以说本就不该有人吐。
所以，“如果开发部不出错不就没问题了么？”这样的思路是不对的。（这个帖子不是讨论如何尽可能避免bug，而是在遗漏了bug后的责任归属。）
虽然大厅有“N不规定”，但仍需要清洁人员，清洁人员存在的原因就是肯定有人为和非人为的因素需要他们担负职责。
可以再看看吐痰的员工。
他为什么要把痰吐在大厅地上？可以简单列几个原因：
1）个人素质；
2）其他人在大厅都是很随意地仍垃圾吐痰；
3）大厅的环境没有能够提醒他这里不能随地吐痰，他以为是在老家乡间的小路上；
4）突发紧急情况，被痰噎住，必须吐出，但大厅没有垃圾箱，他也没带纸。
......
好，我们再看看大厅的管理者。
对于吐痰人的4（n）个可能，管理者
1）为什么要雇佣他？
2）为什么没有规章制度或有而不执行？
3）为什么没有创造一个与大厅职能相称的环境？
4）为什么没有备垃圾箱？
......
这些都是管理问题。
我们可以大致（虽然有不贴切的地方）想象一下，
大厅管理者——产品经理
员工——开发人员
清洁人员——质量检验员
但愿能帮助大家得到一些有帮助的思路。 漏了一个，
那口痰就是那个bug 不错。。这个例子能比较切实地说明一些问题。。
大厅管理者——产品经理
员工——开发人员
清洁人员——质量检验员
看来管理还是第一位的。。就象执行测试前 要先对测试计划与测试分析进行
审定一样。。 我们公司不但有软件测试，同时也有硬件测试组。
硬件测试和软件不同，有严格的标准，比如ISO，里面规定的十分详细，像我们的产品，就规定了在什么温度、什么湿度、有多少的使用次数、硬件承受多大的压力等（我们有专门的铁锤去砸硬件，很好玩）。
硬件还有一个好的地方就是可重复性，应该虽然有废品率，比如1/10000，但其他的9999个几乎完全一样。即使出现了问题，下一次再次改进工艺，又可以生产出同样的修正了缺陷的产品。
软件则不同，没人敢保证一种条件下的软件和别的软件一样吧，即使在代码中修改了1行，会有什么样的影响恐怕也很难预测。所以对软件质量的保证不能和硬件等同。就像不能那建筑学和软件工程同样类比一样。只能说有相似的地方，有借鉴的一样，但拿同样的标准去要求，这是不现实的。
其实在客户那里发现了问题，如果公司有好的流程，想追究责任是比较容易的。在提交测试的时候，应该有测试任务单，说明需要测试的内容，测试部门写相应的测试用例，并进行评审，评审通过后，测试仅仅需要测试经过评审的测试用例即可。这样发生问题就很好解决了。
如果发现的问题在测试任务之内，是测试人员的责任。
如果发现的问题在测试任务单之外，找开发或领导的责任好了。
我强烈反对把责任归咎于测试人员。开发的烂就算了，什么事情都找测试，算什么事情呀。 感谢前辈们的精彩分析,不止是这篇帖子,我看过的所有帖子都让我学到很多.
让我这个新手觉得原来这个行业有这么多的东西是我不会不懂的,继续努力
NIO
Originally posted by Nio at 2005-4-19 09:51:“顾问”设计的规格说明书？——是哪个公司的叫法呀？至少我不了解哟？
原则上只要QA同意出货就要对产品的质量负责，否则要不要QA还不是一样？
——盲目“自大”的典型观点！这是说的自大是将QA的“责能”扩 ...
这个叫法你不知道，我不知道该说你无知还是说你经验少，我想问你一句话，你们公司的系统都是怎么设计的？难道连规格说明文档都没有？仅凭产品经理一个人的心血来潮，一个产品就出来了？
还有提到测试人员的自大的问题，我觉得这不是自大，使每个人都要负起相应的责任，否则责权不分，就像大锅饭一样，效率和质量都是可想而知。
另外还有一个就是成就感的问题，如果一个测试人员在公司没有一点的发言权，对于产品的发布也是没有一点的发言权，当然也不用承担责任，这样的工作试问又和成就感？可能你现在所在的公司就是这样的情况，你可能现在也就是属于那种没有发言权的人，但是不是每个公司都是那样的，不能一叶障目，不见泰山啊！ 回应楼上的两个观点：
1、使每个人都要负起相应的责任，否则责权不分——这一点我赞同楼上的观点。但测试人员的职责不会包括：市场发言权、开发决策权、产品设计权以及产品发布权等，大都数公司赋予测试人员的只有测试权，其它方面的问题最多也就是个参与意见权。
2、测试人员可以参与产品的发布，但不是主导。 个人观点：
1、测试人员唯一需要承担责任的是发现了Bug，却不上报Bug，导致Bug最终在客户那里发现。
2、找出责任承担者不是目的，通过找到漏掉Bug的环节来改进整个项目工作才是关键。如果把注意力都放在追究责任上，只能把大家之间的关系越搞越僵。
3、测试人员漏掉Bug的原因有很多，比如测试经验不够、没有合适的测试环境等，这些都不是什么责任问题。
4、测试人员的工作内容是确定的，就是尽自己的努力尽量多发现Bug，对于产品的发布、市场方面能提出意见当然是好事，但不做并不是失职。 如果测试员说如果我发现了bug，那是好事，如果我发现不了，那也别怪我，那要测试员干吗呢？
每个行当都有自己的职责，当然也有责任，不作为就是失职。这个职位就是设置一个保险，当然不是质量全靠这个职位，但它能为质量增加信心，如果不作为，保险就失灵了。
当然，由于客观因素诸如政策、制度、权限等等，另当别论。
同意目的不是找责任人。只是不要在确定责任的过程中踢皮球。改进和提高是需要确定责任归属才能有针对性。 在某些地方比较同意black_tulip和kpxl朋友的观点
不过现在每个公司的情况也不一样 有时还是要客观地根据
每个公司的实际情况来进行定论。。
我自己认为做测试要三心：细心，耐心，恒心
最起码要做到的一点：对于测试员自己负责的测试部分要尽自己最大的能力
和精力去进行测试过程，测试员的工作职责应该贯穿整个测试过程，并非只
是根据上面所拍发的任务来进行执行，那如果是这样测试员不等于机器人了
有时候也要发挥测试员的主观能动性。有的错误是潜在的问题，而且在沟通
的过程中也能发现许多潜在的错误。 这个问题想不到会引起这么大的争论，我的观点是～
一旦客户反馈回bug就要及时定义bug类别，然后做出相应的对策。（其实就是以严重级别为准） 如果一定要追究责任的话，那就回头重新检查需求说明书和测试计划，如果上面标注而用例没有覆盖到的话，不用说就是测试员的问题，测试员要负主要责任。要是需求说明上有，测试计划中测试要点没有指出，那写测试计划的人要负主要责任当然测试人员也有责任。（如果测试员说没看过、听过需求说明，那我无语.....）要是连需求说明上都没有，那出现的任何bug与测试部门都没有关系。那是系统分析和售前的事～！ 我有这么一个案例，大家看看如何定义其主要负责人？
可将DV录制视频并刻录到光盘上（制作成DVD），这个功能是客户需要的。软件经过测试也达到了要求。但用户发现了一个CRASH的问题：录制完后，在将内容刻录到光盘前，断开DV与PC的联接，软件CRASH了。我们如何找主要责任人呢？ 软件有bug是肯定的，要不要test干什么，但并不是所有的bug test 都会发现并提交给相应的program，那么user发现bug那是一定了的，首先要有这个思想准备，不要user发现了自己负责的部分有bug 就有心理负担。
至于责任，那要看情况，如果是user新的要求，那就是项目经理的责任了；
如果是test写的testplan没有涉及到这块，但是项目经理签字了，那也是项目经理的责任；如果test写的testplan涉及到这块，但是test由于某种原因疏忽了，那就是test的责任了。 Nio，软件测试不仅仅是验证其正常操作时的可用，还要验证其在非正常操作或误操作时的鲁棒性，这个你不会不知道吧。你说的这个情况，如果测试员拍着胸脯说达到标准，呵呵，给他一棒子。 关于我上述的案例我补充几点说明吧：
1、整个测试过程还是比较规范的，有测试计划，测试用例设计（Checklist）；测试计划、测试用例经由PM（产品经理）和RD（开发人员）认同。
2、软件需求说明和功能说明，由PM和RD共同提供。
3、测试计划、测试用例(设计)以及测试的执行在这个案例中属不同分工。
4、在需求、功能、计划、用例中均没有提及这个CASE。
如何认定责任呢？
“可将DV录制视频并刻录到光盘上（制作成DVD），这个功能是客户需要的。软件经过测试也达到了要求。但用户发现了一个CRASH的问题：录制完后，在将内容刻录到光盘前，断开DV与PC的联接，软件CRASH了。我们如何找主要责任人呢？” "4、在需求、功能、计划、用例中均没有提及这个CASE。"
说说我对需求中没有提到这个case的一点理解：软件需求中应该包括显性需求和隐性需求，显性需求通常都会定义的非常明确和具体，而隐性需求就不同了，很多都不会在文档中体现出来。作为测试人员在根据开发文档进行测试设计时这两方面的需求都应该尽量考虑周全，如果是单纯根据文档中所记录的来进行设计肯定会漏掉不少case。软件不能crash应该就看成一个隐性需求，在进行故障测试时就应该考虑用各种异常或者非法操作来进行攻击性测试看能否让软件crash掉。
另外还需要强调的是个人认为这样漏掉了一个case不是什么责任问题，要说责任整个团队都有责任。当然测试人员需要进行自我总结和反思了，通过不断的总结和提高保证将来的工作中能做的更好。 这段比喻太精辟了，特此加精！
比较赞同！
如果让偶来审判，一个严重的bug我会把所有相关人员（developer/tester/QA/PM/TL）各打五十大板，嘿！
Originally posted by black_tulip at 2005-4-19 13:37:
我举个很简单的例子，以前给别人讲过。
窗明几净的大厅里有一口痰，给访问的来宾留下不好的印象。
谁的责任？
简单分析一下，为了分析方便，把前提固定，痰是一个员工吐的，大厅有专门的清洁人员，大厅的 ...
