该帖子同步发自：(dynamic99的博客  访问该博客)

1         前言

近期有SQA抱怨工作内容不明确，发展方向不清晰；同时也发现有些QA在实际工作中对工作方法、目的和意义了解不够，导致对待工作任务比较粗糙，工作效果大打折扣。

这种现象对于在质量工作领域的筒子们来说很正常，就如同人力资源岗位一样，这个领域和岗位是企业运作的辅助岗位，是一个保障性的平台，是为了保障公司的主要业务能够顺畅运行的有效机制。然而，正因为这样，很多人容易迷失方向，不清楚自己的未来在哪里，如何工作才能起到作用，为公司业绩带来影响的同时为自己的未来做好铺垫。

要做一个合格的SQA，需要走的路很长。国外有很多案例，其中一些模式都值得我们借鉴，比如：SQA需要至少5年的开发经验，SQA有权给项目开不符合项并责成项目整改，SQA可以直接向高层领导汇报等。在中国国情下，有些做法很难被认同。那么，SQA该怎么做呢？

这里稍微整理一下思路，给还在这个岗位或立志于这个岗位的筒子们参考。

2         SQA的工作范围和职责

SQA的工作范围和职责，不同国家、不同公司的差别还是比较大的。主要分为：过程QA、产品QA，这俩类的具体做法也差别很大。

过程QA：一般公司的定位是过程和方法推广、过程审计、过程数据收集和分析、过程改进，有些公司分得更细致，过程QA只是做过程审计，不关心改进工作，另外设立了过程改进工程师。

产品QA：一把公司的定位主要是做软件系统测试，验证产品需求和发现产品缺陷为目的，确保在产品发布到客户前产品符合客户提出的需求，质量达到可发布的标准。

这里重点说说过程SQA的主要工作范围和职责：

1）            熟悉和了解项目和产品特征，理解和指导项目进行过程定义；

2）            熟悉和了解企业标准和公司标准，并指导项目按照标准实施项目活动；

3）            跟踪项目进展，了解项目偏差情况，包括进度、质量、范围、问题和风险等，并及时向项目经理发出预警；

4）            根据项目计划制定项目审计计划，并按照计划实施审计，其中包括过程审计和部分产品审计；

5）            针对审计的不符合项督促制定预防纠正措施，并跟踪关闭；

6）            制定项目数据收集和度量计划，并按计划实施数据收集、分析和报告；

7）            负责制定和实施组织级的内外部审计，以发现偏差和改进方向，为后续改进规划做准备。

3         SQA的工作方式

职责很清楚，但操作起来却有些困难。作为监管部门，难免在实施中会有很多阻碍。这里面首先我们自己要理清楚思路，以下这几点就是两个核心思想：知己知彼（1和2）、胡萝卜（3）加大棒（4、5）的策略：

1） 项目和产品运作模式的理解

对于自己要服务和监管的项目或产品，如果自己是外行，完全不懂，那么你怎么能够理解项目的语言，知道项目需要什么过程、适合什么管理模式呢？接手一个项目，最初始的工作内容就是项目和产品的学习。作为SQA不需要了解到代码级，但是需要懂得产品需求、产品系统架构、主要的设计方案和测试方案，只有这样才能与项目组有着共同语言，给出的建议或意见才更有发言权。

2） 对项目进展的了解度

知道了产品干什么的，项目的计划和范围，接下来的是项目进展跟踪。很多SQA不太跟进项目，待审核时则拿着检查单，凭借检查单的条目机械的去寻找证据。检查单帮助我们关注到该关注的点，不至于遗漏。但是检查单无法帮助我们理解项目组为什么这样做，是否合理。只有跟进了项目，知道项目如何在开展，你才能很快了解到检查项缺陷是项目组未有效开展还是标准本身需要调整。

由于不属于项目组的直接成员，很多信息只能间接获取。我们推荐的一些方式包括：日常沟通、参加项目例会、参加项目方案讨论或评审、参加里程碑会议、查阅项目文档、查看项目数据、了解项目问题或风险解决情况等等，通过这些活动以方便要使得项目组认为SQA是项目组成员之一，同时也能获得很多的项目信息，便于判断当前项目需要的支持或者改进。

关于参加项目活动，有一个现象是：项目组通常不会主动的通知SQA去参加，导致SQA不能及时参与项目活动获得相关信息。我们通常是与项目组项目经理协商，确定哪些活动是SQA必须参加的，并由项目经理通知到SQA。同时，也要求SQA主动关注项目的日常活动，自行选择参加。

3） 给以项目的咨询和支持度

这点上其实是对SQA本身有很高的要求，如果自己对过程理解不到位，对产品和项目特点不清楚，对项目的组织结构和管理模式不熟悉，那么虽然有检查单帮助发现问题，但却不一定能给出合适的解决方案。这点不容易做到，也是项目人员最为关心和最易抱怨的。SQA除了以上的两点自身充实外，需要学习业界的很多专业知识，包括软件工程、度量、质量知识、组织标准和模板等，至少在过程领域是需要能发出权威的声音，获得项目的认可，在项目需要时能够给以必要的支持和引导。这其中包括：给以标准、制度和模板的使用指导，定期观察项目情况并及时提醒，定期出具项目质量数据给项目组做参考，协助项目经理分析项目问题等等，这些活动会让项目组真正体会到SQA的价值所作。

