BY林子

本文首发于个人网站「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当做一个比搜索引擎更加方便更加强大的工具来使用。比如，我可以给它输入特定场景上下文，让它帮我提供解决方案的思路。 由于大模型的支持，它的产出是经过提炼和总结的，是相对系统的，更接近于我所需要的结果，显然它是比搜索引擎更加强大、更加智能的工具，能够节省我查找资料并从资料中提炼我所需信息的大量时间，而且它可...

本文首发于「BY林子」，转载请参考版权声明。 「质量三人行」播客在3月发布的一期《那些在需求评审和迭代计划会议中容易忽视的质量问题》，其中有个关于需求梳理会的问题： 问：周期为两周的迭代，团队的需求梳理会要花1-2天时间，这是合适的吗？ 答：不合适，这个梳理会太重了！ 有朋友听完播客给我们留言说他们现在就是这么做的，觉得2天是可以接受的。 因此，本文就这个话题跟大家聊聊。 01 什么是需求梳理会？需求梳理会也称为Product Backlog Grooming Meeting，通常指的是团队定期进行的一系列活动，以确保产品需求列表（Product Backlog）中的所有需求都足够明确、可操作、可测量，并为团队的开发工作提供足够的指导。 在Grooming过程中，团队成员将一起审查、讨论和精炼产品需求列表中的用户故事（User Story），以确保它们已经足够详细、具体，并与其他用户故事之间形成逻辑关系。 02 每次需求梳理会的理想时长是多少？我想先问下大家： 如果一个团队在一起讨论需求，你觉得多长时间是你能坐得住并能高效参与讨论的？ 就我个人而言，一个小时内我能高效...

本文首发于「BY林子」，转载请参考版权声明。 不管是专业测试人员还是软件行业其他角色，几乎很少有人能分清楚各种软件测试类型，比如最近看到有人说： “功能测试等同于手动测试” “功能测试也叫黑盒测试或者数据驱动测试” …… 的确，测试类型的概念没有标准化的定义，而且在不同的语境下还会有不同的含义，因此，大家都混淆各种概念也是很正常的。但是，尽量搞清楚这些类型，对于我们更好地理解和实践软件测试还是很有帮助的。 于是，通过我对ChatGPT进行提问，对它回答不清晰或者不准确的内容通过进一步提问澄清，最终我和ChatGPT pair 整理了这份软件测试类型清单。 01 按照测试验证的内容分类根据测试验证的内容是系统的功能需求，还是非功能需求，可以分为功能测试和非功能测试，而非功能测试还可以细分为不同的测试类型。 1.1 按验证内容分类的测试类型1. 功能测试： 功能测试主要验证软件系统的功能是否符合用户需求和规格说明书的要求。 2. 性能测试： 性能测试主要用于测试软件系统的性能，包括响应时间、吞吐量、负载能力等方面。通过这种测试类型，可以找出系统的性能瓶颈，以及在不同负载条件下的...

本文首发于「BY林子」，转载请参考版权声明。 随着软件开发变得越来越快，越来越复杂，传统的开发方法已经无法满足当前的需求。在过去，软件开发人员和测试人员通常是两个不同的团队，他们之间的沟通和协作非常困难。为了解决这些问题，开发和测试融合已经成为了软件开发的新趋势，越来越多的企业开始实施开发和测试的融合。 然而，现实情况下，开发和测试融合却并不理想，大家对此也是存在疑问：开发和测试融合，到底该怎么做？本文就跟大家一起探讨开发和测试融合相关的问题。 01 为什么要实现开发和测试融合？1.1 新形势下质量文化的要求开发和测试融合是跟新形势下的质量文化、软件测试的价值观密不可分的，主要体现在以下几个方面： 1. 全程的测试介入全生命周期各个环节的测试介入，并不是测试的独立工作，离不开跟各个角色的协作。 2. 团队为质量负责传统的测试和开发物理上隔离、时间上分裂，不利于实现团队整体为质量负责，只有两个角色打破隔阂，融合到一起，才有成功的可能。 3. 持续精准的自动化测试自动化测试不是把手工测试用代码实现那么简单，而是需要有相应的策略，需要考虑业务风险和技术风险，从而少不了开发和测试的协...

本文首发于「BY林子」，转载请参考版权声明。 最近在学习管理方面的知识，尝试根据我所经历过、听说过的项目，做一些总结。本文即从一个项目成员的角度，分享我对优秀PM的理解。 01 对齐项目目标 小A加入某项目团队，PM跟他说：“你的工作就等着B给你安排就好了”。并没有交代更多项目背景和目标相关信息。 小A刚加入也不敢问太多，就想着B应该会讲更多信息。结果B也讲不清楚项目背景和目标，只是说最近要做啥工作，但不知道这些工作背后的目的是什么，也不清楚工作的优先级是根据什么排的，只能按照B说的去做。这样，小A感觉非常的被动…… 小A想再次问问PM，但PM觉得他只需要知道该干什么就行，没有跟他说清楚。久而久之，小A觉得越来越没意思，渐渐失去了工作热情，变得非常消极…… （PS：这里只关注PM的处事方式，暂时忽视其他因素） PM带领团队成功交付项目，首先就得确保每位成员都能清晰了解项目目标，都能明确自己所做的工作与达成目标的关系，这样大家才会更有激情去完成工作。 这个看似很简单的道理，但真正做好也不容易。这里对齐目标，其实包含了三层含义： PM主动跟团队说明项目目标 PM要明确表述项目目...

本文首发于「BY林子」，转载请参考版权声明。 2022年，稀里糊涂地过去了。当大家都在忙着总结过去、展望未来的时候，我似乎还没反应过来。十天前的高烧，脑子虽然没烧傻，但是变懒了，只想躺着，只想慢下来。于是，这篇文章今天才跟朋友们见面。 回忆过去的一年，我并没有取得啥辉煌的成绩，也没有跟身边很多优秀的朋友那样进行了大量阅读和学习……不过，还是尝试提炼出三个关键字：坚持、突破、感恩。 坚持01 从2015年Thoughtworks公司内组织的第一届博客大赛开始，我就正式开始写博客，先是根据每届博客大赛的节奏一次都不落下，而且每次两篇以上文章。后来，参加公司的内容输出项目，写作的频率有所增加。我没有追求数量，一直以来更新频率并不高，只是按照自己的节奏持续输出，不知不觉坚持写了8年。 为了对得起自己创作的每一篇内容，2022年初对个人博客网站的界面进行了优化，以崭新的面貌呈现出来，同时也重新组织了内容结构，方便大家浏览所有文章。 02 2021年年初结束多年交付项目生涯，开启了咨询和培训相关工作，接触到了更多本地的企业客户和社区朋友，意识到测试与质量体系化思维对大家的重要性，总结并进...