BY林子

本文首发于个人网站「BY林子」，转载请参考版权声明。 迷茫 焦虑 2023年对于绝大多数人来说都是不容易的一年。无论是大环境还是小环境，无论是工作还是生活，无论是同事、朋友还是家人，到处都充斥着迷茫和焦虑的情绪。 负面情绪就像黑暗无法驱赶，唯一能做的，就是带进光来。喜悦是消融负面情绪最好的光。 ——《重遇未知的自己》 张德芬 今年与姐妹共同取得的PMP证书虽然并不是一件了不起的事情，但考虑到当时的心境和曾一度想要放弃的情况，它实际上是我们在迷茫和焦虑中看到的一束光，为我们注入了前行的信心和动力。 相信 坚持 当你陷入困境或力不能支时，专注在力所能及的小事上，这能推进事情的进展。 ——《宝贵的人生建议》【美】凯文·凯丽 焦虑于那些我们无法改变的环境或事态，纯粹是徒劳。相比之下，专注于我们能够改变的事物，踏实地做好力所能及的事情更为实际。工作、生活、教育等方面的未来发展难以预测，但有一点是我们可以掌握的，那就是相信自己能够适应变化，并坚持做好应对变化的准备。 在心理学中存在一个现象被称为“自我实现的预言”，指的是人们会在不自觉的情况下按照已知的预期行事，最终实现这一预期。只...

白皮书下载 关于软件质量，不同的人根据自身的领域知识和经验，对其有着不同的认知：有人简单地将软件质量等同于软件测试，有人说到软件质量就会想到是否有缺陷，也有人对软件质量的认知停留在是否好用的层面。 实际上，软件质量内涵丰富，既包括可感知的、跟用户使用相关的外部质量，也包括影响外部质量的软件技术架构和代码相关的内部质量，还有整个软件开发生命周期中各个环节相关的过程质量。 在 Thoughtworks，我们认为软件开发是复杂的社会活动，随着业务形态的增多、技术架构的演进，软件质量的复杂性不断增加，影响软件质量的因素也越来越多。软件质量不能仅靠传统意义上的测试活动来保障，测试人员要延伸测试边界，以更全面、更系统的视角来构建软件质量体系，助力组织提高软件产品的质量。 如果我们开始设想一套完善的质量体系，这个体系应该包括许多方法论和实践，并需要自上而下的管理框架和自下而上的主动意识。 自上而下的框架是基于顶层设计，整体包括哪些部分，它们的作用是什么，以及互相之间的关系等。 自下而上的主动意识则是每个员工基于不同的角色，主动关注与质量相关的工作，并积极履行应尽的质量职责。 因此，质量体系可...

本文首发于个人网站「BY林子」，转载请参考版权声明。 Note: You can find the English version after the Chinese one. 两个场景场景一：有限经费与质量改进 “要写自动化的单元测试、E2E测试，就会需要更多的钱，可是我们经费有限暂时做不了。” “CI上配置SonarQube扫描，对于扫描出来的问题我们也没有经费修复，这个举措也是没法实现。” …… 某IT团队在推进质量改进系列举措的时候总能听到这样的声音，就是由于经费有限很多的举措都实施不了。这似乎成为了一个困扰许多团队的难题，因为供应商往往要求额外费用来支持自动化测试和安全漏洞修复等。 这种困境的核心问题在于，有限的经费似乎成为阻碍团队提高质量的主要障碍。其实，需要全面理解质量改进的投入：质量改进是一项短期支出，更是一项长期的投资。 短期内去修复已有的代码Bug、安全漏洞，或者在原本没有自动化测试的情况下去增补自动化测试，确实需要额外的投入，因为这不属于新功能开发部分的工作内容。但是，代码漏洞的修复可以提高代码整体质量，而自动化测试能对代码改动提供快速反馈，能更有效地保...

