【讨论】那你说我们需要专职的QA吗？
2012-04-12 14:51 Tester Chen 阅读(2337) 评论(6) 编辑 收藏 举报前些天在博客园的网站上看到一篇名为我们需要专职的QA吗？ 让我很让震惊！
发这篇文章的目的，并不是对原作者的看法表示如何的批评，且说出自己的想法（自认中正的看法），希望各位园友能说出你的看法，也希望我能解释很多开发人员的疑惑。
为了支持原作者，贴出原始链接：我们需要专职的QA吗？
紫色的文字为引用原文，因为引用文章很长。
在开始今天的讨论之前，先看几个名词解释（参考）：
质量保证（QA）：QA（QUALITY ASSURANCE，中文意思是“品质保证”，通过过程的持续改进来提高产品质量，是软件成熟度模型（CMMI/ISO）中的一个角色
QA可以对开发的具体技术不了解，但要对CMMI、ISO900等的流程要清楚
软件配置管理（SCM）：配置管理(Configuration Management，CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程（其中涉及到基线的概念），确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置；
配置管理包括六大任务：配置标识、版本管理、变更管理、配置审核、状态报告、发布管理，配置管理的最重要的是版本管理和发布管理；
配置管理往往是配置在质量部统一进行管理，现时还要为测试提供一个测试环境，即我们讲的搭测试环境。
软件测试（Tester）：使用人工或者自动手段来运行或测试某个系统的过程（他是一个验证的过程），其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别，通俗的说是去验证两个方面：是否做了正确的某事，是否正确的做了某事
QA通过对流程（过程）的持续改进来提升产品的最终质量；软件测试通过技术来保证产品的最终质量；配置管理是对过程产品及软件生命周期进行管理。
所以，到这里我们就可以看到，其实标题中把测试和QA的概念混为一谈，是错误的！
“我们都同意，Dev 要懂测试，QA 要懂开发，只不过分工不同，既然你中有我，我中有你，那就不要分彼此了，一起携手开发测试吧 （另外，我个人觉得不懂开发的测试人员不可能测试得好”）
对于上面的观点我是认同的。
至于园子中转载的文章，我不知道作者是谁，既然是分享，那么我们来看一下作者的故事：
我们暂且沿用作者的QA称谓
“我 再说说我最糟糕的 QA 经历吧，这个公司的 QA 部门只做测试，他们的 leader 觉得所有的 test design 和 test 的过程都不需要 Dev 参与，他们是独立于 Dev 之外的部门，他们几乎不关心 Dev 的设计和实现，他们只关心能跑通他们自己设计的 test case。但是去执行 Test Case 的时候，又需要 Dev 的支持，尤其在环境设置，测试工具使用，确认是否是 bug 方面，全都在消耗着 Dev 的资源，最扯的是，他们对任何线上的问题不负责，反正出了问题由 Dev 加班搞定。”
上面的文字包含了很多分享者公司的情况，不知是不是可以猜测如下：
把测试能独立于开发之外（把需求视若无物）进行，这首先是Tester或Leader认知层面上的一个错误（是否作者的理解有误差暂且不论）；
或者可能从中看出来，分享者的公司中没有测试总监、测试组长之类的Leader或者他们的资质明显不足以胜任他们的工作，才会出现前面所说的将测试独立于开发和其他部门而存在；
我们或者可以从Dev的抱怨中看到，公司的测试人员资质不够（不懂得基本测试工具的使用，不擅长自我学习、自我突破），过分的依赖本身已有的知识及开发人员的协助；
公司对于需求的管理很粗或者根本没有管理（或者还是测试人员的理解能力太差，无法理解需求的含义，无法分辨需求与实现之前的差异是否可以定义为Bug），如果有明确的需求管理，则不会出现经常无法确认是否Bug的情况；
我们可以从字里行间，感觉分享者的公司好像是为了测试而测试，要知道测试的目的是为了最终的质量，这一点在整个公司上下的目的都是一致的，任何的工作都不能偏离这个目标而存在
我认为：
公司要做好测试工作保证质量，公司从CEO到普通员工有质量意识很重要，只有从意识上认识到质量的重要性，才能真正的做好质量的管理，没质量的意识，其他就都是空中楼阁；
同时优秀的测试总监和测试组长是保证测试工作质量的前提 ，相信强将手下少弱兵；
不要认为任何人都能做好测试，基层测试人员的素质很重要（懂开发的测试人员或Dev最好，还要有专业系统的测试理论，同时最好了解需求或业务），他们最终的测试执行者，是质量保证的第一关和最后一关；
需求管理与需求培训很重要，遇到需求问题，沟通很重要；
质量部不是摆设，测试人员也不是找茬的家伙，大家的目标要一致的---质量
“我有一次私自 review 他们的 test case 的时候，发现很多的 test case 这样写到 – “Expected Result：Make sure every thing is fine” ，WTF，什么叫“Every thing is fine”？！而在 test case design 的时候，没有说明 test environment/configuration 是什么？没有说明 test data 在哪里？Test Case、Test Data、Test Configuration 都没有版本控制，还有很多 Test Case 设计得非常冗余（多个 Test Case 只测试了一个功能），不懂得分析 Function Point 就做 Test Design。另外，我不知道他们为什么那么热衷于设计一堆各式各样的 Negative Test Case，而有很多 Positive 的 Test Case 没有覆盖到。为什么呢，因为他们不知道开发和设计的细节，所以没有办法设计出 Effective 的 Test Case，只能从需求和表面上做黑盒。”
我很能理解这会Dev的感受，测试人员把预期结果写成“Every thing is fine”，谁他都受不了！
上面所说到的测试人员存在两个问题：
①测试用例的基本构成不完成，构成元素过于模糊无法达到准确测试的目的，无法实现测试用例的延续（他人无法看懂你的测试用例）
②测试人员对需求或测试理论理解不够，导致很多的漏洞或重复测试
但是我要告诉你的是“这和测试没有什么关系，这所有的一切都只能说明，你们的测试人员很滥，他们的很滥直接影响到了你对整个测试的理解”；
同时，我要讲的是是否了解需求与是否做黑盒测试没有关系，下面是黑盒测试的概念可以参考一下：
黑盒测试：也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
所以，如果遇到上面的情况，不应该是说对软件测试失去信心（因为我们需要更好的保证质量），而应该向你的上级反应，我们需要更称职的测试人员！！！
建议去51Testing上看一看有关软件测试方面的信息
“在做性能测试的时候，需要 Dev 手把手的教怎么做性能测试，如何找到系统性能极限，如何测试系统的 latency，如何观察系统的负载（CPU，内存，网络带宽，磁盘和网卡I/O，内存换页……）如何做 Soak Test，如何观察各个线程的资源使用情况，如何通过配置网络交换机来模拟各种网络错误，等等，等等。”
这就是我上面说的，测试人员的本身素质太差，无法实现自我学习，自我提升与自我突破的情形
要知道在工作中要用到的东西并不是我们都会的，在这种情况下，我们就要积极主动的去学习，个人认为在有压力的情况下学习，往往是事半功倍的！
“在项目快要上线前的一周，我又私自查看了一下他们的 Test Result，我看到 5 天的 Soak Test 的内存使用一直往上涨，很明显的内存泄露，这个情况发生在 2 个月前，但是一直都没有报告，我只好和我的程序员每天都加班到凌晨，赶在上线前解决了这个问题。但是，QA 部门的同学们就像没发生什么事似的，依然正常上下班。哎……”
首先要肯定的是测试人员没有测试好，开发人员没有开发好，所以谁也不要说谁做得不好。人非圣贤，离孰能无过焉！
出现问题时，先解决问题，而不是先追究责任，在问题解决之后，我们需要讨论问题产生的原因，如何避免下次再出现这样的情况，同时如果可以追溯到相关的责任人，我们要进行一定的处理，但处理不是重点。
出现一些紧急的情况，加班难免，要能扛得住！
“为什么会这样？我觉得有这么几点原因（和邹欣的观点一样）
1、给了 QA 全部测试的权力，但是没有给相应的责任，
2、QA 没有体会过软件质量出问题后的痛苦（解决线上问题的压力），导致 QA 不会主动思考和改进。
3、QA 对 Dev 的开发过程和技术完全不了解，增加了很多 QA 和 Dev 的沟通。
4、QA 对软件项目的设计和实现要点不了解，导致了很多不有效的测试。”
1、质量部的责任是很重的，一量出现漏测或出现线上事故，质量部是要承担一半或以上的责任的（但具体的也要看公司的情况，如果没有系统的管理，这个很难说）
2、软件出现问题，测试人员是不是要重新测试，甚至有时候要加班加点（至于分享者说的他们测试人员不管什么时候按时下班，这还是归结到测试人员的素质问题，就无关乎能力了）是常有的事；计算机行业是一个快速发展的行业，不思考不主动学习，你很快就会被淘汰，如果你的公司的测试人员还抱着过去的知识、抑制学习、被动思考，那么你可以让他回家抱孩子，热坑头……
3、测试人员不了解软件工程或开发语言的情况常有，但有时候我们也需要精通业务的人来进行测试，这个是很重要的！
4、这个涉及到我前面讲过的对需求的管理与测试人员对需求的理解，以及对基础测试理论的缺失
从以上的几个观点来看，可以看出来文章的作者对测试人员还是很存在一定的理解偏差的，他的问题主要是把他们公司的测试一些人员当成了整个软件测试行业！
如果他可以跳出他们公司，去质量管理规范的公司看一看，或许能有极大的改观，不知道他本身是否认可？
“我越来越觉得软件开发，真的不需要专职的 QA，更不需要只写代码不懂做测试的专职的 Dev”
关于作者的这句话，我不敢完全苟同，我觉得更应该这样说：
“我越来越觉得需要软件测试人员，但不需要不专业的测试人员，更不需要只写代码不懂做测试的专职的 Dev”
我为什么我不说“我们需要专业的测试人员”而不是说“我们需要懂开发的测试人员”？
专业，包括懂需求、懂开发、懂测试理论的人员，也包括懂业务、懂需求、懂测试理论的测试人员，这两者都是我们需要的优秀的测试人员！
“1） 开发人员做测试更有效
开发人员本来就要测试自己写的软件，如果开发人员不懂测试，或是对测试不专业，那么这就不是一个专业的开发人员。
开发人员了解整个软件的设计和开发过程，开发人员是最清楚应该怎么测试的，这包括单元测试，功能测试，性能测试，回归测试，以及 Soak Test 等。
开发人员知道怎么测试是最有效的。开发人员知道所有的 function point，知道 fix 一个 bug 后，哪些测试要做回归和验证，哪些不需要。开发人员的技术能力知道怎么才能更好的做测试。
很多开发人员只喜欢写代码，不喜欢做测试，或是他们说，开发人员应该关注于开发，而不是测试。这个思路相当的错误。开发人员最应该关注的是软件质量，需要证明自己的开发成果的质量。开发人员如果都不知道怎么做测试，这个开发人员就是一个不合格的开发人员。
另外，我始终不明白，为什么不做开发的 QA 会比 Dev 在测试上更专业？ 这一点都说不通啊。”
闻道有先后，术业有专攻！
首先我对写下这段文字的Dev表示我的景仰，你能说出这番话说明你还是对软件测试、对软件质量、对Dev本身的测试还是有一定的了解和意识的。
但是，要知道软件测试也是一个系统的过程，和软件开发一样，他有一个长期的过程，开发人员通经系统、完善的培训或者可以成为一个优秀的测试人员，这个不虚假；但是术业有专攻，开发人员专攻的是开发，测试人员专攻的是测试（最最好是彼此都有一些了解）。开发人员要进行的测试是对基础功能的粗略测试，因为他有更重要的开发工作要去完成，做不到详细的完全测试；而测试人员一方面要详细的对基础功能进行测试，还要对很多很多的细支末节进行测试，尤其是平常经常使用的或可能会出现，但一般人很少想到的，在测试中我们称之为场景，测试人员要对各种可能出现的场景进行测试，往往这种测试是很烦琐的。
同时，专业的测试人员和专业的开发人员一样，都是要经常系统、完善的培训才能正式以一名合格的测试人员的身份上岗的，所以说，不能单纯的去怀疑Tester对测试的专业性……
“2）减少沟通，扯皮，和推诿
想想下面的这些情况你是否似曾相识？
QA 做的测试计划，测试案例设计，测试结果，总是需要 Dev 来评审和检查。（不是说测试需要依赖开发，这是本身的一个沟通、交流，是保证质量的一个流程需要，在CMMI\ISO中是有明文的规定的）
QA 在做测试的过程中，总是需要 Dev 对其测试的环境，配置，过程做指导。（这个是为了保证测试的正确性，要是因为配置不正确而导致误报，当如何？）
QA 总是会和 Dev 争吵某个问题是不是 BUG，争吵要不要解决。（是不是缺陷需要相互沟通，需要判断优先级，需要参考需求，需要领导定夺，而不是开发和测试的吵，凡事要有依据）
无论发现什么样的问题，总是 Dev 去解决，QA 从不 fix 问题。（Tester fix Bug？部分的缺陷是可以，如果他有开发的经验，但你会放心么？项目经理能放心么，术业有专攻）
我们总是能听到，线上发生问题的时候，Dev 的抱怨 QA 这样的问题居然没测出来（出现漏测，是双方的责任，不要想到推诿责任，这样的人不仅人品存在问题，连职业道德也值得重新审视）
QA 也总会抱怨 Dev 代码太差，一点也不懂测试，没怎么测就给 hand over 给 QA 了。（所以说开发要懂测试，提高交付质量，避免低级错误，但有偶尔有也是可以理解的，人非圣贤嘛）
QA 总是会 push Dev，这个 bug 再不 fix，你就影响我的进度了。（相互理解、支持）
等等，等等。
如果没有 QA，那么就没有这么多事了，DEV 自己的干出来的问题，自己处理，没什么好扯皮的。
而一方面，QA 说 Dev 不懂测试，另一方面 Dev 说 QA 不懂技术，而我们还要让他们隔离开来，各干各的，这一点都不利于把 Dev 和 QA 的代沟给填平了。要让 Dev 理解 QA，让 QA 理解 Dev，减少公说公有理，婆说婆有理的只站在自己立场上的沟通，只有一个方法，那就是让 Dev 来做测试，让 QA 来做开发。这样一样，大家都是程序员了。”
（扯皮，多么俗的字眼，当然不是说这种情况没有，但这种情况是不应该的，还是那句：相互的沟通、相互的理解、统一的目标很重要）
“3）吃自己的狗食
真的优秀的开发团队都是要吃自己狗食的。这句话的意思是——如果你不能切身体会到自己干的烂事，自己的痛苦，你就不会有想要去改进的动机。没有痛苦，就不会真正地去思考，没有真正的思考，就没有真正的进步。
在我现在的公司，程序员要干几乎有的事，从需求分析，设计，编码，集成，测试，部署，运维，OnCall，从头到尾，因为：
只有了解了测试的难度，你才明白怎么写出可测试的软件，怎么去做测试的自动化和测试系统。
只有自己真正去运维自己的系统，你才知道怎么在程序里写日志，做监控，做统计……
只有自己去使用自己的系统，你才明白用户的反馈，用户的想法，和用户的需求。
所以，真正的工程师是能真正明白软件开发不单单只是 coding，还更要明白整个软件工程。只明白或是只喜欢 coding 的，那只是码农，不能称之为工程师。”
这段的理解，说明文章作者对开发者自测还是有比较深的理解，比较重视的！
一个优秀的程序员，不，应该是工程师，要知道的、要做的还是很多的！
“关于 SDET。全称是 Software Development Engineer on Test。像微软，Google， Amazon 都有这样的职位。但我不知道这样的职位在微软和 Google 的比例是多少，在 Amazon 是非常少的。那么像这样的懂开发的专职测试可以有吗？我的答案是可以有！但是，我在想，如果一个人懂开发，为什么只让其专职做测试呢？这样的程序员分工合理吗？把程序分成两等公民有意义吗？试问有多少懂开发的程序员愿意只做测试开发呢？所以，SDET 在实际的操作中，更多的还是对开发不熟的测试人员。还是哪句话，不懂开发的人是做不好测试的。”
虽然我对上面的“不懂开发是做不好测试的”这句话表示同意，但反过来我是不能同意的，是存在需求（业务）测试工程师，也就是说他们不懂开发，但相当的精通业务、需求
只要是对工作、对最终的目标是合理的，那么怎样的工作都是需要人去完成的，所以不要认为做哪样工作就不怎么的，这个可以做为你奋斗的动力，但不能作为评价一个人的标准
“如果你说 Dev 对测试不专业，不细心，不认真，那么我们同样也无法保证 QA 的专业，细心和认真。在 Dev 上可能出现的问题，在 QA 也也会一样出现。而出了问题 QA 不会来加班解决，还是开发人员自己解决。所以，如果 QA 不用来解决问题，那么，QA 怎么可能真正的细心和认真呢？”
是的，都会出现问题，开发人员开发代码时会出现问题，所以需要测试；测试人员测试会出现问题，所以需要开发人加班加点解决问题；而往往两者都会出现问题
在这个问题上作者陷入了一个死循环中，记住“没有成功个人，只有成功的团队”
“如果你说不要 QA 的话，Dev 人手会不够。你这样想一下，如果把你团队中现有的 QA 全部变成 Dev，然后，大家一起开发，一起测试，亲密无间，沟通方便，你会不会觉得这样会更有效？你有没有发现，在重大问题上，Dev 可以帮上 QA 的忙，但是 QA 帮不上 Dev 的忙。”
首先肯定作者话，如果能从开发中转过来部分专业的测试人员，这样对于项目肯定是有帮助的，但我们仍然需要质量管理体系来管理，通过流程来保证我们的产品/项目质量
从文章作者的言语中可以看到他作为开发人员的优越性，而这种优越性容易造成的结果是：“我不应该来做这个事，我可以做更高级、更有难度的事”
有人说态度决定一切，虽然我不太赞成这句话，但我也明白一个人的能力重要，一个人的心态也很重要
最后，让一个优秀的开发人员做测试确实有些浪费，公司损失不起
“第三方中立，你会说人总是测不好自己写的东西，因为有思维定式。没错，我同意。但是如果是 Dev 交叉测试呢？你可能会说开发人员会有开发人员的思维定式。那这只能说明开发人员还不成熟，他们还不合格。没关系，只要吃自己的狗食，痛苦了，就会负责的。”
思维定式、个人习惯、自我保护意识是三个魔鬼
当然测试人员也有这三个魔鬼，所以测试负责人在安排测试时，一般会交叉测试，具体的涉及到测试策略的问题，就不在这里说了
越多的测试越能保证产品的质量，所以一般都会要求开发人员对自己的程序进行测试，会有代码评审，会有同行评审，其中的原因也就不言而喻
“磨刀不误砍柴功。如果你开发的东西自己在用，那么自己就是自己天然的 QA，如果有别的团队也在用你开发的模块，那么，别的团队也就很自然地在帮你做测试了，而且是最真实的测试。”
说的没有错，是测试，但是不完全的测试，对于质量我们追求的是质量的零缺陷，虽然那不可能实现，而实现的基础是专业、系统、完整的测试
“关于自动化测试。所谓自动化的意思是，这是一个机械的重复劳动，我想让测试人员思考一下，你是否在干这样的事？如果你正在干这样的事，那么，你要思考一下你的价值了。但凡是重复性比较高的机械性的劳动，总有一天都会被机器取代的。”
知道为什么人没有被机器人替代么？
因为人有无穷无尽的思想
“关于线上测试。我们都知道，无论自己内测的怎么样，到了用户那边，总是会有一些测试不到的东西。所以，有些公司会整出个 UAT，用户验收测试。做产品的公司会叫 Beta 测试。无论怎么样，你总是要上生产线做测试的。对于互联网企业来说，生产线上测试有的玩A/B测试，有的玩部分用户测试，比如，新上线的功能只有 10% 的用户可以访问得到，这样不会因为出问题让全部用户受到影响。做这种测试的人必然是开发人员。”
UAT是用户会要求进行的，如果不做接收测试，客户不满意你的项目，后期的款项如何收回？
Beta测试一方面是通过线上的真实情况，检查程序的功能、性能，同时也是对市场的试探、对用户的试探，观察市场、用户对产品的响应，为公司的后期决策做以参考。
写在结尾：
对于你的耐心，Tester Chen很感谢，成文时间仓促，如有不妥，希望留下你宝贵的意见、建议。
文章已被51Testing转载，地址：http://www.51testing.com/html/12/n-811612.html
（51testing软件测试网在软件测试培训领域遥遥领先、并提供完整的软件测试服务）
