《不止测试》——我的自出版小书
《不止测试》电子书下载 这是一本帮助测试人员的小书，但也是写给团队所有角色看的。 “测试把关质量”，这是传统对质量保障工作的普遍认知。 基于业务需求设计测试策略、制定测试计划、编写测试用例、执行测试，对于测试有问题的地方提交缺陷并对缺陷进行管理，这几乎就是测试人员的全部工作内容。 随着业务形态多样化、数据复杂度增加、技术架构演进、基础设施发展，软件所处的生态越来越复杂、不确定性增多，质量面临的风险也更加不可预测；同时，软件市场的竞争越来越激烈，对软件质量的要求有了更高的呼声。 在这样的新形势下，交付高质量的软件面临着更大的挑战，光靠传统的那些质量保障工作无法实现。 这本小书的内容全部来自我个人十几年敏捷项目实战经验的总结，旨在帮助测试人员和敏捷团队在新形势的挑战之下，能够拓宽思路，对软件质量的保障增加信心。 “质量不是检测出来的。”著名质量管理专家戴明先生的这句名言告诉我们，光靠开发完成后的测试是没法保障质量的，质量需要团队成员一起负责，需要从软件开发的整个生命周期给予关注： 需要左移，关注业务的真正价值，要以业务价值驱动开发和测试； 需要右移，关注和利用生产环境的数据和信息...
测试敏捷化 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在质量流程没有明确定义的团队中工作时，需要思考以下两个问题： “你将如何为团队增加价值？” ...
团队对质量负责，“我”可以不负责？
本文首发于「BY林子」，转载请参考版权声明。 “敏捷测试强调团队为质量负责，那质量变成是团队的事情，可能有测试人员认为个人不那么负责问题不大，毕竟天塌下来有团队在。”一位转型中的测试经理表达了这样的担忧。 这跟传统职责分明的做法有关，“我”管“我的”，“你”管“你的”，各自做好自己的本分就可以了。现在，既然说要团队来负责，那么“你”就可以多帮“我”负责一点，“我”少负责一点也没问题。听起来似乎还挺合情合理的。 显然，这种想法是有问题的，把个人跟团队割裂开来了。 良好的团队应该有一种“我们”的态度，而不是“我”的态度：“我如何帮助团队解决问题？我可以为别人做些什么？”，而不是“我不知道这是什么问题，这不是我的问题。” 但是，事实上有前面测试经理提到的这种想法的人应该不是个例。 因此，转型中的团队如何能够真正做到团队为质量负责，如何增强每个人对质量的责任感，是真正需要解决的问题。 01 团队整体对质量负责 敏捷测试宣言里提到“团队整体对质量负责”主要是针对传统的质量都由测试人员来把关的做法，强调团队所有角色对质量的责任。 之前从软件质量属性、易被忽视的质量、角色的质量职责分工、...
育儿之旁观者视角
本文首发于「BY林子」，转载请参考版权声明。 01 电梯里“阿姨包包上挂着一个小挂饰，好看吧？”身后传来温柔的男士声音。 “一个小小小…挂饰。”紧跟着是一个稚嫩的小男孩的声音。 回头看了一眼，是一家三口，小朋友大概4-5岁的样子，对我包上的小挂件感兴趣。 “对，小挂饰就是一个小饰品，装饰用的。”小孩爸爸温柔地跟小男孩解释。 “我也要买买买…买…一个小挂饰。”小孩可爱地说道。 “你说话别那么着急!”小孩的妈妈忍不住了。 “给你买个小挂饰吧” 小孩爸爸继续温柔地说道。 “太太太…太好啦！”小男孩非常高兴。 “叫你别那么着急，小点声说话！”小孩妈妈声调提高了八度。 电梯人越来越多。 “电梯人多，咱小点声说话。”小男孩爸爸还是非常温柔。 “￥##（&）*）”小男孩再次叽里呱啦说了一堆，当然还是有些重复词语出现。 “你慢点说！”小孩妈妈已经出离愤怒了。 “咱慢慢说，不着急。” 小孩爸爸仍然没有着急生气。 电梯到一楼了，身后继续传来小孩妈妈的声音，要他说话别那么着急，小点声……可是，这位妈妈自己却控制不住着急、控制不住要大声地教育孩子。 全程听下来，从一个旁观者来看，这个小朋友其实...
足球赛
本文首发于「BY林子」，转载请参考版权声明。 012021年欧洲杯已经开赛十几天，我今天才看第一场球，是E组小组赛最后一场西班牙对阵斯洛伐克。 没想到上半场竟是如此的戏剧性： 先是西班牙莫拉塔”轻松地“将点球罚丢，如果西班牙本场被踢平或者输球，莫拉塔该是多么的内疚……后来斯洛伐克门将杜布拉夫卡竟以一个扣篮式的乌龙帮西班牙1-0领先，同求门将的沮丧指数…… 足球场上有太多的不确定性，进球的方式无奇不有，总是会有各种意想不到的惊喜（忧）发生。这，就是足球的魅力，也是我喜欢足球的第一个原因。 人生亦是如此，有太多的不确定性，总是计划赶不上变化。过去的不管是遗憾还是辉煌，都已经过去，无需过分在意；未来的还没到来，不管是坦途还是险阻，都无法预知，无需过分焦虑，相信车到山前必有路。我们唯一能够做的就是珍惜当下，尽力而为做好每件事情是关键。 02足球是需要团队高度协作的运动，11名队员通过传球、打配合，才有可能帮助球队赢球。由于是团队运动，协作很重要，但人总会有失误的时候，一旦有失误发生的时候，不是对该人去追责，而是需要从团队协作的角度去看该如何改进。 比如足球场上的点球罚丢和门将的乌龙，...
数字化转型背景下的测试转型
本文首发于个人网站「BY林子」，转载请参考版权声明。 数字化转型强调业务价值驱动、以技术为核心，传统的业务部门和研发部门都会在转型中得到重视，而传统的测试部门因为得不到相应的关注和指导，通常会处于尴尬的局面。 在这样的大背景下，如何帮助测试团队顺利完成转型备受关注，本文将跟大家一起探讨这个问题。 01 数字化转型给测试带来的挑战转型让测试人员打散到研发团队，通常使得测试人员茫然无措，非常地不适应。与众多转型企业中的测试团队沟通后发现，测试转型面临的挑战主要有以下几个方面： 归属感 隶属于传统测试部门的测试团队习惯了以往的部门级管理方式，往往在加入各个不同的产品研发团队之后，找不到归属感。 职责定位 融入研发团队的测试人员面临新的工作方式，不清楚自己的职责和在团队中的定位，不清楚哪些事情是需要做的，发挥不了应有的价值，从而导致话语权低，在团队没有影响力。 团队协作 由于不清楚自己的职责定位，也不知道该怎么跟不同的角色进行协作，这种新的团队组织方式，让测试人员担忧。 能力建设 新的组织方式和开发模式下，测试人员的能力建设也是面临很大挑战的问题，组织和个人都不清楚测试人员的能力要...
从技术趋势看质量赋能
本文首发于「BY林子」，转载请参考版权声明。 《敏捷团队的质量保障赋能》一文从敏捷价值观出发，结合Google、Amazon、Facebook等前沿大公司的质量赋能策略与实践，以及笔者多年在敏捷团队经历的赋能实践，跟大家一起探讨了敏捷团队质量保障赋能的必要性和落地策略。 本文通过分析近十来年《ThoughtWorks技术雷达》（以下简称技术雷达）上的各种技术、工具，从质量赋能角度来看相关技术发展所呈现出来的趋势，再次思考质量赋能该怎么做。 技术趋势 技术趋势主要有以下三个方面： CD技术、DevOps工具使得软件开发呈现全流程标准化趋势 大量测试和流程自动化工具助力标准化的实施 系统韧性成为质量的一部分，测试不再是质量保障的唯一方式 软件开发的全流程标准化随着持续集成、持续交付、DevOps技术的发展，技术雷达上一系列的标准化技术和工具被采纳，主要集中在流水线以及流水线上的标准化工具（代码格式、提交规范等），包括专用于移动应用的流水线技术和工具，另外有平台级的方案——集成多套工具集的Azure DevOps和适用于机器学习的一整套端到端的持续交付策略CD4ML（机器学习的持...
