质量保证如何成为可能
质量保证如何成为可能
拒绝任何不证自明的政治正确
在我们的语境中，经常有些观点是不证自明的，是一种政治正确，没有人提出质疑。比如提高单元测试覆盖率，比如要求保证质量。我们是不是应该问一问，质量保证是可能的吗，以及质量保证是如何成为可能的？
我们只有认真回答了质量保证如何成为可能，才算是给质量保证是否可能以有效的肯定答案。
战国策·魏策四
今者臣来，见人於大行，方北面而持其驾，告臣曰：“我欲之楚。”臣曰：“君之楚，将奚为北面？”
曰：“吾马良。”曰：“马虽良，此非楚之路也。”曰：“吾用多。”臣曰：“用虽多，此非楚之路也。”曰：“吾御者善。”
此数者愈善而离楚愈远耳。
这里提出一个至楚如何成为可能的问题？魏人给出的正方回答是，他具备三个条件：
- 马良
- 用多
- 御者善
季梁给出的反方质疑就一句话：此非楚之路也。
在论证某目标是否可能的时候，正方需要给出达成这个目标的必要条件列表，而反方则需要给出不能达成目标的充分必要条件。
学这个寓言的时候，当时就有小朋友为正方增加了辩护的必要条件：地球是圆的，往北走也可以到楚国。
当然，季梁还可以继续再提出质疑，北方有熊出没，可能西伯利亚都没到就被熊干掉了。
不管怎么说，任何一个观点，都应该经过反复论证、反复辩难。我们不应该接受任何未经证明的观点，不管看上去多么不言而喻。
可能大家会问，质量可以保证这个观点，经过论证辩难的接受与政治正确的直接接受，有什么区别？
区别就是经过论证的接受，会得到一个正方的必要条件列表，和一个反方的充分必要条件。我们在质量保证的落地实施过程中，就会如履薄冰的保持正文的必要条件，也会小心翼翼的提防反方的充分必要条件。
正方条件是质量木桶的长板，论证的是质量保证的可能性，是质量木桶的可能达到的水平。反方条件是质量木桶的短板，论证的是质量保证不可能达到的水平。一旦成立，立刻证伪，所以反方条件在实证科学的认识论中极为重要。
总之，我们需要清醒的认识到，质量保证是有前提、有条件的，并没有政治正确的坚实基础。
南辕北辙的魏国人，还知道论证至楚之所以可能，是因为马良、用多、御者善。我们的同学往往没有经过任何论证，上车就走。单元测试、接口自动化测试、UI自动化测试，老板让干就干，不问所以，不知所由。
生活中的CheckList
我们生活在现代工业文明之中
有一个事实，我们生活在现代工业文明中，日用的生活条件和生活设施都是有质量保证的。
我们不太会去质疑一个存在已久的，而且运转良好的现实。我们网购3C产品，只要看看详情页上的规格说明，就可以无脑下单，而不必担心货不对板。我们花几千块买一辆七手夏利，定期做做保养维护，就敢开着上高速，而不会担心车子会出P0故障。我们在晚上开车跑高速，连个路灯都没有，完全不会担心前车突然抛锚被我们怼上，也不会担心前面路况异常发生事故。
之所以说这些，是说我们在做软件的质量保证时，可以多向生活学习，看看身边传统行业的人都是怎么做质量的。
在传统行业，不管是地铁的消毒，还是巡逻安全、冰箱清洁、卫生间清洁，都是由CheckList作保障措施的。不只每个项目都是一个CheckList，这些项目汇总起来又是一个更大的CheckList。只要留意就会发现，好多地方的CheckList都依然是用的纸质表格，检查完一项就打勾一项。
科学认识论
波普尔的实证主义科学
质量保证如果是可能的，那一定有一个必要条件是：质量是可以观察的。
如果说真实世界不可知，这又是一个引战话题。那起码可以说，真实世界是难以认识的，真实质量是难以观测的。
大般涅槃经卷第三十二：
王言：象为何类？
其触牙者即言象形如芦菔根，其触耳者言象如箕，其触头者言象如石，其触鼻者言象如杵，其触脚者言象如木臼，其触脊者言象如床，其触腹者言象如瓮，其触尾者言象如绳。
有段时间我们的系统线上问题出的比较多，从外界视角来看那段时间我们的系统质量水平比较差。当然我们不敢说那段时间质量比较好，但是真的可以给出一个结论说其他时间比那段时间质量要好吗？恐怕还是要再推敲的。
讨论如何认识真实世界的认识论，辩论了几千年。这里我们肯定不会展开讨论这个话题。
子曰：科学认识论势大，吾从众也。科学哲学也有许多流派，波普尔的实证科学是其中重要的一支，但很难说最高明的一支，因为有争论容易引战。
打个比方，一个男生追求一个女生，确定的结果只有两个。或者女生接受，有情人终成眷属。或者拒绝，可能朋友都没得做。但是，也可能存在第三种情况，即不想接受，也不愿意拒绝，那就互称兄妹好了。我有个朋友说，哪有什么真正的兄妹关系，只有爱与不爱的妥协。
波普尔的科学哲学就是这种爱与不爱的妥协，所以基本上是应用最广泛的一个流派。
胡适同学说的大胆假设、小心求证，基本上是波普尔实证主义科学的特征。后面我们使用科学方法这个词来指代这个方法论。
实证科学就是提出一个可以证伪的假设命题，然后准备一个用于证伪的CheckList。如果检查结果不能证伪，就可以说这个假设是成立的。
如果我们提出一个命题，天鹅是白色的。
给出下面一个CheckList：
- 考察北京的天鹅颜色有没有不是白色的
- 考察南京的天鹅颜色有没有不是白色的
- 考察俄罗斯的天鹅颜色有没有不是白色的
只要有一个检查项发现了天鹅不是白色的，就可以证“明天鹅是白色的”这个命题是错误的。
一个命题，需要可以证明是错的，但是现有CheckList中的证据还没有证明是错的，那么我们就可以得出这个命题正确的结论。当然CheckList中的证据也是可以不断变化和补充的，但是只要没有证伪，就要假定命题是正确的。
总之一句话，科学的原则就是证伪的原则。
再看一个伪科学的CheckList：
- 考察北京的天鹅颜色是不是白色的
- 考察南京的天鹅颜色是不是白色的
- 考察俄罗斯的天鹅颜色是不是白色的
其实就是观察到CheckList中的天鹅都是白色的，也并不能得出天鹅是白色的这样一个结论。
我们在日常工作中，大量充斥着这样证实的伪科学方法论，出现问题的时候总是尝试证明自己的正确性。比如发现一个BUG、或排查线上问题的时候，我们经常会说我检查了几处几处都是好的。
伪科学的特点是CheckList中的证据都是用于证实命题的。
CheckList的设计和CheckList中证据的选择都不是很容易的事情，要依据科学的理论，要选择可以观测、可以证伪的证据。
众所周知，区块链技术维护的数据具有不可伪造的公开透明特征，但是依然存在51%攻击的可能性。三人成虎的故事也是类似的问题，CheckList必须小心的处理。
科学的CheckList是科学的依据，CheckList需要进行认真的科学论证。
浪费大量的时间讨论这种务虚的问题有什么用呢？非常有用。
我们的测试工程师写测试用例很辛苦，也很辛苦的进行各种测试工作，但是似乎总是苦劳多功劳少。每次对线上故障的5W分析，结论往往都是开发没有细心、测试没有测到等等。故障的改进措施，往往也是加强CodeReview，增加单元测试用例，引入自动化接口测试、性能测试、UI测试等等。马虽良，用虽多，御者虽善，然此非楚之路也。
开发工程师往往是根据产品文档的需求开发功能的实现，测试工程师往往根据开发的实现写测试用例。问题是核对产品需求有没有实现应该是开发工程师的职责，测试工程师的职责顶多是做一遍复核，因为我们不能假定需求的实现都成为问题。如果假定需求可能实现不了，就像假定地铁站没有消毒但是直接划了已消毒的标记，冰箱、卫生间没有清洁但是CheckList上打了勾，保安没有巡逻但是签了到。如果出现类似的问题，就是很严重的团队治理问题了。
如果测试用例，包括单元测试用例，是开发导向的，就是开发了什么功能就写什么用例，是很难保证质量的，因为你把白天鹅湖里的天鹅全部检查一遍，都是白色的，也不能得出结论天鹅是白色的。CheckList中的测试用例需要精心的设计，推断开发的实现哪里可能会有问题，就在哪里设置观察点。产品需求基本实现复核的测试用例，在CheckList是必须要有的，这个不消说了。
基本结论就是，CheckList中的测试用例需要遵循证伪的科学原则，而不应该走证实的伪科学之路。
质量是符合要求
质量保证就是保证满足要求的清单（LIST）
《质量免费》这本书中给质量下了一个定义，质量是符合要求。这个定义在工业化、标准化的语境中，可以严谨无歧义的使用质量概念，可以与ISO9000族的质量体系国际标准，在概念上保持一致。
设想一个柏拉图理念式的圆，在一个平面内，围绕一个点并以一定长度为距离旋转一周所形成的封闭曲线。质量的逻辑要求就是这种像理念的圆一样的封闭曲线，是一个针插不进、水泼不进的独立王国。老板对质量的要求，一般要的就是这种密不透风。
实际上，开发是人干的，质量检测也是由人干的。质量保证即便不像小朋友围起来的圆圈那么脆弱，充其量也不过是点球的人墙一样滴水不漏。要完成老板的柏拉图式的质量要求，除非请上帝来打工。
2011年的时候，从台湾爆出的塑化剂事件迅速扩及好多国家和地区，引发了不少抗议。
质量检测机构及相关的政府专业部门给出的质量检测说明，有如下的特点：
- 质检报告只对送检样品负责，不对业者产品的质量负责。
- 只检测N种塑化剂，不覆盖塑化剂的全部种类。
- 使用特定的测定方法检测
- 塑化剂小于某阈值即为达标
这样的质量检测报告，很不能满足人们的诉求：
- 检测结果合格，不能说明业者产品合格，那要检测有什么用？
- 只检测N种塑化剂，也就是说检测结果合格，也不能保证不含任何塑化剂？
- 使用特别的方法检测，也就是说有这种方法检测不出来的塑化剂了？
- 为什么是小于某个阈值的量，而不是塑化剂含量为零？
有很多地方的抗议者提出了对食品质量的逻辑要求，除非证实不含塑化剂，否则禁止销售。
足球的守门员在球飞过来的会伸手去拦，所以虽有空隙，依然可以有效拦截。但是，CheckList中的检查点，尤其是自动化的测试用例，却没有伸手拦BUG的自我意识。CheckList检查点的密集程度和科学程度，决定了拦截BUG的有效能力，但无法做点逻辑上柏拉图式的密不透风。
质量的逻辑要求，即是科学要求的出发点，也是归宿，是科学要求追求的目标。
生活需要仪式感
夸张的机械动作有助力强化制度的执行
网络上流传着一个印度炮兵的视频，恒河歌舞式操炮。动作夸张、机械，基本上在网上是被嘲笑的对象。
前些年，我们航母刚下水的时候，网上掀起了各行各业争相拍摄航母Style的照片和视频，其实也是因为动作的夸张和机械。
在坐地铁的时候，我们也会经常见地铁的司机、安全员等等，用很夸张、很机械的手势对着一些地方指来指去。
标准化作业往往都体现在以比较夸张、机械的动作标注制度、流程执行中CheckList中的检查点。
我们也应该在日常工作的流程中制定一些动作夸张、机械的标准化作业。比如，Diff代码后标注一下某某在某年某月某日CodeReview了哪部分代码，哪怕是小团队的提测也发一个固定格式的提测邮件，在发布中完成了某个流程的环节都在沟通群里明确的发言声明，等等。
这些夸张的机械动作，都会有助力强化制度的执行。
质量保证的处方
研发中保证质量的CheckList
研发中保证质量的手段，常见的包括不限于：
- 单元测试
- 验收清单
- 冒烟测试
- 接口自动化测试
- 常规测试
- 功能测试
- 性能测试
我们的测试工程师肯定还可以罗列出其他的质量保证手段。
这些都是良药，是业界行之经年的有效实践，像跑步锻炼、多喝热水对身体健康有益一样不言而喻。但是，我们去医院看病，有没有见过大夫开的方子上写多跑步、多喝热水的？
医生治病有理、法、方、药，我们保证质量也是一样的。
首先需要提出问题，诊断得了什么病，然后论证分析解决问题的原理和理论论据。确认了解决问题的原理以后，要研发解决问题的具体方法。根据解决问题的方法，拟定解决问题的具体措施。在具体措施的实施过程中，才会涉及到使用什么良药、什么手段、什么工具。
如果只见药，不见方，没有搞明白解决问题的理论和方法就去治病，那肯定是不行的。
具体措施的处方笺，一般需包含如下内容：
- 用什么药、工具、手段等，要指代明确，详细到规格
- 使用多大的量，多大的频率
- 需要使用多么长的时间
其实，药和处方只是看得到的内容，还有以理、法为依据的预后判断也是非常重要的。我们必须明白，一组措施实施一段时间后，应该有什么结果。如果出现了预期的结果，下一步怎么办。如果没有出现预期结果，下一步又该怎么办。
上面说大夫不会把多跑步、多喝热水写进处方，其实也是有的，只不过不常见就是了。
我有时会带自己的朋友去见一位我认识的大夫。这个大夫往往不开药，而是推荐做微汗的慢跑运动。跑的时候不要听音乐，不要想事情。每次慢跑要不低于一小时，一周需要至少4次。如果能坚持至少一个月，可以回来开药了。
这就相当于系统的质量不好，希望让大夫诊断，给出一些解决问题的具体措施。而大夫的建议是，每写代码都要写单元测试，发布的时候单元测试的行覆盖率不要低于50%，分支覆盖率不要低于30%，坚持至少一个月，就可以讨论质量的改进措施了。
网友评论