快乐是一种选择
明天（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和用户的双重身份接触到了数据匿名化，决定跟大家分享一下这段经历，从QA的视角来聊聊数据匿名化。 数据匿名化及其实现概述在聊项目经历之前，还是有必要大概介绍一下数据匿名化。 数据匿名化是指从数据集中将个人身份信息（Personal Identification Information, PII）清除/脱敏，让人无法识别数据所描述/关联的主体，以实现保护隐私的目的。 很多场景下需要使用和处理生产环境的真实数据，比如：以测试、培训、数据对外发布、数据分析等为目的的场景。但生产环境的真实数据包含个人身份信息，由于隐私保护需要，不能直接使用。这个时候数据匿名化很有必要。 实现数据匿名化的操作（参考Wikipedia）常见的有五种类型：泛化（Generalization），抑制（Suppression），解剖（Anatomization），置换（Permutation）和扰动（Perturbation）。具体的实现技术细节不是QA视角关注的重点，本文不做展开，对此感...
2020-21《全球软件质量报告》解读
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为什么转换角色
“妈妈，听李老师说还有插画课，我能不画素描了去上插画课吗？”早上出门前小朋友跟我说。 “为什么？”我问。 “我不想画素描了，素描太难了！” “插画跟素描一样，要画好都不容易。你之前学的都是素描，如果素描还没学好想转学插画，那么画一阵之后会不会又觉得插画也难，然后又转学别的呢？结果可能到头来你什么都没有学好。”小朋友好像听懂了，没有再说什么。 这让我想起来最近身边讨论激烈的QA转角色的问题，想到下面三种情形： A：QA在团队做的工作难度低，重复度高，没有发展，感觉做BA（PM、Dev等）挺好的，我也转个角色吧。 B：QA目前在团队所做的事情对技术能力要求还是挺高的，尤其是自动化测试编码能力，我努力去学去练，但还是很难精通。感觉这个特别不适合我，以我的兴趣和能力特点，可能做BA更合适我的发展，因此，我准备尝试一下转BA。 C：我QA干了很多年了，目前QA技术领域也取得了一定的成就，想尝试更多不同的角色，从不同的视角来关注质量，应该能够更有利于工作的开展，也更有利于自身能力的提升和职业的发展。 决定总结成文，跟大家分享。 本文单纯想聊聊QA（测试人员）转角色的问题。关于软件测试...
敏捷团队的质量保障赋能
本文首发于「BY林子」，转载请参考版权声明。 “没有专职的测试人员？ 代码提交就直接发布到生产环境？ 而且，一天还可以发布多次？” 对于很多团队来说，这是完全不可能的事情！他们都是怎么做到的？ 01 两个案例相信很多人都对前面这些问题很好奇，在解开谜团之前，我们先来看两个案例。 案例1 随着互联网业务业务的发展，某行业核心系统为了面对互联网的挑战，需要对系统进行改造。可是，真想改起来却寸步难行…… 该系统已经有十多年的历史，业务规则复杂，业务逻辑代码全部都在数据库脚本层；缺乏有效的业务文档，需求分析文档是以系统页面流转和操作步骤为主的形式，开发和测试人员对业务没有清晰的概念，只是知道系统有哪些操作，某个操作对应的真实业务并不清楚。 面对几百万行代码的改造，没有业务上下文的支撑，其难度可想而知。 案例2 某团队开发半年的一个网站在上线前一个多月发现根本没法正常运行，被迫延期半年后才上线…… 原来，该网站是基于一个第三方平台开发，由于业务的特殊性需要支持2TB的数据量。但是，该第三方平台并没有验证过可以支持这么大的数据量，在上线前一个多月UAT环境准备就绪，系统在UAT运行的...
我的2020
近期北京疫情又开始有病例出现，为了元旦顺利出行，预约好时间、请好了假、就等着孩子放学一起去做核酸检测。但是，上午刚刚通报的最新确诊病例有两例网约车司机，看来这次疫情可能比较麻烦…我们开始纠结还要不要按原计划出行，一直纠结…直到把孩子接回家，最终决定改变计划，不做核酸检测元旦也不出行了。 在做出放弃出行决定那一刻，突然变得很平静，再也不用担心各种可能的麻烦情况。虽然白请假了，利用这个时间好好的给家人做顿美味晚餐、好好的跟家人相处也是很好的！ 回顾过去的2020年，这其实是生活的常态。正是这特殊的2020年，让我学会了以平常心面对一切不确定性。 01我的2020，从焦虑开始。 一月，因为回乡从武汉转车，虽然只是凌晨在候车室待了几十分钟，但足足让我在家焦虑了半个月，甚至头疼感冒都不敢跟家人说…每天起床第一件事情就是跟孩子学校汇报健康情况，以及查看最新疫情发展状况… 随后是考虑上班上学什么时候回京的问题，没有口罩没有消毒液怎么办？回京的高铁票改机票，又由于乡镇封城，机票进行多次改签…内心的焦虑随着疫情加剧有增无减…这是对未来不确定性的担忧。 直到二月顺利回到京城自己家中完成半个月居家隔离...
测试右移：日志收集与监控
本文首发于「BY林子」，转载请参考版权声明。 我在敏捷测试系列直播课程里讲到了《测试右移》，也就是收集生产环境的数据信息，分析和利用这些信息优化软件开发和测试环节，以进一步提高质量。生产环境的数据信息中最为重要的就是日志信息，因此，收集日志信息并利用日志信息进行监控也是测试右移最重要的内容。 测试右移直播课 本文将从日志收集的必要性、日志收集方案、日志监控机制和高效日志管理实践几个方面跟大家一起探讨测试右移之日志收集与监控。 日志收集的必要性随着科技的发展，业务形态、业务类型、业务复杂度都发生了很大的变化，相应地，业务数据量和复杂度也增加了不少。为了支撑复杂的业务和大的数据量，技术架构和基础设施也在演进变化。所有这些因素，导致软件系统生态变得日益复杂和不确定。而在处于不确定状态的软件系统，传统的软件测试方法显然行不通，于是利用生产环境信息，尤其是其中的日志信息，成为了新时代软件质量保障的必要条件。 日志信息的价值那么，日志信息这么重要，它的价值到底体现在哪里呢？我认为至少有以下四个方面的价值： 1. 定位功能问题 当我们的软件系统出现bug的时候，最常用的诊断方式就是尝试重...
QA评审底层测试的价值
“林子，咱们上次讨论的高效Desk check清单，用起来还挺好的，最近我们组每次Desk check变得顺利多了，Dev也是越来越熟练。”玥玥跟我说。 “真好！我们组感觉也是这样！” “不过，我听小慧说他们组有人对QA review UT提出了一些concern（质疑），觉得QA review的价值不大，基本都是Dev给讲一遍，QA也提不出来什么反馈…”玥玥补充说道。 “哦！那你们组感觉review的怎么样？”我问玥玥。 “我们组感觉还挺好的，可能是因为我已经review很长时间了，对Dev写的测试也比较了解了，每次过一遍不会太费劲，也能发现一些问题。” “嗯，QA review测试肯定是有价值的，但是能否体现出价值，取决于是否做的好，这不仅对QA有要求，对Dev也是有要求的。” 关于底层测试及其评审看到前面的对话，可能有朋友会问什么是底层测试，以及底层测试又是如何评审的。因此，我先来介绍这两个内容。 底层测试测试分层理论根据测试所覆盖范围的大小，将测试分成不同的层：端到端功能测试、API集成测试、单元测试等，常见的测试分层实例有测试金字塔。 位于金字塔下面的API测试...
高效用户故事验收（Desk Check）
“先来更新一下各个team近一周发生的事情吧。”又到了每周的QA catch up时间，今天是轮到玥玥主持会议。 “我先说吧，我们这一周刚完成一件大事！”我忍不住抢先说。 “什么大事？”大家都很好奇。 “就是上次说过的新增一种工单类型的feature，昨天刚刚完成了story的desk check（用户故事验收）。” “听说那个影响到了整个企业系统？” “差不多吧。desk check就做了两个小时。”我说。 “是看到你们做了好久！上次我们有个story做了快一个小时，我都快要崩溃了！你们竟然更久……”小慧之前就给我们说过她那次痛苦的Desk Check经历。 “我们这次时间虽久，但是感觉做的挺好的，已经很高效了。时间长是因为实在是太复杂了。这次Dev很给力，准备工作做的很好，整个desk check过程也很有条理，非常顺畅。”我解释道。 “这种情况可能比较少见。正好今天没有特别的分享话题，咱们先更新完各个组的情况，林子你再给我们详细分享一下昨天的Desk check，咱们还可以可以讨论一下如何能让Desk check做的更好。”玥玥说。 “这个主意不错！”大家都表示同意。于...
