前言
这篇文章是对“测试圆桌派”第二期线上直播的精华内容整理。
直播过程中，很多的思路和观点，都是在不断的交流碰撞以及听直播的同学提问中产生的。
关于测试圆桌派
测试圆桌派是老张和CC、chenkl老师无意中闲聊时候产生的一个想法，抱着试一试的态度举办了第一期，结果反响出乎意料的好，因此决定继续办第二期甚至更多的直播分享。
每期我们会挑选不同的话题，来谈谈彼此的看法和观点，以及我们在实践和工作经历中遇到的一些问题，解决方案。
话题不会仅局限于测试领域，还会有职业规划、职场发展、学习成长等很多方面。我们也希望通过直播分享，不断的产生思想上的交流碰撞，在分享的过程中，不断提升自己，探寻更多的向上的可能性。
什么是质量内建
定义：作用在开发过程中，要求软件生命周期中参与的各个角色实时对软件的质量负责，确保软件在交付到下一环节前已经有了基础的质量保证。
目的：减少因为质量问题导致的返工而浪费大量资源。
核心：及时反馈，共建质量，而不是让测试做质量兜底。
角色定位：质量是整个软件生命周期都应该关注的事情，测试是为了质量负责，但又不能局限于测试本身的一些活动。
角色解读：测试从刚开始的QC，变为QA，本身就是随着行业和技术的发展要求不断演进的。
为什么要做质量内建
1.质量没法通过测试在短时间内进行一个本质的提高，软件开发出来质量已经在那儿了。所以大家有没有发现，如果一家公司有一定的时间成本去从根本上提高质量，并不是说让测试不停的测而是选择重构。
2.随着软件复杂度的增加，只关注测试本身活动，并没有办法预知软件的不确定性，也就不能去保障软件质量的各个层面。
举例：
不知道大家有没有一种感觉，往往在一些作坊式的公司，测试层面从单点解决问题往往比较难，通过一些零碎的资源去做一些长期建设的工作，也不太能保证收益，提出的困难总比你要表达的诉求还多，包括软硬件环境，团队组织，这是一种现状，有的同学经历过多家公司会发现在一些公司很难做成的事情在另外一家公司就是基本操作，比如说业务测试中的单元测试，比如说冒烟执行的通过率，比如说性能测试的数据需求分析，这一点最大的区别已经变成基本操作的公司都已经在做执行质量内建的实践，而很难做成的公司别说实践，他们可能连质量内建的意识都么有，或许根本也不了解什么是质量内建。对于我们测试人员来说，说小一点会影响我们的工作环境，工作环境的好坏会影响我们的心情；说的大一点，一些局面没有打开，有可能会影响我们的职业生涯。
质量内建的挑战
PS：三位老师通过几个关键字总结了不同的一些挑战，下面是关键字释义。
老张：文化+协同
文化：需要通过长期的质量保障文化宣讲和实践，来抹平由于团队成员技术能力、认知偏差带来的不确定性。
协同：软件项目最终的质量交付需要多个角色协同完成，而良好的沟通和高效的协调是保障交付质量必不可少的因素。
CC老师：价值+约束
价值：认清交付的价值，设计质量的层次。
约束：不能一味地追求交付过程的效率而牺牲一些东西，需要一定的流程规范，标准的组织体系和技术规范来约束过程。
我想聊一聊与质量相关联的两个关键词是价值和约束，技术的价值是用业务来体现的，有一些同学说我们业务很赶，老是压缩开发测试时间，如果测试话语权比较弱，那测试时间更是容易被压缩，其实像这种情况你可以说他不合情，但我的观点是存在即合理，你的饭碗都是业务给的，你有什么理由去不停的吐槽呢，当然也并不是一味的去接受，而是如何去应对这样的情况，而质量内建就是一个比较好的方式，通过在不同的阶段比如需求、研发等等有相应的输出标准，这样通过团队去保障质量肯定比测试本身去做要好得多，就像踢足球，场上不给力，总指望守门员扑球，这样还能赢得比赛几乎是不现实的。而不同的项目对质量要求也是不一样的，比如银行类和一些活动类的，活动类往往需求到上线时间都比较赶，不涉及到金钱的情况，可以优先保证住流程走通，而银行类项目往往就没有人敢说这话，所以质量他也是有层次的，需要听取业务的声音，去探讨在既定时间内完成的质量标准。所以聊到这里，我们就聊到另外一个关键词约束，约束在我的定义里面是在多久的时间内有多少人力成本完成多大范围的事情，而这样的方式也就要求我们事情一定要细化，在现实中去寻找解决方案。所以说，跟一些同学聊质量内建，他会说你们公司不错，我们这边就不行，其实都有一个0-1建设的过程，而有些公司一些前辈已经完成了这部分工作。而前期的工作，往往不是技术，更多需要去做的是核心成员认知的趋同，这方面本质就是文化的形成。
Chenkl老师：思维+平衡
思维：技术团队整体的思维需要做出转变，从质量保障是测试的工作转变为质量保障是所有人的工作。
平衡：思维转变、流程落地、质量内建体系建设并不是一蹴而就的，变革的阵痛期需要平衡落地顺序以及作出取舍。
质量内建案例分享
老张：软件工程体系
软件项目落地有三个重要的因素：质量+效率+成本。很难三者都具备，需要做出一定的平衡和取舍。
根据企业组织架构以及项目类型、投入资源多寡、业务类型以及团队成员技术能力，选择合适的软件工程迭代体系。
- 需求多变，追求交付效率和成本的，可以选择敏捷迭代的方式，尽快交付不太影响用户使用的MVP版本。
- 需求稳定，追求交付质量和效率的，可以选择瀑布或双V迭代模型，投入更多的时间和人力技术成本来达成目的。
CC老师：测试左移+持续反馈+测试右移+全员参与
测试左移：尽可能在测试本身活动开战之前就接入测试，包括在需求和设计阶段（形成规范+落地实例）。
持续反馈：保持高度的信息透明和及时的信息反馈，才不至于由于信息盲区导致的风险变大（尽早接入+固化流程）。
测试右移：项目交付后的线上运营也是至关重要的一环，获得用户的反馈并不断的迭代优化（灰度发布+用户调研）。
全员参与：质量内建是项目全体成员都需参与并为之负责，结合自身和公司情况，先做好自己（日志+告警+资源），
形成影响力，再落地体系。
Chenkl老师：技术标准+需求管理+持续测试+分层测试
技术标准：明确验收条件、质量卡点、技术工具的技术标准，形成约束，下面是Chenkl老师的两个案例：
需求管理：
https://mp.weixin.qq.com/s/JhFvsmNB9bBCGCkrxYFoJw
持续测试：
https://mp.weixin.qq.com/s/mADVauTn7GKXv_uD4Sk_uw
分层测试：持续测试和自动化测试是高效且必须的，推动自动化的标准化和分层验证。
如何理解交付质量
需求质量是卡点
- 需求描述+需求评审；
高度重视过程质量
- 研发过程质量（构建成功率、缺陷燃尽图）；
- 线上交付质量（交付时长和效率、缺陷留存）；
不要忽视线上结果
- 用户反馈；
- 埋点数据；
- 可维护性；
- 可扩展性；
质量需要持续运营
- 收集用户问题、不断反思改进、质量持续度量；
- 客户体验、客户需求、客户环境、客户沟通距离；
质量内建四大特征
风险可识别+问题可追踪+结果可验证+数据可量化！
构建质量保障体系
建立质量保障文化，通过纵向的组织标准化体系来建设底层的技术基础设施和持续的流水线交付能力，这些能力可以支撑具体的项目落地，而这些项目对需求质量、过程质量以及交付质量具有巨大的提升作用。
对于客户交付的一些补充：
上面说的大部分基于内部交付的，那对于外部交付来说既包括对内交付，更重要的是面向客户交付，我还想去增加一些内容，外部交付需要更关注你的产出物是不是客户想要的，他涉及到跨团队跨公司的沟通，有可能会有更多的信息差，你有没有充分的从客户角度去对接这是非常重要的，那什么是客户角度呢？
1.业务需求的匹配度，这个事情不能说最终交付的时候和客户对接需求，而是平时每次的stoy，里程碑以及可能的会议里面都需要持续确认。
2.与客户对接要充分的进行端到端测试，一些同学认为只保障自己的模块没问题就ok了，并没有充分考虑与客户方集成测试方案，出了问题其实都会造成客户满意度下降，大部分客户尤其是客户老板并不会去考虑你出问题的原因，只会觉得合作不是很顺利。
3.客户基于什么样的环境也是需要你考虑的，基于docker，k8s，jdk的版本等，这部分有出入同样也是很容易在客户环境不能跑通的，而且后续的调整也会很累。
4.与客户是需要保持一定距离的持续沟通，关于持续沟通我上面已经说了，防止造成的需求理解偏差以及实现偏差，而保持一定距离，是让自己有一个清醒的认知，你的边界在哪里，会不会因为疏忽或者过度沟通的问题导致需求蔓延，给自己团队带来被动。
