去年 4 月份,在测试圆桌派第二期的直播分享中,聊了质量内建对提升交付质量的作用。
近一年学习了很多新的知识,也在和其他同行的交流分享中,对质量内建有了新的一些理解。
这篇文章,我想聊聊质量内建在团队中落地的四要素。
在软件研发领域,无论是我们提倡的各种设计原则,不断演进的系统架构或者各种技术组件的出现,其本质是为了解决软件系统的质量问题。这个质量可以是功能性的,也可能是体验方面的,或者以更低的成本交付。
软件测试的本质是验证交付的产品符合产品设计的预期标准,以及是否存在可能影响产品质量或者体验的风险。软件工程的本质也是聚焦于交付质量,为了在不断迭代过程中解决质量不可控而产生的一系列方法论和最佳实践。
我们都知道一句话叫做“质量是设计和构建出来的,不是测试出来的”。
对于质量内建,我在前文聊到过,它的作用是在软件的整个生命周期中,要求参与的各个角色实时对软件的质量负责,确保软件在交付到下一环节前已经有了基础的质量保证。质量内建的目的是为了减少因为前期风险不可控而导致后期的修复成本增加,进而浪费大量资源。
质量内建,与其说是一套方法论,我更认为其本质是一种思想和文化。通过全生命周期的全员对质量负责的理念,来指导在实际的软件研发过程中关注质量,提高设计和构建质量。
从软件工程的角度来说,影响质量的三要素如下图:
从敏捷研发的角度来说,影响质量的因素也是范围、时间和成本,只不过演进之后的关系如下图所示:
好的交付质量会影响业务价值的达成,而影响质量的三要素又对质量形成了一种约束关系。结合上述的 2 张图,以及我们在日常工作中遇到的影响质量的各种问题,我个人认为要落地质量内建,要面临这几点挑战:
业务是不断变化的,团队成员也可能在不断变化,伴随着技术的不断迭代升级,以及可能存在的政策因素,要保障高质量的软件研发交付,第一个要解决的就是控制这些变化因素。
业务的变化是否有连贯性,团队成员的变化是否能保证技术沉淀和经验的有效传递,技术的迭代升级是否有严谨的调研和验证,政策因素是否有足够的风险评估,这些都是为了保障质量要考虑的。
传统的理念还是质量全系于测试团队,测试成为那个拿着锤子敲钉子的人。但质量内建,要求我们关注需求质量、设计质量、编码质量、构建质量等很多环节。
我们需要一种更好的方式来让团队成员认可这种全员对质量负责的理念,通过一定的形式推动在具体的实践中去践行这种质量文化。这个过程中,质量门禁是很重要的一个因素,也是质量团队需要首选关注的。
需求质量、设计质量、编码质量、构建质量都会影响最终的交付质量,这就要求我们在软件的全生命周期的每个环节,都有科学合理的方法来指导具体的实践。无论是倡导了几十年的敏捷,还是近几年比较火热的 devops 等方法,其实都是在不同阶段对质量保障的比较好的指导方法。
软件研发毕竟是个技术活儿,好的软件工程能力才能提高生产效率。这对团队在工程能力和基础能力建设方面有较高的要求。无论是 CICD,还是各种监控、链路追踪甚至数据采集度量,都需要一定的工程能力支撑。
上面提到了落地质量内建的四大挑战,从我个人理解和实践经验来说,可以从这四点入手:
组织:首先在组织层面,要制定合理的流程规范来尽可能保证即使业务迭代和人员更迭,业务和技术的经验有足够的沉淀,这样做的好处是抹平由于不同团队成员技术能力、认知偏差带来的不确定性。还有就是组织需要从更高维度,尽可能保证业务和技术迭代的连贯性,避免重复的造轮子和重开战场,导致团队成员为了按时交付而疲于奔命。
文化:文化的形成是一个长期持续的过程,既需要组织的不断宣讲,也需要在具体的实践中去践行和认可这种文化。而且文化认可的建设,需要一定的激励机制和容许犯错的空间。思维转变、流程落地、质量内建体系建设并不是一蹴而就的,变革的阵痛期需要平衡落地顺序以及作出取舍。
方法:无论是敏捷或者 devops,其实都提出了很好的可参考的优秀实践和方法,比如:测试左移、持续反馈、测试右移、质量运营等具体的实践方法。这些方法没有先后顺序,在落地过程中要根据具体情况选择适合自己团队的,先小范围落地,拿到好结果,形成影响力,然后在不断扩大范围,最终形成体系化。
工具:上面提到了影响交付质量的三要素,其实成本和时间是互相影响的。但两者之间有个共同追求就是效率,而各种工具或者平台就可以大幅提高研发过程的效率。比如 CICD、监控平台、链路追踪、数据工厂、质量度量、自动化测试等工具平台,可以帮助质量内建更高效的落地。
领取专属 10元无门槛券
私享最新 技术干货