通过质量内建，提高交付质量

前言

这篇文章是对“测试圆桌派”第二期线上直播的精华内容整理。

直播过程中，很多的思路和观点，都是在不断的交流碰撞以及听直播的同学提问中产生的。

关于测试圆桌派

测试圆桌派，本来是我和 CC、chenkl 老师无意中闲聊时候产生的一个想法，抱着试一试的态度举办了第一期，结果反响出乎意料的好，因此决定继续办第二期甚至更多的直播分享。

每期我们会挑选不同话题来谈谈彼此的看法以及我们在实践和工作经历中遇到的一些问题，解决方案。

话题不会仅局限于测试领域，还会有职业规划、职场发展、学习成长等很多方面。我们也希望通过直播分享，不断的产生思想上的交流碰撞，在分享的过程中，不断提升自己，探寻更多的向上的可能性。

什么是质量内建

定义：作用在开发过程中，要求软件生命周期中参与的各个角色实时对软件的质量负责，确保软件在交付到下一环节前已经有了基础的质量保证。

目的：减少因为质量问题导致的返工而浪费大量资源。

核心：及时反馈，共建质量，而不是让测试做质量兜底。

角色定位：质量是整个软件生命周期都应该关注的事情，测试是为了质量负责，但又不能局限于测试本身的一些活动。

角色解读：测试从刚开始的 QC，变为 QA，本身就是随着行业和技术的发展要求不断演进的。

质量内建的挑战

老张：文化+协同

文化：需要通过长期质量保障文化宣讲和实践，来抹平由于团队成员技术能力、认知偏差带来的不确定性。

协同：软件项目最终质量交付需要多个角色协同完成，良好沟通和高效协调是保障交付质量必不可少因素。

CC 老师：效率+约束

效率：交付质量有一点很重要，那就是效率。

约束：不能一味地追求交付过程的效率而牺牲一些东西，需要一定的流程规范，标准的组织体系和技术规范来约束过程。

Chenkl 老师：思维+平衡

思维：技术团队整体的思维需要做出转变，从质量保障是测试的工作转变为质量保障是所有人的工作。

平衡：思维转变、流程落地、质量内建体系建设并不是一蹴而就的，变革的阵痛期需要平衡落地顺序以及作出取舍。

质量内建案例分享

老张：软件工程体系

软件项目落地有三个重要的因素：质量+效率+成本。很难三者都具备，需要做出一定的平衡和取舍。

根据组织架构及项目类型、投入资源、业务类型以及团队成员技术能力，选择合适的软件工程迭代体系。

• 需求多变追求交付效率和成本的，可以选择敏捷迭代的方式，尽快交付不太影响用户使用的 MVP 版本。

• 需求稳定，追求交付质量和效率的，可以选择瀑布或双 V 迭代模型，投入更多的时间和人力技术成本来达成目的。

CC 老师：测试左移+持续反馈+测试右移+全员参与

测试左移：尽可能在测试本身活动开战之前就接入测试，包括在需求和设计阶段（形成规范+落地实例）。

持续反馈：保持高度的信息透明和及时的信息反馈，才不至于由于信息盲区导致的风险变大（尽早接入+固化流程）。

测试右移：项目交付后的线上运营也是至关重要的一环，获得用户的反馈并不断的迭代优化（灰度发布+用户调研）。

全员参与：质量内建是项目全体成员都需参与并为之负责，结合自身和公司情况，先做好自己（日志+告警+资源），形成影响力，再落地体系。

Chenkl 老师：技术标准+需求管理+持续测试+分层测试

技术标准：明确验收条件、质量卡点、技术工具的技术标准，形成约束；

需求管理：https://mp.weixin.qq.com/s/JhFvsmNB9bBCGCkrxYFoJw

持续测试：https://mp.weixin.qq.com/s/mADVauTn7GKXv_uD4Sk_uw

分层测试：持续测试和自动化测试是高效且必须的，推动自动化的标准化和分层验证。

如何理解交付质量

需求质量是卡点

• 需求描述+需求评审；

高度重视过程质量

• 研发过程质量（构建成功率、缺陷燃尽图）；

• 线上交付质量（交付时长和效率、缺陷留存）；

不要忽视线上结果

• 用户反馈；

• 埋点数据；

• 可维护性；

• 可扩展性；

质量需要持续运营

• 收集用户问题、不断反思改进、质量持续度量；

• 客户体验、客户需求、客户环境、客户沟通距离；

质量内建四大特征

风险可识别+问题可追踪+结果可验证+数据可量化！

构建质量保障体系

建立质量保障文化，通过纵向的组织标准化体系来建设底层的技术基础设施和持续的流水线交付能力，这些能力可以支撑具体的项目落地，而这些项目对需求质量、过程质量以及交付质量具有巨大的提升作用。

最后，感谢几位老师的精彩分享！

相关文章推荐

从测试看需求

持续测试持续反馈

如何建立高效的质量保障机制