质量保证（一）

什么是质量保证？

质量保证（Quality Assurance）也是质量管理的一部分，它致力于提供质量要求会得到满足的信任。质量保证是指为使人们确信产品或服务能满足质量要求而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动。质量保证一般适用于有合同的场合，其主要目的是使用户确信产品或服务能满足规定的质量要求。

质量保证的内容绝不是单纯的保证质量，保证质量是质量控制的任务，质量保证是以保证质量为其基础，进一步引申到提供“信任”这一基本目的。
[注： 以上摘录至百度百科]

谁来做？

我在08年左右，就因为公司要进行ISO9000质量体系的认证，而接触了质量保证这一概念，且很长很长一段时间都一直认为，由测试人员为了保障产品质量而从事的一系列软件测试过程（例如：测试计划、环境准备、数据准备、用例设计、用例执行、Bug验证等等）称之为质量保证过程。但随着时间的不断推移以及在工作中的不断实践，才发现测试人员所承担的角色，不足以对整个产品的质量进行把控，它只是整个质量保证体系中的一环，需要研发、测试、运维的共同协作，才有可能形成一个相对可靠的质量保证过程。

测试的对象到底是什么？

经典的答案是：源程序、目标程序、数据及相关文档。

但随着目前微服务架构的越来越流行、越来越盛行，软件在架构、部署等方面都有了天翻地覆的变化，这个答案现在还适合吗？是合适的、但也是不合适的，取决于您对于测试人员的要求如何。

为什么是研发、测试、运维？而不仅仅是测试？

在与研发人员沟通中，是否会经常听见这样的

1. 这段代码是之前离职的那位同事写的，写的真垃圾
2. 我虽然知道这段代码可以优化，但是我不敢动他，不知道会影响哪里
3. 架构就是这样设计的
4. 这是经过评审的

在与运维人员沟通中，是否会经常听见这样的

1. 没有抓到日志
2. 刚才那个问题不知道什么原因，重启就好了
3. 不知道是谁操作的，东西给删除了

在于测试人员沟通中，是否会经常听见这样的

1. 业务我很清楚，但是不知道数据是如何流转的
2. 我不知道服务部署在哪里，那不是运维干的事情吗
3. Docker？那是啥玩意

那么，你看出什么问题了吗？

1. 代码编写没有规范
2. 服务运行态没有监控
3. 日志没有记录
4. 系统不够了解
5. 基础知识不够扎实
6. 岗位之间分工不够明确
。。。。。。
问题太多太多了，多到单独拿出来讲，都能讲个一天一夜。。。

肿么办？

怎么做？

从个人的经验来看，要想取得一个好的结果，那么必须具备几个方面：

优秀的规划

1. 清晰的质量要求说明；
2. 科学可行的质量标准；   
3. 组织建设项目质量体系；
4. 配备合格和必要的资源；
5. 持续开展有计划的质量改进活动；
6. 项目变更全面控制。

明确的分工

1. 研发人员，负责代码风格统一、覆盖率测试、单元测试
2. 测试人员，负责集成、系统、验收过程中的软件测试活动
3. 运维人员，负责系统规划、系统部署、系统运维阶段的软件要求，包括规范的制定、系统的监控、日志的分析

持续的改进

1. 明确的度量考核体系，引导改进的方向
2. 坚定不移的支持
3. 及时的鼓励与肯定

从下一篇开始，就将围绕 团队、质效、考核、改进 等方面进行系统的阐述，如何根据实际情况来建设质量保证团队。