还记得2011年，成为前公司第一位SQA的第一天，在度娘上查找“SQA”，度娘给出的答案是SupplierQuality Assurance，即供应商质量保障。搜索结果遍历好几页都没有任何跟Software搭边的信息。而如今，搜索出来的相关结果就已经很丰富了。以此可以看出SQA这个岗位在国内的市场的需求发展情况。
在正式开始前，我们还是先来看下度娘给出SQA的定义：
软件质量保证（SQA-Software Quality Assurance）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。
从度娘的解释中，我们可以看出一个关键词，体系。不管是标准、步骤还是实践和方法，都是组织的体系文件（PMI里面称为组织过程资产）。虽然SQA经常承担了很多很杂的工作内容，但是纵观这些工作内容，无不围绕着体系二字。
SQA首先是体系的维护者。从度娘给出的解释就可以看出，SQA的出现其实就是为了保证体系能够落地，使体系不再是一纸空谈，让其管理可视化。体系的维护工作是SQA日常最大的一部分工作了。
这么空谈概念，不太符合我们SQA一贯的以数据、以事实为依据的形式作风。那么我简单的罗列一些QA的日常工作来检验下此条理论：
项目关键节点评审。首先关键节点的设立，本身就是组织识别的其项目的共性的过程里程碑，只有相关里程碑能够按照组织的经验积淀在固定阶段按照固有标准通过，才能从一定意义上确保项目的按时、保质达成。所以里程碑的评审，也就是，从项目执行的大框架上检查项目的流程符合度。
软件过程审计，包括了流程符合度审计、过程KPI审计等。流程的审计不难理解，是直观的从项目组成员在项目开发过程中对流程的遵循程度的一个审计判断过程；过程KPI审计，虽然可能是一些过程结果的搜集和审计过程，比如软件的改出问题（或称衰退问题）、reopen问题、bug解决delay问题以及版本编译问题等。表面上看，是一些结果的确认，但最终的目的是想从这些质量结果数据去窥探是否存在流程上、方法上或者标准上的执行偏差或体系文件本身制定的漏洞。
质量问题回溯，有了过程审计的例子，这个就不难理解了，所有的质量问题的回溯，都是为了检讨过程问题是执行层面的问题还是说体系文件本身制定问题。即便是回溯的根本原因最终确认是技术层面的技能积累不足，那这也是组织体系建设的一个重要输入项。
质量专案改善。质量专案改善按最终产生的改善方案分类，分为体系类和技术类。体系类很好理解，就是从流程上需要完善，或从流程的宣导、执行和监督上做相关改善动作；而技术类的改善，一般无非做提升组织的某技术领域的技术能力、或做对应的技术总结以及技术领域的阶段性check。虽然技术能力的提升感觉和体系不搭边，但是要想提升技术能力一般情况下无外乎也就是通过内部培训和外部招聘两种方式了，这也就是为何SQA要承担组织内部培训组织甚至培训体系搭建工作和组织内部岗位工作职责和工作指引相关体系文档建设的一个重要原因。
另外，SQA还是体系创建和完善过程的重要参与者。
为何将体系创建放在了体系维护的后面，为何说SQA是重要参与者，其实主要是想表明，SQA在体系的创建和完善过程中，虽然常常是作为leader的一个角色，但他绝不是体系创建的主导者。
体系，是组织过程资产，它一定是组织在整个项目过程中沉淀下来的最适合该组织及其项目管理的最佳实践。
因此体系的形成不是某一个人拍下来的，一定是经过经验积累下来的，虽然最终可能是某个SQA牵头拉着几个领域leader将其文档化，但不能说就是这几个人创建了体系。另外体系的创建一定是包含了组织领导层的一些管理导向在里面的，其实从度娘给出的SQA的解释中就可以侧面看出，SQA的工作是向领导层呈现体系在项目中的执行情况的一个手段。因此体系是因组织、因项目而异的，即使是相同或者是类似的项目，不同的组织去做，也无法完全沿用完全一套的体系指导；同一个组织做不同的项目也一样。