产品诚可贵，质量价更高

• 缘起
• 所属行业
• 研发人员规模
• 所在团队规模
• 团队开发模式
• 产品类别
• 软件主体层次
• 软件交付周期
• 软件需求质量/感受/问题
• 设计质量保证及好与不好
• 开源组件
• 代码质量
• 千行缺陷数
• 单元测试代码覆盖率和测试质量
• 质量文化和QA人员
• 测试团队人员配置
• 质量工程活动
• 功能用例自动化占比
• 工具组合
• 2022年质量工作重点和问题
• 2023年质量改进
• 2023年自动化测试投入
• 缘落

缘起

叮~~~，有消息过来了，一看是测试领域博主拾|贰发来的信息，如下：

我们再来看看，某公司对级进行精简后的过程，即“精简并行过程”：

• 是基于以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范”，它由众多的过程规范和文档模板组成。主要用于指导企业持续地改进其软件过程能力；
• 含义是：

（1）对CMMI 3级以内各过程域的内容和要求作了“精简”处理。
（2）在产品生命周期之内，项目管理过程、项目研发过程和机构支撑过程“并行”开展。

适合自己的开发模式才是最好的开发模式有最好，只有更好~

产品类别

产品类别不管是还是，个人觉得他的质量重点应该有所偏向；
比如说某些团队它本身成熟度就摆在那里，但非要让他把做成的质量要求：

• 这里不是说没有质量要求高，而是侧重点不同；
• 可能更偏向于个人使用，用户体验程度和交互设计质量可能有所偏重；
• 的产品量级可能更大，比如性能方面等偏向（猜测）。

不能眉毛胡子一把抓，针对不同的产品，质量工作重点应该有所偏向。

软件主体层次

关于软件的主体，我们团队更多偏向应用系统的后端+应用系统的前端；
那对我们测试团队来说，我们常用的质量测试手段就是接口测试了；
我看现在比较常用的几个工具和框架为：

• 工具：、、等；
• 框架：

• 语言：、居多；

产品交付周期和很多因素有关，最直接的就是是否有标准化作业过程

软件需求质量/感受/问题

需求质量保障，目前主要是：

• 有明确的的需求管理和规范；
• 会进行初审、再审、终审；
• 变更管理；
• 需求管理和维护平台等；

目前对团队的需求比较满意，因需求中最值得点赞的是：

• 有需求跟踪矩阵；
• 有需求唯一标识；
• 完善的模板参考；
• 需求的可追踪性；
• 合格性规定；
• 各种指标的明确等。

代码质量尤其重要，测试质量不等于产品质量。

质量文化和QA人员

产品设计过程中，我们一定要有质量文化，她就是无形的力量，帮助每个人树立起质量意识；
质量文化不是一句口 那么简单，要融入到产品开发过程中，比如我们需要有严格的绩效考核和质量目标：

• 这里我觉得的流程是非常值得学习的，像其中的点的过点要求，其实就是一种质量保障；

http://u.uin.com/external/publishInfo.shtmld=6203&objectType=%CE%C4%D5%C2

总之我觉得测试应该以独立的团队存在。不过有些开发模式并不太适合，比如敏捷开发。

质量工程活动

目前开展的质量活动是用户体验工程：

• 分内部用户和外部用户；
• 内部用户主要为除了测试、研发、需求、产品等之外未使用过软件的人员；
• 外部用户主要是“天使客户”；
• 制定详细的问题收集和跟踪模板，定期进行用户体验活动竞赛；
• 当然不止这些，这是个系统工程了，这里不赘述了。

功能用例自动化占比

功能测试用例数的自动化实现占比已经大于90%了，但是自动化并不是全能的；

• 从他的优缺点可以看出，要达到90%其实还挺难的，就看业务的复杂程度了；
• 如果团队有实力做自动化，当然专人去做更好，没有的话可能做自动化反而是投入和产出不成正比，得不偿失。

考虑做自动化最主要是清楚它的应用场景：

常见的工具（仅为举例）：

对自动化又爱又恨，爱它确实带来了很多方便，恨它对它不了解的人瞎搞自动化。

缘落

• 以上就是，仅仅是个人想法，不代表任何组织、团体；
• 以上内容难免有错误或偏见，欢迎指正；
• 做产品，我们三两人坐一起，推敲、熬夜很可能就能做出来；但是做好产品，质量为先，它涉及的领域、面都非常广，可谓产品诚可贵，质量价更高。
• 再次说明个人观点（不喜勿喷，嘎嘎嘎~）：

凡涉及“行为、动作、过程、活动等”均会涉及质量，质量无处不在。

所有的问题最终要落到团队、管理、流程、制度上。

质量从组织架构、质量文化、质量体系上进行牵引可能有更好的效果。

质量不等于测试，一个成功的高质量产品的质量，势必是从干系人、到团队、到客户、到公司层面的质量总和。