BY林子

本文首发于「BY林子」，转载请参考版权声明。 “小淘，吃石榴吧。” “吃石榴太麻烦了，不想吃。” “这是软籽石榴，籽儿可以吃的，很好吃的哈。”说完，我大口嚼着石榴直接咽下。 “不用吐籽吗？那我试一下。”小淘拿起几颗石榴粒放嘴里嚼了一下，还是把籽儿吐出来了。“不行，这籽儿我没法咽下。” 的确，在没有软籽石榴的时候，我也这样吃石榴，也觉得石榴吃起来太麻烦，而不愿意吃。而小淘由于对硬籽石榴中的籽儿难以忘怀，吃软籽石榴也还是会关注籽儿的存在…… 这一情景让我恍然大悟，这不就跟咱们很多传统测试人员对软件测试的理解很类似嘛！ 我们先看吃石榴的场景 没有软籽石榴之前，石榴籽不能吃，那个时候觉得石榴籽儿太多吃得太麻烦，根本体会不到石榴的美味，也顾不上它的营养了。 有软籽石榴之后，石榴籽就可以吃了。但如果在吃石榴的过程中还是总关注石榴籽，你会发现尽管它们是可以吃的，也会觉得很别扭，咽不下去，这样根本没法好好吃石榴，没法吸收石榴的营养。 如果把关注点放在石榴的美味和营养上，大口大口嚼着吃，你就感觉不到籽儿的存在，这样既能享受石榴的美味，也能吸收石榴的营养。 再看软件测试 在传统测试里，QA（测...

本文首发于「BY林子」，转载请参考版权声明。 在《软件测试中的『树莓酱定律』》一文中借用杰拉尔德·温伯格的『树莓酱定律』解释软件测试中的一些典型场景。其实，温伯格还有一个对应的『草莓酱定律』： “只要有果肉块，就不会抹得太薄。” 把一点树莓酱抹到几片面包上，你会发现它越抹越薄。可要是你换成草莓酱再来试试，你会发现不管怎么抹，果肉块还在那里！草莓酱里面的果肉块是草莓。在你传达的“伟大信息”中，果肉块就是你自己！只要你的沟通渠道还实实在在地用到你的身体——说话、写作、拥抱，你的信息就不会被无限冲淡。 本文聊聊上一篇文章提到的软件测试中的现象，如果用『草莓酱定律』解释会是怎样的。 01 测试全流程介入：离不开全面的测试策略测试全流程介入不会导致测试工作的增加，用树莓酱定律解释是因为测试工作分摊到全流程的各个环节了。但是这里有一个重要的前提，需要将测试工作真正地分摊，确保每个环节做的测试工作都是有效的，并且对整个团队和整个流程都是可见的，也就是没有“果肉块”，这样才能有机组合起来实现软件整体的质量保障。 如果存在“果肉块”，测试工作量是有可能增加的。“果肉块”是什么呢？比如下面的情...

本文首发于「BY林子」，转载请参考版权声明。 温伯格经典著作《咨询的奥秘》中提到『树莓酱定律』： （将一定量的树莓酱抹在面包片上）铺得越广，摊得越薄。 意思是不管多伟大的信息，传播的越广，信息量就会越淡，即信息在传播的过程中不会增加，信息的总量是一定的。 这是一个看似非常简单的定律。本文不聊信息传播的问题，而是想借用该定律来聊聊软件质量与测试中可以用树莓酱定律解释的常见场景。 01 测试全流程介入：测试本来就忙，这就更忙不过来了？提倡全生命周期的测试活动的开展，其中就要求测试人员在全生命周期各个环节有更多的介入，这对于传统独立测试阶段忙得不可开交的测试人员来说，是难以接受和理解的一件事情，觉得那样会更忙不过来。 其实不然。 根据树莓酱定律，在测试工作量一定的情况下，全生命周期开展测试，是将测试工作分散到各个阶段，每个阶段的工作量会有所减轻。而且我们知道越早开展的测试工作，能够做到更快速地反馈，其有效性越高，价值越大。 因此，测试全流程介入，不会增加测试的工作量，只是将测试工作的开展时间进行重新安排。 另外值得提醒的是，全生命周期的测试不仅是测试人员全流程介入，也需要团队不同...

