构建测试的体系化思维（进阶篇）/ Building Systematic Thinking for Testing (Intermediate)
本文首发于个人网站「BY林子」，转载请参考版权声明。 Note: You can find the English version after the Chinese one. (文末有对应演讲视频) 【中文版 Chinese version】00 引言1. 三个层次聊测试体系 测试人员缺乏体系化思维？ 新建产品团队或者新启项目，如何搭建质量保障体系？ 大家都接触过不计其数的测试、质量方面的文章或者培训课程，内容不乏测试实践、技术相关，但是却很难构建自己的测试体系。基于很多朋友类似的困惑，结合本人多年的团队实践和咨询经验，从基础篇、进阶篇和高级篇三个不同的层次来跟大家探讨测试体系化思维的构建。 《构建测试的体系化思维（基础篇）》 《构建测试的体系化思维（进阶篇）》 《构建测试的体系化思维（高级篇）》 2. 基础篇内容回顾2022年1月份发布了《构建测试的体系化思维（基础篇）》（后文简称《基础篇》），从测试的五个基本职责出发，围绕这五个基本职责介绍了相应的实践活动和方法集。 理解和澄清业务需求 制定策略并设计测试 实现和执行测试 缺陷管理与分析 质量反馈与风险识别 3...
“赢得孩子”，而不是“赢了孩子”
本文首发于「BY林子」，转载请参考版权声明。 《正面管教》第二章提到一个非常关键的点：我们教育孩子的目的不是“赢了”孩子，而是要“赢得”孩子。“赢了”孩子，孩子成了失败者，会导致孩子反叛或者盲从；“赢得”孩子则会获得孩子心甘情愿的合作。 下面的一些行为都是“赢了”孩子： 你咋这么笨，这么简单的题也不会做，看我的！ 我早告诉你这样会出问题，你不听。 01 自尊：一个容易造成错觉的概念如果孩子只能通过一些外在的、他人的评价来获得认可，慢慢地就会变成“讨好者”或“总是寻求别人的认可”，学会观察别人的反应来判断自己行为的对错，而不是学会自我评价与内省。这样培养出来的是“他尊”，而非“自尊”！ 因此，我们需要教会孩子自我评价，而不是依赖别人的赞扬或观点。应该教会孩子把犯错误当成学习的大好时机，允许孩子经历失败，学会遇到问题时自己解决。 02 赢得合作的四个步骤书中介绍了四个“赢得孩子合作的步骤”，非常好，摘抄如下： 表达出对孩子感受的理解。一定要向孩子核实你的理解是对的。 表达出对孩子的同情，而不是宽恕。同情并不表示你认同或者宽恕孩子的行为，而只是意味着你理解孩子的感受。这时，你如...
正面管教方法概述
本文首发于「BY林子」，转载请参考版权声明。 “正面管教是一种既不用严厉也不用骄纵的方法，它以相互尊重与合作为基础，把和善与坚定融为一体，以此为基石，在孩子自我控制的基础上，培养孩子的各项技能。” 这是一种听起来非常好的教育方法，不过，似乎也是很难做到的一种方法，起码我个人这么觉得。 最近在读《正面管教》，这是一本非常经典的亲子教育书籍。因为学习最大的收获来自输出，我决定把我从书中所学通过后续几篇文章分享给大家，以增强我的正面管教技能。 本文为第一篇，我们一起来粗略了解一下正面的方法。 01 教育孩子的方法需要与时俱进受社会的系列变化所影响，现在的孩子很少有特别听话、顺从一切的。这主要是因为： 父母不再是顺从的样板 当今社会强调平等，我们这些做父母的也不再是顺从一切，不再能作为榜样影响孩子。而孩子也只是在追随他们周围的榜样，也希望得到平等与尊重。 培养责任感和上进心的机会减少了 孩子不再需要为生计奔波努力，而是被爱包围，亲人们给予的爱很容易被认为是理所当然。而“孩子的责任感只有在和善而坚定、有尊严、受尊重的氛围中，有机会去学习具备良好品格所需要的有价值的社会和人生技...
Navid的质量框架
本文首发于个人网站「BY林子」。 Navid Nader-Rezvani根据她在敏捷团队的质量咨询经验，总结出一个敏捷质量框架，在书籍《An Executive’s Guide to Software Quality in an Agile Organization: A Continuous Improvement Journey（敏捷组织的软件质量持续改进之旅）》中有详细介绍。 这个框架从五个维度来描述敏捷质量需要关注的内容，现将这个框架简单分享给大家，如果想了解更多详情，请自行阅读原书。 Navid提出的质量框架也叫Navid的质量支柱（NQPs，Navid’s Quality Pillars）： 支柱1：团队建设和敏捷实践（Pillar 1: Team Development and Agile Practices） 支柱2：代码质量和架构（Pillar 2: Code Quality and Architecture） 支柱3：敏捷生产力和质量赋能利器（Pillar 3: Agile Productivity and Quality Enablers） 支柱4：非...
构建测试的体系化思维（基础篇）/ Building Systematic Thinking for Testing (Basic)
本文首发于个人网站「BY林子」，转载请参考版权声明。 Note: You can find the English version after the Chinese one. (文末有对应演技视频) 【中文版 Chinese version】00 引言1. 三个层次聊测试体系 测试人员缺乏体系化思维？ 新建产品团队或者新启项目，如何搭建质量保障体系？ 大家都接触过不计其数的测试、质量方面的文章或者培训课程，内容不乏测试实践、技术相关，但是却很难构建自己的测试体系。基于很多朋友类似的困惑，结合本人多年的团队实践和咨询经验，从基础、进阶和高级三个不同的层次来跟大家探讨测试体系化思维的构建。 《构建测试的体系化思维（基础篇）》 《构建测试的体系化思维（进阶篇）》 《构建测试的体系化思维（高级篇）》 2. 基础篇概述之前写过一篇文章《神圣的QA》，是面向想从事QA工作的毕业生同学的，文中有讲到五个测试基本职责： 理解和澄清业务需求 制定策略并设计测试 实现和执行测试 缺陷管理与分析 质量反馈与风险识别 本文基础篇的内容将从这五个职责出发，分享测试的体系化思维需要关注的各个...
《不止测试》——我的自出版小书
《不止测试》电子书下载 这是一本帮助测试人员的小书，但也是写给团队所有角色看的。 “测试把关质量”，这是传统对质量保障工作的普遍认知。 基于业务需求设计测试策略、制定测试计划、编写测试用例、执行测试，对于测试有问题的地方提交缺陷并对缺陷进行管理，这几乎就是测试人员的全部工作内容。 随着业务形态多样化、数据复杂度增加、技术架构演进、基础设施发展，软件所处的生态越来越复杂、不确定性增多，质量面临的风险也更加不可预测；同时，软件市场的竞争越来越激烈，对软件质量的要求有了更高的呼声。 在这样的新形势下，交付高质量的软件面临着更大的挑战，光靠传统的那些质量保障工作无法实现。 这本小书的内容全部来自我个人十几年敏捷项目实战经验的总结，旨在帮助测试人员和敏捷团队在新形势的挑战之下，能够拓宽思路，对软件质量的保障增加信心。 “质量不是检测出来的。”著名质量管理专家戴明先生的这句名言告诉我们，光靠开发完成后的测试是没法保障质量的，质量需要团队成员一起负责，需要从软件开发的整个生命周期给予关注： 需要左移，关注业务的真正价值，要以业务价值驱动开发和测试； 需要右移，关注和利用生产环境的数据和信息...
测试敏捷化 vs 敏捷测试
本文首发于【林子的空间】 大家可能关注到双态IT联盟前一阵发布了一个测试敏捷化成熟度评估模型，不断有小伙伴问到我关于这个成熟度评估的问题，我发现大家很自然地把这个跟敏捷测试成熟度画上了等号，不过这不是Thoughtworks开发的，我也不是很清楚。为此，我特地进行了一番调研，希望我这篇文章的解读能解答大伙大部分的疑问。 我们先尝试从字面意思来理解一下，对于以下两个术语大家都比较熟悉： 数据匿名化 => 匿名数据：通过匿名化技术对数据进行处理，使得数据变成匿名的，也就是得到匿名的数据 存储虚拟化 => 虚拟存储：通过虚拟化技术对存储进行处理，使得存储变成虚拟的，也就是得到虚拟的存储 这两个例子，相信大家都能理解没有问题。关于测试敏捷化，类似地，从字面意思可以这样理解： 测试敏捷化：通过敏捷化的方式（可能包括技术、流程、实践等）对测试进行处理，使得测试变成敏捷的，得到了“敏捷的测试” 那么，“敏捷的测试”是否等同于“敏捷测试”呢？从字面意思来看，似乎是等同的。但事实如何，需要对两者有深入的理解才可以下定论。 01 相关概念1. 敏态与稳态为...
敏捷QA需要写测试用例吗？
“可工作的软件高于面面俱到的文档，这是敏捷的价值观之一，测试也不需要那么重的文档，测试用例可以不写。”这是甲方观点。 “没有测试用例怎么知道要测啥？没有测试用例怎么证明你测了啥？编写测试用例是保护QA自己的手段之一，应该要写测试用例。”乙方可不这么认为。 这里说的测试用例，我理解主要是指手动测试的用例。 01 真正的敏捷团队不需要详细的测试用例总有人纠结或讨论测试用例该以什么形式写、要写到什么粒度，不同的团队、不同的公司对测试用例的要求也是不同，有的要求特别严格的格式、详细描述的步骤和期望结果等，有的则是可以简单的列出检查点即可。 那么，敏捷QA到底是否需要写测试用例呢？ 1. 真正的敏捷团队我是赞同甲方观点的，我认为真正敏捷的团队是不需要严格要求编写手动测试用例的。这是因为： 敏捷团队的QA需要参与测试左移的相关实践，包括从需求分析阶段开始介入，测试分析、设计和执行都会是同一个人，通过一系列的实践活动，QA在不断理解和澄清需求的过程中已经清楚了在测试时候需要关注的点，这些点不用以严格的测试用例的形式呈现出来。 真正的敏捷团队要求做好自动化测试工作，应该有足够的自动化测试...
测试经理如何适应敏捷转型
“转敏捷后，测试经理的话语权没有了，团队更加关注交付速度而不重视质量怎么办？” 在跟某转型中的团队进行交流时，一位测试经理表达了这样的担忧。 我理解这里的困惑在于两个方面： 传统模式下测试是一个独立的部门，测试经理可以在测试这个阶段严格把关质量，有很强的话语权；在敏捷模式下，测试需要融入开发团队，都由开发团队PM来统一管理，很有可能会更关注交付速度，这种情况下，测试经理的话语权似乎减弱了，该如何发挥价值、捍卫产品的质量？ 其实，测试经理对自己的工作职责比较迷茫，不是很清楚敏捷模式下他该如何开展工作，似乎传统模式他所做的事情不能再继续了？ 下面跟大家一起探讨该如何解决。 质量的重要性毋容置疑不管是传统还是敏捷开发模式下，质量都很重要。 传统项目管理三角把质量放在中心，体现了质量的重要性。但是，现实情况下，项目管理在保持铁三角不变的情况下，很容易从质量方面去妥协。 Jim Highsmith提出了敏捷项目管理三角，价值和质量是目标，各占一角，传统三角组合变成“约束”占据第三角。敏捷管理三角不仅进一步强调了质量的重要性，更是强调了质量的不可妥协性。这就表明如果因为某些因素影响...
AIMA：如何通过质量指标提高QA的绩效（译）
译者按： QA在团队的价值总是被质疑，本文利用简单的AIMA（分析、影响、度量、演示）四个步骤，介绍如何将QA的工作重心放在跟团队/项目的质量指标关联的工作上，通过质量指标来提高QA的绩效，体现QA的价值。 原文为葡萄牙语，模型里的AIMA分别来自于四个步骤的葡萄牙语首字母： 分析 Análise 影响 Impacto 度量 Metrificação 演示 Apresentação 英文原文：AIMA: How to increase the performance of QA Analysts through indicators，作者：Jonas Davila 随着越来越多的公司使用 KPI指标来衡量软件质量，质量分析师（QA）迎来了更多的机会。 QA工作有很多的可能性，比如：被安排在实践定义不明确的团队或组织，或者是QA角色职责不清晰的团队。 QA要开展的活动跟团队具体情况有关，但可以使用一种方法轻松地将改进点可视化，从而快速为公司和团队增加价值。 因此，当QA在质量流程没有明确定义的团队中工作时，需要思考以下两个问题： “你将如何为团队增加价值？” ...