前些天在网站上看到一篇名为我们需要专职的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最好，还要有专业系统的测试理论，同时最好了解需求或业务），他们最终的测试执行者，是质量保证的第一关和最后一关；