本文首发于个人网站「BY林子」，转载请参考版权声明。 01 两个真实的故事故事一X公司IT质量管理部门在做质量的规范化管理，定义实践标准规范、模板、指南等，以指导各个团队因为实践不一致带来的问题，帮助各个团队更规范地开发和交付高质量的软件。A团队是X公司IT部门实践最成熟的团队，是标杆。 按说，A团队应该是最容易配合IT部门的质量改进的，因为他们是相对做得好的。可事实恰好相反，A团队对各种模板和指南都特别敏感，认为这些东西一旦制定出来就会要求严格照做，没做好肯定会追责，需要找人“背锅”，很排斥IT部门的改进举措。 相反，在成长初期的B团队却是真心想得到改进，心态很开放，角色间的协作和配合更加和谐，希望有一些指导性的东西帮助他们做的更规范，对各种举措也是很愿意配合。 故事二Y公司的IT部门也想做质量改进，但他们的情况比较特殊，业务方相对于IT来说比较强势，业务需求不清晰、进度要求紧等一系列问题，导致IT开发交付团队压力较大，但又不知道如何解决。我所接触到的Y公司几个IT团队的成员基本都感觉很累、很压抑，都在抱怨其他角色有做的不好的地方。 但其中有一个QA却完全不一样，她心态很好，...

本文首发于个人网站「BY林子」，转载请参考版权声明。 QA的绩效如何考核？ 测试工作的价值体现在哪里？ 这两个是大家比较关注，也是比较难的问题。确实，业务分析人员会产出需求文档，开发人员会产出软件，而QA的工作则很难定义明确的产出，很难被量化。 我们需要换个角度来理解测试工作的价值。测试工作本质是为了交付更好的质量，预防缺陷在生产环境暴露。因此，测试工作犹如防火，虽然很难量化定义，但是却举足轻重。 注意: 测试工作不一定是QA来完成，基于“团队对质量负责”的理念，团队任何人员都需要承担相应的测试工作，下面提到的测试工作都需要团队共同完成。 测试工作犹如防火测试工作在软件开发过程中的价值跟日常做好防火工作的价值是类似的，目标是在软件部署到生产环境之前，尽早发现并修复潜在的缺陷，确保软件在用户手中的安全和稳定运行。主要体现在以下几个方面： 早期发现隐患：防火检查会在火灾发生前发现火源或潜在的火灾隐患，并在事态扩大之前采取措施。同样，在软件开发过程中通过执行各种测试来发现潜在的缺陷和问题，并在软件交付到用户之前尽早予以解决。 预防性措施：防火需要采取预防性措施，例如安装灭火器...

本文首发于个人网站「BY林子」，转载请参考版权声明。 “我们项目两周后要发布新版本，现在QA忙不过来了，需要找个人帮忙回归。” “这我恐怕搞不定！我还得花时间熟悉上下文。” “你这么资深，我们都相信你肯定是没问题的。” 天啊！我可不是ChatGPT，怎么可能短时间内熟悉业务并能做好回归呢？别吓我！“团队其他角色帮忙回归更好吧！团队外的人就算再专业也不如团队内的人合适呢……” 千万不要惊讶，事实上，有着类似诉求的团队不在少数。面对这样的局面，该如何处理呢？ 01 一个真实的故事我前一阵接触了这样的一个团队：需要在5天内完成回归测试，但是QA还在忙着测新开发的Story，根本忙不过来。我尝试以外援身份从了解业务上下文开始去做回归测试，我知道这个方式行不通，不过是想了解团队更多情况，希望能够给他们一些切实可行的建议。 第一天我是周三早上加入团队。早上10点，半个小时，PM给我简单介绍诉求上下文，QA告诉我要测哪些回归case。让我先自己熟悉系统，熟悉case，然后找BA给我介绍业务，因为QA还有其他会，还有正在开发的Story要跟。 我只好自己先熟悉。可是，BA一直也有各种会或团...

本文首发于个人网站「BY林子」，转载请参考版权声明。 各个团队的质量管理不够规范，想要一套质量指标对其进行规范化的考核。 指标，总是受到管理者们的青睐，甚至有人绞尽脑汁研究出各种指标的计算方式，似乎利用指标来进行管理是最简单的方式。 我曾经提醒过警惕度量指标陷阱，当然，也不能对指标望而生畏，用得好也是有很大积极作用的。本文以我熟悉的软件质量领域为例，分析如何在质量管理中让其产生积极的效果。 1. 质量体系和实践举措在图中的最左侧是“质量体系”，它是质量能力的基石。质量体系通过规范化的实践举措，对团队的工作进行指导和管理，旨在提高团队的质量能力和整体工作效率。 2. 质量能力：超越指标的关键质量能力是团队在持续改进的实践举措基础上形成的技能和能力。这些质量能力被描绘在图中的中间部分，它是连接质量体系和最终价值交付的关键所在。与单纯追求指标不同，质量能力是团队具备的技术、流程、团队协作等方面的核心能力，通过质量内建相关实践呈现。有了这些能力，团队才能更加自信地应对挑战，不断提升产品和服务的质量，实现高效高质量的交付。 3. 质量指标的辅助和监控质量指标扮演着重要角色，它是评估...

