SQA之旅

---

前言

时光如梭，在不知不觉中，已经在软件质量工程师的岗位上待了两年半了。这两年多的时间说长不长，说短不短，对于有目标、有规划的人来说可以获得很多东西。于我而言，是在一次次的迷茫中找寻方向。

---

一、开心的相遇

2018年公司第一次设立了这个岗位，并组建了一个过程改进小组的团队。一个Leader带领我们三个小兵，开始软件研发的过程改进之旅。

我是从软件测试转岗到过程改进组的，对过程改进工程师这个岗位的具体内容了解的并不深，只知道它也是保证软件质量的，但是区别于测试，不会具体参与到具体的测试任务，而是通过搭建工具、流程等手段保证研发质量。

Leader先定了过程改进工程师的技能要求，包含管理和技术两方面，主要是配置管理、需求工程、软件设计与实现、测试与同行评审、CMMI实施、项目管理、质量保证等。并且根据初级、中级、高级分别定义了需要掌握的技能。通过这些内容，我对软件过程改进这个岗位有了进一步的了解。看着那些内容，我知道自己需要学习的东西还有很多，但是并没有怯懦，而是很开心的同时也算是我与她的第一次相遇。

二、懵懂的相识

由于我们团队中多是新人（毕业一两年，都未做过软件质量的工作），领导虽然有很多年工作经验，但是对于软件过程改进的具体工作也是初次接触，所以我们多是在摸索着前进（其中的艰难可想而知）。
我们先从两方面着手：

1. 缺陷分析
2. 配置工具

1. 缺陷分析

每月定期获取各团队的缺陷，进行缺陷分析。当时我们对各团队产生的Bug进行一个个分析，从严重级别、Bug引入原因、Bug漏测原因等几方面进行分析、总结，然后再分别召集各团队的开发负责人召开质量会议。会上主要是提出我们发现的问题，由开发负责人给出相应的改进措施；会后我们会跟进各团队改进措施的执行情况。

作为软件研发的第三方团队，这种方式可以帮助我们深入了解各团队软件研发的具体工作情况，从中发现一些过程问题，有助于我们统一制定一些改进措施。同时我会总结各团队经常遇到的问题，再找一些经验丰富的开发同事一起组织培训，至于效果只能说是因人而异。

2. 配置工具

1. wiki：本身软件研发已有wiki这样的知识网格系统，但是并未在所有团队中推广。我们在wiki中开辟了各个团队的模块，供团队内部使用。
2. 评审工具：TFS2012以上版本开始支持在线提交代码评审，虽然我们一直用TFS做为代码开发、管理工具，但其实这些新功能并未使用，大家都是通过手动提交搁置集、口头通知的方式进行的。为了方便代码走查，我们利用TFS提供的代码审核功能，同时建立了邮箱通知系统，向各个团队进行了推广。当时要求签入代码之前必须进行代码审核，但是工具不支持强制审核的功能，后面我在GitHub上找了一个插件（国外一个大神编写的，源码都有），可以增加一个签入策略，就解决了这个问题！
3. 代码检查：CPPCheck（C++）、SonarQube（C#）
4. 持续集成：基于TFS建立起持续集成的简易流程（详见下一篇“基于TFS的持续集成搭建”），只实现了自动编译，还是手动触发。

通过以上的活动，我们逐渐开始认识过程改进工程师。

三、艰难的相伴

俗话说万事开头难，对于我们更是难上加难。两年多的时间我们工作的内容一直在变，但都是围绕着工具、研发活动、研发流程展开的。

1. 研发活动

主要围绕缺陷分析、编码、代码审核、方案设计、功能规格设计几个活动开展。

1. 缺陷分析：完善缺陷分析的流程，提供缺陷分析的模板、分析的维度，给大家培训缺陷分析的方法（根因法、流入/流出分分析法、人机料环法测等）
2. 编码：完善编码规范、提供编码规范检查工具（最初靠人工抽查过一段时间，有一定的效果，但是很难坚持下来）、制定代码审核的checklist、明确代码审核的流程和内容
3. 方案设计：提供方案设计模板、方案评审checklist，规范方案评审的流程
4. 功能规格设计：提供功能规格设计模板、功能规格评审checklist，规范功能规格设计流程。这个活动涉及的内容很多，所以当时专门找IT帮忙做了一个信息化管理系统来支撑这个活动。

其实后面还增加了单元测试、自动化测试活动的推行。只是这一块我们是交给团队自己作的，我们主要是协调者。

2. 研发流程

这一块其实并未真正作出一套流程，当时只是建立了一个基础的框架，后面会详细介绍这一块内容。

3. 工具

在工具上其实还是围绕最初的工具进行的，只是加深了使用。比如Sonarqube，与持续集成工具一起使用。持续集成不仅仅是最初的编译打包，还有单元测试、自动化测试、编码规范检查等。

其实我们团队中间换了好几个领导，人员数量也是一再减少（虽然最初就没有几个人，可能公司也没指望我们能有多大动作吧），以上那些内容看着没有多少，好像都是比较简单的。实际执行过程中遇到过很多问题，毕竟研发人员有将近200人，单凭我们几个人的力量去推行一个东西，是很困难的，并且很难做到check，虽然我知道这个很重要，但其实这一块做的并不好！一是没有人力、时间，二是缺少检查的手段。

四、坚定的相守

其实转到过程改进组这两三年，在工作上我一直没有什么成就感，并且还经常受到打击。常常感觉到压力很大，做的也不是很开心，说到底还是自己的能力不足，才会造成现在的样子！

所以虽然压力大，但我依然选择不离不弃，所以接下来打算从以下方面进行提升：

1. 质量相关理论知识：熟悉CMMI各个过程域的内容、ISO9001的质量相关内容。
2. 软件工程：这一块其实并未系统学习，里面内容只是知道一些简单的知识。选了一本大学教材先进行学习。
3. 项目质量管理：这一块目前正在工作中学习、实践。
4. 需求工程：之前买了一本Microsoft的需求工程的书籍，看了一点，感觉还不错，计划先从这本书入手。

五、思考

最近几年“研发效能”这个词很火，大佬们都在研究如何提高研发效能，但是如何衡量研发效能呢？

过程改进中的活动有很多，采取的措施也有很多，如何评价措施的有效性呢？

软件质量从哪几个维度评价合适呢？

---

总结

软件质量工程师需要具备的知识很多，在推行一些活动时还容易不被人理解。之前时常听到一些人说，你们制定的流程有什么用，除了麻烦还是麻烦，解决不了真正的问题。很明显这是对自己工作的否定，难过之余也会与耐心与其沟通，了解他所谓的真正的问题是什么，然后再反思自己哪里做的不够。

因为从事过程改进工作，所以接触的人也比较多，包括各团队的领导。与每个人深入沟通，都能发现其身上的闪光点，从中我也学到了很多，处理事情的方式、遇到问题时的解决思路、与人沟通的方式等。