4） 畅通的汇报机制

历来任何事情要有效推动都需要有胡萝卜加大棒，对于质量工作也是一样。光给以支持、引导和帮助，但是没有有效的惩罚措施，说什么也是白搭。遇到能力水平较高的项目团队，可能工作较好开展，但若遇到认识不到位的项目团队，此时光依靠单方面的引导而不给以压力，工作会在很长时间内不会有成效。虽然，我们说工作要做到人心，首先理解到位了再说操作的问题，但是实践中很多事情往往是先推动和落实，在此过程中不断加深理解。这种体验很多很多，也往往产生了良性的结果，因此是值得的。因此，在制度上需要给以保障，包括考核机制和汇报机制。

说到汇报机制，这个度往往是SQA比较犯难的。什么情况下需要汇报给QA经理、产品总经理或高层？对审计发现问题的处理，我们的原则是：一般的不符合项，首先由QA与项目成员或项目经理协商制定改善措施，之后由项目组实施、QA跟踪关闭；以下情况SQA需要汇报给产品总经理及其QA经理：1是当项目组在计划时间内没有落实相关措施，且无任何合理的解释时；2是项目组有合理理由，但未在合理的期限内解决时；3是项目发生的问题或不符合程度比较严重时。此时QA经理需要与产品总经理沟通协商确定改进措施，并指派项目经理或专人进行处理；若仍然没有成效时，QA经理负责向公司高层汇报，以便督促相应工作的落实。

5） 对公司考核制度的把握

公司制度体现了公司的业务方向和关注重点。对于软件产品而言，SQA的发现是保障产品质量、进度和成本的关键环节之一，需要作为KPI之一纳入考核体系。只有有了考核指标的要求，并逐步分解为可落实的措施上，才能有效开展工作。说到考核，有一点是需要关注的：在考核设计中对SQA工作成果的应用要关注最终结果而不是过程，最为简单的例子是，日常审核的结果不能作为考核内容，而半年或一年的定期审核，可以专门用于考核，以便于评估考核周期内项目的质量状况和改进情况。

4         SQA的审计方式和重点

QA的审计其实是有方法的，而不是简单机械的使用检查单去审核。我们尤其反对那种日常不参与项目活动，只在审核时才出现的方式。然而到底要怎么审计效果才更好呢？

1） 检查单的使用

使用检查单做审计是一种非常好的方式，检查单帮我们总结了需要审计的范围和关注点，好的检查单甚至也积累了很多人对某过程的深刻理解，对于知识传承、培养新人起着很重要的作用。同时，也是检查结果的一个客观反映，杜绝了太多的人为干扰。因此，我们要求所有组织标准和过程都要有检查单相对应，以便QA能够有效开展工作。

但是，检查单本身的质量、使用检查单人的能力对于最终应用结果起着重要的影响。因此，我们重视检查单但不能依赖检查单，我们强调对各检查单条款的具体理解，并在检查中需要融会贯通。

2） 证据和访谈的使用

SQA审计中很关注证据和访谈的作用，尤其是直接证据。由于在直接证据中能够很轻易的获取到项目实施情况的数据，从一定程度上客观反映了情况，也避免了与人交流的复杂性，尤其是对不喜欢与项目沟通的QA。有好处也有坏处，既然是看证据，项目团队也存在为了审核而造证据的现象，无法真实反映项目能力水平。

因此，审核要采取多种方法，包括看证据、访谈合适的人员，同时结合日常对项目的了解给出判断。若有了日常的了解，基本上我们能够看出来证据的有效性和项目的实际情况，并能够给出合适的审核结果。

3） 规范性和有效性问题

审核要关注的两个方面，1是规范性，2是有效性。规范性比较容易检查，通过检查单、证据和访谈都可以获取到，更多看到的执行结果。而有效性要求更高，不仅仅关注做到没有，而且关注怎么做，为什么这么做的问题。这里就需要SQA有着较高的素质才能做好。有两点我们发现SQA经常遗漏，但实际上却对审核有效性很重要：1是检查需求的可追溯性，2是检查计划执行状况。任何过程的检查前，我们需要先了解项目初始计划、当前计划和当前状况，以便确定项目当前应该做到什么，没有做到什么；当检查项目的工程过程时，无论是设计、开发还是测试过程，都需要关注需求的可追溯性，抽查几条需求，检查是否在相应的设计开发和测试环节中都考虑到，这是很关键的，只有这样才能看出项目团队是否是为了文档而写文档，而是真正考虑了项目的需求。

4） 检查计划和检查结果

SQA在项目启动后就应该制定项目审核计划，审核计划应该与项目立项时的计划相匹配。当项目计划调整时，QA审核计划需要相应的进行调整，以便能够跟上项目的节奏，起到及时预警的作用。

每次审计的结果，对于符合项和不符合项都需要进行确认，包括项目团队的确认和QA经理的评审，尤其是针对新QA的工作成果更需要评审和确认的过程。很多QA经理一忙就难以保证这点，实际上是工作质量的缺失。