本文首发于个人网站「BY林子」，转载请参考版权声明。 近日，某群有人发了领导制定的绩效考核指标： 对测试人员的工作成效进行考核，指标是发现的 Bug 的情况，甚至有参考指标细到每个小时要求发现多少 Bug，同时还考虑不同严重程度的 Bug 占的权重也不一样，并附有详细计算公式。当然，细节就不说了，大意是发现 Bug 越多绩效越好，且越严重得分越高。 这可真是一套经过严密设计的考核指标，相信这位指标制定者一定下了一番功夫！ 指标固恋（metric fixation） 杰瑞·穆勒（Jerry Z. Muller）所著的《指标陷阱（The Tyranny of Metrics）》对痴迷于使用指标来度量绩效的现象提出“指标固恋”的概念： 相信基于标准化数据的可比较绩效的数值型指标，替代依靠个人经验和天赋获得的判断力，不但可行，还是可取的； 相信公开这些指标（透明），可确保机构履行其目的（问责制）； 相信在这些组织内，激励人们的最佳方式是根据其测量绩效进行奖惩，奖励可以是货币性的（绩效薪酬），也可以是声誉上的（排名）。 很多的管理者都喜欢使用看似非常客观的标准化的数据来考察人...

本文首发于个人网站「BY林子」，转载请参考版权声明。 之前在《敏捷测试的核心》、《构建测试的体系化思维（进阶篇）》和《一页纸测试策略》等文章中提到过测试左移，但是没有专门针对这个主题做过系统的介绍，但又总是被社区朋友问到。本文旨在介绍测试左移及其相关实践，希望能够解答朋友们的疑惑。 01 什么是测试左移？传统软件开发生命周期一般分为如下五个阶段：需求分析、软件设计、程序编码、软件测试和上线发布。其中软件测试是软件编码完成之后的一个独立阶段，通常由测试人员来负责完成测试相关工作。如下图所示，从左到右依次为上述五个阶段： 测试左移就是针对传统独立测试阶段而言，将测试活动左移到图中测试阶段左边的多个环节，对每个环节所做工作进行测试验证，以确保其正确性，如下图所示： 需求分析环节的测试活动是为了保障需求的合理性，确保团队在做正确的事情； 设计环节的测试活动是为了保障设计的合理性，确保易于实现所期待的功能； 编码环节的测试活动是为了保障开发人员所写代码和所开发功能的正确性； 在测试环节还需要有相应的测试活动来对功能和非功能需求进行最后的验证和确认。 图中所示各个活动是从左到右按先...

本文首发于个人网站「BY林子」，转载请参考版权声明。 ChatGPT是一个经过预训练的AI语言模型，可以通过聊天的方式回答问题，或者与人闲聊。它能处理的是文本类的信息，输出也只能是文字。它从我们输入的信息中获取上下文，结合它被训练的大模型，进行分析总结，给出一个可能会让我们耳目一新的答案。 正因为简单易用，并且似乎具有超常的智慧，它使得我们“普通老百姓”有机会近距离接触到这个超能AI，并且爱上了它；另一方面，正是由于它“智力过人”，我们在喜欢它的同时也产生了担忧，那就是我们的工作会不会被它取代，导致失业…… 我的ChatGPT初体验我使用ChatGPT也有一段时间，由于我目前所做工作主要偏向于产生内容，根据一些特定场景设计或制定解决方案之类的文本处理的事情，我会把ChatGPT当做一个比搜索引擎更加方便更加强大的工具来使用。比如，我可以给它输入特定场景上下文，让它帮我提供解决方案的思路。 由于大模型的支持，它的产出是经过提炼和总结的，是相对系统的，更接近于我所需要的结果，显然它是比搜索引擎更加强大、更加智能的工具，能够节省我查找资料并从资料中提炼我所需信息的大量时间，而且它可...