从测试看质量内建

从测试角度看质量内建-质量内建

前情回顾：

质量，一个看似完全免费的东西：游离于项目中， 好像一个幽灵， 你不知道他的样子， 你甚至不知道他是否存在过。可人人都担心有那么一天，这个幽灵突然出现，告诉你，你的项目完蛋了。

所以在项目上总会有角色和这个幽灵“斗智斗勇”。

Quality is free. It’s not a gift, but it’s free. The ‘unquality’ things are what cost money.

-- Philip B. Crosby

因质量问题导致项目损失或者失败的事件历历在目， 从软件工程这个门类诞生直到现在，人们都在强调质量， 力图在每个环节都对质量有把控，力图将发生隐患的概率减到最小，在军工和制造业，这种现象更加的明显，也催生了CMMI这种目前权威的标准。

转回来再看现今的软件开发， 硬件和软件技术的飞速发展将工程的方法论提高到了一个新的高度，短平快的项目模式已经成为了软件工程的主流。

那让我们再看一下项目三角：

图片.png

你会发现， 我们依然无法冲破时间，范围和成本互相制约的这个底层逻辑。

但与之前相比，敏捷的交付模式已经可以用更短的时间， 更少的成本覆盖更大的范围了， 这是一个飞跃，但不要忘了那个“幽灵”。

试想一下：

• 如果你的项目是用1周的时间带领你的团队研发一个核心的支付模块，项目中没有做任何质量保证的动作，即使在1周的时间内，完成了研发，你是否有自信将项目推至线上？

• 如果是，那么这个项目在显示那个发生了支付漏洞， 公司的损失如何估计？

在这个短平快的交付时代，所有的项目都像是满级的武林高手，出手迅速，武功高强，内力雄厚...刀光剑影中往往一个走神一个失误就会一败涂地。

这就使得我们不得不回头看看那个幽灵在哪里：

图片.png

想想看，质量放在这里非常的贴切， 他是在项目中，平时不会被察觉，但是它会作为同时制约时间，成本和范围的因素， 它也是导致项目出现风险的常见因素（无论是在项目初期还是项目后期）。

以上是从策略方面看，质量在项目中的位置。从实战方面上看， 质量也有自己的位置：

从软件开发模型上看，往古可以回溯到V模型， X模型， 螺旋模型，往今可以推演到敏捷模型， SAFe, DevOps，任何一种模型或者工程实践都共同承认一个道理

项目中问题存在的时间越久，修复它的代价就越大

图片.png

图：不同阶段发现问题的数量和修复的成本

显然， 最好的做法就是把这些问题“扼杀在摇篮里”。再做的精细一些，就是把每个步骤都按照“一边做一边检查”的做法完成， 保证每个步骤都能在这个步骤中交付含有最高质量的交付物。这就是将质量刻入项目中每个细节甚至DNA的方法--狭义质量内建（下文简称质量内建）

要了解质量内建如何做之前， 我们需要先分析在质量内建的各个环节，以及项目整体，需要做什么才能提高质量

首先是各个环节，试想

需求：如果可以清晰的描述需求， 确保需求的描述， 客户的项目， 和开发的实现三者完全一致。

开发：如果保证写出的代码没有缺陷，可以完美运行

测试：如果所有的问题都可以在测试环节中被找到

运维：如果所有的即将发生的问题都会提前10天预警

图片.png

别喷，我也知道这是完全不可能的！！！

也正是因为需求和开发的假设是不可能的， 才会催生测试和运维这两种保障类的软件行业细分。

但凡测试和运维的假设达成；也不会因质量问题造成任何的代价。

然而更重要的是， 虽然这个愿景我们目前没有办法去达到，但是可以无限接近它， 通过很多的项目实践和工程方法的落地（这些工程方法在后续会介绍）；甚至有很多的sprint迭代中， 开发，测试已经达到了这个愿景！这也证明了去无限接近这些愿景并非不可能。

说回质量内建， 那不就是通过种种活动来无限接近这个愿景的行动吗？

从项目的各个环节上看，质量内建相关应该保证需求尽量澄清，开发尽量高质，测试尽量充分，运维尽量机警。

遵循了这些原则的活动， 认为都可以属于质量内建。

除此之外， 从全局项目角度来看， 完备的项目流程， 高效的软件，清晰的看板和视图等等都可以是质量内建的体现。

总结一下：

质量内建应该是质量保证的核心手段

质量内建是降本增效的手段

质量内建应该是全项目生命周期的工作，它应该是项目中的每一个人的责任

质量内建可以作用于项目各个环节，也可以作用于项目整体

质量内建与敏捷：

提到质量内建这个概念，往往需要和敏捷这个概念成对出现， 正是因为敏捷将原有的项目过程碎片化，机动化，灵活化， 使得原有的传统项目质量保证的手段也发生了演化，成为了新的质量保证活动--质量内建。

引入SAFe框架中的一句话很好的阐述了质量内建与敏捷方法论的因果关系：

企业能否以最短的可持续交付周期交付新功能，并适应快速变化的业务环境，取决于解决方案的质量。因此，毫不奇怪，质量内建是安全的核心价值观之一，也是敏捷宣言的原则之一，“持续关注技术卓越和良好设计增强敏捷”。质量内建也是精益敏捷思维的核心原则，有助于避免与召回、返工和修复缺陷相关的延迟成本（CoDs）。外部质量内建理念应用系统思维来优化整个系统，确保整个开发价值流的快速流动，并使质量成为每个人的工作。

质量内建与测试：

有些人依然认为质量是测试的事情， 与自己无关， 因为一个合格的测试通常都会进行很多保证质量的动作，但需要注意，测试仅仅是对质量的验证，质量从需求定下来那一刻或者代码提交的那时起就生效了。

测试无疑是在项目中可以推进质量的最佳角色，但绝对不是唯一角色和主要角色。

引用一句话：

质量是建出来的， 不是测出来的。

下期预告：

作为质量的密切接触者--测试，更是在这场斗争的最前沿。在下一个章节，我会给大家介绍作为质量内建的先锋，可以使用何种事件来辅助质量内建。