BY林子

本文首发于「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（机器学习的持...

明天（2021年5月15日）技术雷达峰会将在深圳举办。今天，从北京飞深圳，本来是一件很平常的事情。 倒霉 or 幸运结果昨天晚上我这个几乎不腰疼的人莫名其妙的腰疼，而且越来越疼，今天早上起来还是很疼，但是没办法，只能这样去赶飞机。从机场入口到候机厅，一路都靠小车子帮我背行李。 幸运的是，碰到同一个航班的同事，并且座位还是前后排。于是，行李上下行李架就不是问题。 延误 or 惊喜前两天到深圳的同事就反应航班大面积延误，都是延误好几个小时的。我的航班是中午13点，还有同事建议我改签早一点的，可是我发现好多航班还取消了，万一我改了之后那班取消了怎么办？所以我还是保持乐观的态度，不改了，但同时做好了长时间延误的心理准备和物资准备（零食+充电宝+书）。 果不其然，航班最终延误了近5个小时才起飞…… 不过，好处是我选了个右侧靠窗的位置，这就意味着可以看夕阳啊！而且今日的夕阳特别美，真是大大的惊喜O(∩_∩)O 话不多说，直接跟我来一起体验吧~~~ 快乐是一种选择相信生活中的美好无处不在，虽然我们经常会经历各种不顺，换个角度看问题，就能完全不一样。 快乐是一种选择，选择了快乐，人生的...

本文首发于「BY林子」，转载请参考版权声明。 场景01 “Story上的AC（验收标准）可以直接作为Test Case（测试用例），就不用再详细写Story相关的Case了。” “AC不能写成Test Case那样的，AC肯定不能作为Case。” “为啥啊？AC写得详细点，不就可以作为Case了吗？” “AC跟Case是两码事，AC是从业务视角出发的验收标准，而Case是用来验证系统功能的。” 听到这里，是不是觉得有点意思？你赞同哪个观点呢？别急，咱们接着往下看。 场景02 “你们的测试用例全部都是系统的操作步骤哈，那怎么知道相关的业务需求实现了呢？”看到那一条条格式整齐的测试用例，清一色描述的是系统的操作步骤，不禁产生这样的疑惑。 “我们这些测试用例就是根据业务需求文档来写的，需求文档上也是这样描写的系统操作步骤。” 测试人员如是说。 好吧，我理解需求、开发和测试都已经习惯了这样的方式，那么，真的没有问题吗？我们来听听PM怎么说：“大家对业务上下文理解不清晰，都只知道系统如何操作、提供了哪些功能，包括测试人员，测完了系统功能正常，但是他们可能都不知道自己测试的功能关联到...

数据匿名化，是数据安全相关的实践。目前从网上能找到的内容主要是关于匿名化的实现技术。最近，笔者在项目中以QA和用户的双重身份接触到了数据匿名化，决定跟大家分享一下这段经历，从QA的视角来聊聊数据匿名化。 数据匿名化及其实现概述在聊项目经历之前，还是有必要大概介绍一下数据匿名化。 数据匿名化是指从数据集中将个人身份信息（Personal Identification Information, PII）清除/脱敏，让人无法识别数据所描述/关联的主体，以实现保护隐私的目的。 很多场景下需要使用和处理生产环境的真实数据，比如：以测试、培训、数据对外发布、数据分析等为目的的场景。但生产环境的真实数据包含个人身份信息，由于隐私保护需要，不能直接使用。这个时候数据匿名化很有必要。 实现数据匿名化的操作（参考Wikipedia）常见的有五种类型：泛化（Generalization），抑制（Suppression），解剖（Anatomization），置换（Permutation）和扰动（Perturbation）。具体的实现技术细节不是QA视角关注的重点，本文不做展开，对此感...

2020年11月凯捷（Capgemini）发布了第12期《World Quality Report 2020-21》（全球质量报告），本文跟大家做简单解读，来看看最新的软件质量趋势是什么。 不平常的2020年，数字化转型在加速，而质量保障和IT在其中起到很关键的作用，也表现出很大的弹性。日趋成熟的工程实践给质量保障带来了很大的便利，但核心的测试思维模式仍然至关重要，人们对质量保障的期望越来越高。 正如本期质量报告的摘要所述： Growing expectations from QA. Can we meet them? Yes. We can. （对质量保障的期望越来越高。我们能做到吗？是的，我们可以。） 质量保障和测试的目标软件质量保障的目标早已经不是发现bug那么简单了，随着科技和业务形态的变化，QA也被赋予了更重要的使命。从质量报告调查结果我们可以看到质量保障和测试的目标主要体现在以下几个方面： 业务保障：这是排在第一位的目标，业务是企业存活的关键，QA需要为业务增长和业务成果作出贡献。 质量把关者：在上线前发现尽可能多的缺陷是QA的最基本职责，新形势下这一点仍然很受关...

“妈妈，听李老师说还有插画课，我能不画素描了去上插画课吗？”早上出门前小朋友跟我说。 “为什么？”我问。 “我不想画素描了，素描太难了！” “插画跟素描一样，要画好都不容易。你之前学的都是素描，如果素描还没学好想转学插画，那么画一阵之后会不会又觉得插画也难，然后又转学别的呢？结果可能到头来你什么都没有学好。”小朋友好像听懂了，没有再说什么。 这让我想起来最近身边讨论激烈的QA转角色的问题，想到下面三种情形： A：QA在团队做的工作难度低，重复度高，没有发展，感觉做BA（PM、Dev等）挺好的，我也转个角色吧。 B：QA目前在团队所做的事情对技术能力要求还是挺高的，尤其是自动化测试编码能力，我努力去学去练，但还是很难精通。感觉这个特别不适合我，以我的兴趣和能力特点，可能做BA更合适我的发展，因此，我准备尝试一下转BA。 C：我QA干了很多年了，目前QA技术领域也取得了一定的成就，想尝试更多不同的角色，从不同的视角来关注质量，应该能够更有利于工作的开展，也更有利于自身能力的提升和职业的发展。 决定总结成文，跟大家分享。 本文单纯想聊聊QA（测试人员）转角色的问题。关于软件测试...