本文首发于「BY林子」，转载请参考版权声明。 测试部门的存在是传统企业普遍存在的一种组织架构形式，在数字化转型的浪潮下，有不少企业在往业技融合方向转变，但测试部门完全融合到业技融合团队还是任重而道远。在这种新形势下，测试部门该如何跟业务、开发更有效的协作，是需要系统性思考的问题。 本文围绕这一问题展开，尝试对测试部门的职责进行定义，内容不仅适用于传统企业中独立的测试部门或者测试团队，也适用于敏捷团队里的QA（测试角色）。 01 组织架构为了更好地聊职责定位，有必要先捋一下测试部门的组织架构。测试相关的组织架构常见的有以下几种情况： 测试是一个独立的部门，跟开发中心或者开发部是平级的关系：这种组织架构下，测试跟开发是非常独立的，两者之间通常会有比较厚重的部门墙，沟通和协作会比较吃力。 测试和开发同属于某个开发中心，但是测试自己是一个独立的团队，对应的还有多个开发团队：这种组织架构跟前一种是非常类似的，测试和开发还是比较独立，有着团队墙，同样沟通和协作的难度较大。 根据不同的产品线，测试和开发融合在一起成为开发团队：这种开发和测试间的沟通和协作会相对顺畅，比较利于质量实践的开展。...

本文首发于「BY林子」，转载请参考版权声明。 敏捷测试象限有了近20年的历史，但还是有很多在做敏捷项目的朋友也没听说过，或者听过但完全不知道是怎么回事。另外，知道敏捷测试象限的业内同仁对它的评价也是褒贬不一。 最近听到几个稍感意外的说法，于是，想跟跟大家一起聊聊这个有名却又颇受争议的敏捷测试象限。 01 敏捷测试象限的演进史深入了解一件事物，我们有必要了解它的历史演变过程。下文尽量按照时间先后顺序来分享敏捷测试象限几个主流版本的演进，如有不准确的，烦请指出，先行感谢。 1. 原型：敏捷测试矩阵（2003年）Brian Marick于2003年最早提出“敏捷测试矩阵”的概念，分四个象限，左右分别为支持编程和评价产品，上下分别为面向业务和面向技术。如下图所示： 这是一个专门针对敏捷测试的矩阵，Brian指出左侧的测试主要是为了支持编程所做的准备工作和确保一些问题的澄清，而右侧的测试是关于验证和发现bug相关，左右两侧的“测试”含义不同。 这个矩阵就是我们通常提到的敏捷测试象限的原型。 2. Lisa和Janet的敏捷测试象限第一版（2008年）Lisa Crispin和Janet...

本文首发于个人网站「BY林子」，转载请参考版权声明。 《敏捷软件测试：测试人员与敏捷团队的实践指南》一书的作者Janet Gregory提出了一个新的概念“Holistic Testing”，暂且译为“全面测试”，指出要从更全面的视角来进行测试。 她和Lisa Crispin的敏捷测试课程也因此改名为“Holistic Testing”了。 01 Holistic Testing模型Janet利用类似于DevOps循环的形式表示软件开发生命周期，分为发现、计划、理解、构建、部署、发布、观察、学习几个阶段，并指出在整个生命周期中的每个阶段都有相应的测试活动。Holistic Testing模型如下图所示： （图片来源于：https://janetgregory.ca/testing-from-a-holistic-point-of-view/） Janet对她这个模型有两点关键解释： 采用无限循环表示，是认为测试应该是无限循环的，不是线性的，不应该有起点和终点，也不再谈测试左移和测试右移的概念。循环的左侧主要是指可以提前进行的测试活动，确保在“做正确的事情（Do the ri...

本文首发于「BY林子」，转载请参考版权声明。 针对2022年4月27日的「质量三人行之不止测试」直播，有不少朋友提了各种问题，这里将一些典型问题类型进行简要的解答，还有剩下的一些问题，后续尽量通过文章或者播客的方式帮大家解答。 01 质量内建与团队质量赋能相关 如何改变团队不同角色对质量的认识以及如何给团队不同角色进行质量赋能？ 提升团队全员质量意识是一个比较虚的话题，如何细化到实操级别来提升团队质量意识？ 需求测试在质量保障中的重要性？如何做好需求测试？怎么要求开发提测质量比较好比较有效？ 测试的合理成本、流程和角色 开发团队对系统设计意识比较薄弱，导致完成质量比较低，增加了测试工作压力，甚至影响到交付上线时间，有什么方法 敏捷测试在金融业的运用，特别是在缺乏QA人员的金融行业如何运用 质量流程优化 这一部分的问题主要是针对测试流程策略、团队负责质量、团队质量意识相关，很难通过简单的答案来回复这些问题，理念和策略方面之前都有相应的文章介绍过，但是到具体的团队和组织还是需要根据具体情况进行分析和定制化。 推荐先阅读我之前写过的很多文章，相信掌握了思路和方法，你的问题就会迎刃而...

