小白进阶之SQA软件质量保证工程师工作职责与素质要求
叮嘟！小白进阶，每天掌握一点常见问题小常识，写篇博客分享一下。
一、 SQA 工作职责与素质要求
软件质量保证（即 SQA——Software Quality Assurance ），是 CMM2 级中的一个关键过程域 , 它是贯穿整个软件过程的第三方独立审查活动，出现在大多数关键过程域的检查与验证的公共特性中，在整个软件开发过程中充当重要角色。
从 CMM2 级中包含的 6 个关键过程域来看，无论是需求管理、软件项目计划、软件项目跟踪与监控，还是软件子合同管理、软件配置管理，都不同程度地存在于我们现在正在进行的软件项目开发过程中，对于它们的了解我们已经不再陌生，只有 SQA 这个关键过程域，是在我们准备以 CMM2 级要求的关键过程域为基础进行软件过程改进前未接触过的。在很多软件企业中还没有与之相对应的人员和工作方法，整套关注软件开发过程的软件质量保证体系还没有建立起来。所以，在企业以 CMM2 级关键过程域为参考进行软件过程改进时， SQA 往往是一个难点，直接涉及到组织结构的变化。
二、实施 SQA 的目的
软件质量保证的目标是以独立审查方式，从第三方的角度监控软件开发任务的执行 , 就软件项目是否正遵循已制定的计划、标准和规程给开发人员和管理层提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程组取得高质量的软件产品。主要包括以下四个方面：
● 通过监控软件开发过程来保证产品质量 ;
● 保证开发出来的软件和软件开发过程符合相应标准与规程；
● 保证软件产品、软件过程中存在的不符合问题得到处理 , 必要时将问题反映给高级管理者；
● 确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审和审计需要 ;
除了以上四点之外，我们还希望 SQA 能作为软件工程过程小组（ SEPG ）在项目组中的延伸，能够收集项目中好的实施方法和发现实施不利的原因，为修改企业内部软件开发整体规范提供依据，为其他项目组的开发过程实施提供先进方法和样例。
三、对 SQA 人员的素质要求
SQA 人员 ( 有时简称 SQA) 要有很强的沟通能力。从实施 SQA 的目的中可以看出， SQA 不在项目中，是独立于软件项目的第三方，但他要了解项目的开发过程和进度，捕捉到项目中不符合要求的问题，这就要求 SQA 能够深入项目，和软件开发经理以及项目组中的开发人员保持很好的沟通，这样才能及时获得真实的项目情况。SQA 要熟悉软件开发过程。作为 SQA ，既然要确保项目组制定的计划、标准和规程，要符合项目组要求，那么 SQA 首先自己就要了解软件项目开发过程，以及企业内部已经有的开发过程规范。SQA 本身要有很强的计划性。SQA 一方面要监督软件项目组编写计划，另一方面 SQA 自身的工作也要有计划，并且能够按照计划开展工作。SQA 要能应对繁杂的工作。作为 SQA ，在跟踪项目进行过程的时候要对项目组的很多工作产品进行审计，而且会参与项目组中的多种活动。同时一个 SQA 还有可能会面对多个项目组，所以任务相对繁杂细碎，这就要求 SQA 在处理这些事物的时候要耐心细致。SQA 要客观，有责任心。作为第三方对项目过程进行监督， SQA 要能保持自己的客观性，不能一味讨好项目经理，也不能成为项目组中的宪兵，否则会影响工作的开展。对于项目组中多次协调解决不了的问题，能够向项目的高层经理进言，完成 SQA 的使命。
以上五点是作为 SQA 应该具备的基本素质，除此之外，一个好的 SQA 还应该在软件开发过程中作为开发人员或测试人员参与过一个或多个环节，这样他们才能在过程监督中比较准确地抓住重点，同时他们的意见和提出的解决办法也会更贴近项目组，容易被项目组接受。
四、SQA 人员的组成
软件企业中的 SQA 人员既可以由全职人员担任，也可以由企业内具有相关素质、经过 SQA 培训的人员兼职担任。由此组成的 SQA 小组可能是一个真正的物理上存在的独立部门，也可以是一个逻辑上存在的平台。但不管是真正的独立部门还是逻辑上的平台，它都需要有一个灵魂人物 ——SQA 小组组长，来组织 SQA 小组的日常活动。
在给一个项目组分配负责监督其项目过程的 SQA 时，一定要注意一点：就是该项目的 SQA 不能是该项目组的开发人员、配置管理人员或测试人员，一个项目的 SQA 除了监控项目过程，完成 SQA 相关工作以外，不应该参与项目组的其他实质性工作，否则他会与项目组捆绑在一起，很难保持客观性。
五、SQA 工作的内容
SQA 的工作内容主要包括以下六类：
与 SQA 计划直接相关的工作：SQA 在项目早期要根据项目计划制定与其对应的 SQA 计划，定义出各阶段的检查重点，标识出检查、审计的工作产品对象，以及在每个阶段 SQA 的输出产品。定义越详细，对于 SQA 今后的工作的指导性就会越强，同时也便于软件项目经理和 SQA 组长对其工作的监督。编写完 SQA 计划后要组织 SQA 计划的评审，并形成评审报告，把通过评审的 SQA 计划发送给软件项目经理、项目开发人员和所有相关人员。参与项目的阶段性评审和审计：在 SQA 计划中通常已经根据项目计划定义了与项目阶段相应的阶段检查，包括参加项目在本阶段的评审和对其阶段产品的审计。对于阶段产品的审计通常是检查其阶段产品是否按计划按规程输出并内容完整，这里的规程包括企业内部统一的规程也包括项目组内自己定义的规程。但是 SQA 对于阶段产品内容的正确性一般不负责任检查，对于内容的正确性通常交由项目中的评审来完成。 SQA 参与评审是从保证评审过程有效性方面入手，如参与评审的人是否具备一定资格、是否规定的人员都参见了评审、评审中对被评审的对象的每个部分都进行了评审、并给出了明确的结论等等。对项目日常活动与规程的符合性进行检查 :这部分的工作内容是 SQA 的日常工作内容。由于 SQA 独立于项目组，如果只是参与阶段性的检查和审计很难及时反映项目组的工作过程，所以 SQA 也要在两个阶段点之间设置若干小的跟踪点，来监督项目的进行情况，以便能及时反映出项目组中存在的问题，并对其进行追踪。如果只在阶段点进行检查和审计，即便发现了问题也难免过于滞后，不符合尽早发现问题、把问题控制在最小的范围之内的整体目标。对配置管理工作的检查和审计：SQA 要对项目过程中的配置管理工作是否按照项目最初制定的配置管理计划进行监督，包括配置管理人员是否定期进行该方面的工作、是否所有人得到的都是开发过程产品的有效版本。
这里的过程产品包括项目过程中产生的代码和文档。跟踪问题的解决情况 :对于评审中发现的问题和项目日常工作中发现的问题， SQA 要进行跟踪，直至解决。对于在项目组内可以解决的问题就在项目组内部解决，对于在项目组内部无法解决的问题，或是在项目组中跟催多次也没有得到解决的问题，可以利用其独立汇报的渠道报告给高层经理。收集新方法，提供过程改进的依据：此类工作很难具体定义在 SQA 的计划当中，但是 SQA 有机会直接接触很多项目组，对于项目组在开发管理过程中的优点和缺点都能准确的获得第一手资料。他们有机会了解项目组中管理好的地方是如何做的，采用了什么有效的方法，在 SQA 小组的活动中与其他 SQA 共享。这样这些好的实施实例就可以被传播到更多的项目组中。对于企业内过程规范定义的不准确或是不方便的地方，软件项目组也可以通过 SQA 小组反映到软件工程过程小组，便于下一步对规程进行修改和完善。
六、SQA 与几类角色间的关系
一个企业内的部门设置可能会各有不同，但是很多角色设置是相同的，从一个项目的 SQA 出发，我们可以把 SQA 与其他相关角色的关系表示为下图 :
以上图示只说明 SQA 与高层经理、项目组和其他相关组之间的关系，并不是以上几个角色之间所有关系的描述，所以即便项目组会直接向高层经理汇报，但与 SQA 无直接关系，在图中就没有表现出来。
七、SQA 工作中常见的几个问题
最初给项目组配置 SQA 人员的时候， SQA 的价值不被认可 。因为是新工作的初次开展，已经习惯了自己管理项目，向高层经理汇报的项目组难免会有抵触情绪。
要从两个方面解决这个问题：一方面，从组织的角度，要明确 SQA 的角色及其合法性 ; 另一方面， SQA 也要以其专业的工作赢得项目组认可，为项目组增加价值。一个全职的 SQA 可以同时兼任多少个项目的 SQA 工作对于不同的项目规模和组织管理方式，这个问题会有不同的答案。根据实施中的一些经验总结，通常在第一次实施时，承担一个 20 人左右的项目组的 SQA 工作需要占用一个人 30% 左右的工作量，随着 SQA 的成熟，这个比例会降低到 15% 。对于一个 10 人以内的项目组， SQA 需要投入其 10% 左右的工作量。当然，项目越大 SQA 的投入就越多。SQA 与项目组的关系难处理。对于 SQA 与项目组的关系，应该遵循以下两条原则 : 要在过程方面成为项目组的严师，有错必纠，但不能有错全报；要做项目组的朋友，但不能对项目组包庇纵容。项目组有了 SQA ，可是需求文档和设计文档的质量还是不高 。
对不起，这不是 SQA 的直接工作范围。提高需求和设计的质量，要从人员培训和严格评审入手，让有经验有资格的人来完成需求和设计文档。 SQA 只能从规程符合方面进行监督。
总之，在软件企业中建立 SQA 体系，是软件项目管理由人治到法治的一个必经阶段，也是软件企业以 CMM 模型为参考，进行软件过程改进中一个不可缺少的部分。软件企业只要真正建立了 SQA 规范，培养了专业的 SQA 人员就会真正从中体会到它的好处。
小结！
学海无涯，学无止境。
让我们一点一滴积累吧，相信水滴石穿，总归功夫不负有心人。
就酱，嘎啦！
注：小白进阶，每天都在学习的路上。
