BY林子

本文首发于「BY林子」，转载请参考版权声明。 “敏捷测试强调团队为质量负责，那质量变成是团队的事情，可能有测试人员认为个人不那么负责问题不大，毕竟天塌下来有团队在。”一位转型中的测试经理表达了这样的担忧。 这跟传统职责分明的做法有关，“我”管“我的”，“你”管“你的”，各自做好自己的本分就可以了。现在，既然说要团队来负责，那么“你”就可以多帮“我”负责一点，“我”少负责一点也没问题。听起来似乎还挺合情合理的。 显然，这种想法是有问题的，把个人跟团队割裂开来了。 良好的团队应该有一种“我们”的态度，而不是“我”的态度：“我如何帮助团队解决问题？我可以为别人做些什么？”，而不是“我不知道这是什么问题，这不是我的问题。” 但是，事实上有前面测试经理提到的这种想法的人应该不是个例。 因此，转型中的团队如何能够真正做到团队为质量负责，如何增强每个人对质量的责任感，是真正需要解决的问题。 01 团队整体对质量负责 敏捷测试宣言里提到“团队整体对质量负责”主要是针对传统的质量都由测试人员来把关的做法，强调团队所有角色对质量的责任。 之前从软件质量属性、易被忽视的质量、角色的质量职责分工、...

本文首发于「BY林子」，转载请参考版权声明。 012021年欧洲杯已经开赛十几天，我今天才看第一场球，是E组小组赛最后一场西班牙对阵斯洛伐克。 没想到上半场竟是如此的戏剧性： 先是西班牙莫拉塔”轻松地“将点球罚丢，如果西班牙本场被踢平或者输球，莫拉塔该是多么的内疚……后来斯洛伐克门将杜布拉夫卡竟以一个扣篮式的乌龙帮西班牙1-0领先，同求门将的沮丧指数…… 足球场上有太多的不确定性，进球的方式无奇不有，总是会有各种意想不到的惊喜（忧）发生。这，就是足球的魅力，也是我喜欢足球的第一个原因。 人生亦是如此，有太多的不确定性，总是计划赶不上变化。过去的不管是遗憾还是辉煌，都已经过去，无需过分在意；未来的还没到来，不管是坦途还是险阻，都无法预知，无需过分焦虑，相信车到山前必有路。我们唯一能够做的就是珍惜当下，尽力而为做好每件事情是关键。 02足球是需要团队高度协作的运动，11名队员通过传球、打配合，才有可能帮助球队赢球。由于是团队运动，协作很重要，但人总会有失误的时候，一旦有失误发生的时候，不是对该人去追责，而是需要从团队协作的角度去看该如何改进。 比如足球场上的点球罚丢和门将的乌龙，...

本文首发于「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视角关注的重点，本文不做展开，对此感...