本文首发于个人网站「BY林子」，转载请参考版权声明。 Note: You can find the English version after the Chinese one. (中文版文末有对应演讲视频) 【中文版 Chinese version】00 引言1. 三个层次聊测试体系 测试人员缺乏体系化思维？ 新建产品团队或者新启项目，如何搭建质量保障体系？ 大家都接触过不计其数的测试、质量方面的文章或者培训课程，内容不乏测试实践、技术相关，但是却很难构建自己的测试体系。基于很多朋友类似的困惑，结合本人多年的团队实践和咨询经验，从基础篇、进阶篇和高级篇三个不同的层次来跟大家探讨测试体系化思维的构建。 《构建测试的体系化思维（基础篇）》 《构建测试的体系化思维（进阶篇）》 《构建测试的体系化思维（高级篇）》 2. 基础篇和进阶篇内容回顾2022年1月发布了《构建测试的体系化思维（基础篇）》（后文简称《基础篇》），从测试的五个基本职责出发，围绕这五个基本职责介绍了相应的实践活动和方法集。 理解和澄清业务需求 制定策略并设计测试 实现和执行测试 缺陷管理与分析 质量反馈与风...

本文首发于「BY林子」，转载请参考版权声明。 愚人节聊天记录 啊哈，今天过节吗？ 原来今天是4月1日了，也就是愚人节！不说我还真忘了。 想想还挺恐怖的，当然不是说今天这个节日。而是2022年已经过去了四分之一，我却还没反应过来……还是不要继续这个话题，言归正传，来聊聊今天的节日吧。 愚人节特意上网搜索了一下关于愚人节的知识： 愚人节（西方节日） 愚人节（April Fool’s Day或All Fools’ Day），也称万愚节、幽默节，时间为4月1日，并未被任何国家认定为法定节日。 愚人节较普遍的说法是起源于法国。1564年，法国首先采用新改革的纪年法——格里历（即通用的阳历），以1月1日为一年的开端，改变了过去以4月1日作为新年开端的历法。支持改革的人在4月1日那天嘲笑不支持改革的人。 该节在十八世纪流传到英国，后来又被英国早期移民带到了美国，并随着英国的殖民运动和移民活动被带到了美洲大陆，于是成为了欧美流行的节日。 （以上内容来源于网络） 愚人节 关于愚人节的起源，网上有很多种说法，从这些说法看来，愚人节是一个真正愚弄人的节日，在这一天通过各种玩笑来制作“四月恶作...

本文首发于「BY林子」，转载请参考版权声明。 文章是“自己的”好！ 看到这句话，是不是觉得我太骄傲？！ 哈，不要误会，不是说只有我自己写的文章才是好的。 这说法来自著名散文大师王鼎钧先生的《作文六要》，其意思是说要写出自己的所见、所闻和所感，而不要模仿他人的写法，只有这样写出来的文章才是带有真情实感，才是好文章。 对此，本人深感认同，这也同样适用于技术写作。王老先生表达的意思有三点： “写作的最初动机，是诉说自己的心事。” 对于技术写作而言，那么动机就是分享自己掌握的新技术、工具、实践经验。 “文章要写真心话、老实话，而不是说别人话，不是抄书本的话。” 对于技术写作而言就是要将掌握的技术、工具和实践经验用自己的话表达出来，而不能抄袭别人的文章，或者东拼西凑地写一些自己根本不了解的内容。 “文章中的故事可以是假的，但情感至诚无伪。” 对于技术写作而言，可以理解为项目实情可以虚构，但所描述的技术、实践一定是切实可行的，并且是来自自己的真实体验和感受。 大家可能都见到了我前一阵写的《构建测试的体系化思维（基础篇）》和《构建测试的体系化思维（进阶篇）》两篇文章，对我来说，它们都...