我们需要专职的QA吗

　　前些天在网站上看到一篇名为我们需要专职的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”，谁他都受不了!

　　上面所说到的测试人员存在两个问题：

　　①测试用例的基本构成不完成，构成元素过于模糊无法达到准确测试的目的，无法实现测试用例的延续(他人无法看懂你的测试用例)

　　②测试人员对需求或测试理论理解不够，导致很多的漏洞或重复测试

原文转自：http://www.ltesting.net