敏捷测试的指导性原则
本文首发于个人网站「BY林子」，转载请参考版权声明。 “这么多问题，你们是怎么测的？” 这是我们测试人员听到的最多的质问，也是传统的测试人员对质量把关的常见认识。 但是，事实上，就像著名质量管理专家戴明指出的那样：软件的质量不是测出来的，测试人员没法控制软件质量的好坏。尤其是在敏捷开发模式下，特别强调的核心是质量内建，而要做好质量内建，需要团队全员的参与，需要团队整体对质量负责，这是敏捷测试的指导性原则，我们在敏捷测试宣言里也有强调。 01. 团队整体对质量负责有多难团队整体对质量负责，这是个说起来容易做起来难的事情，很少有团队能够做的特别好。 那么，为什么这么难呢？ 在我看来，多半情况是因为不是团队所有成员都清楚质量到底是什么，没有明确的质量目标，所以也就没法很好的对质量负责，要实现团队整体对质量负责，首先得搞清楚下面三个问题： 敏捷里的质量是什么？ 通常容易忽视的质量有哪些？ 团队不同角色怎么为质量负责？ 关于这部分内容，在《说好的团队为质量负责呢》一文里有详细的分享，感兴趣的同学请移步阅读。 下面将继续分享相关的两个话题：敏捷团队是否需要专职QA、能够整体对质量...
业务价值驱动的测试
本文首发于「BY林子」，转载请参考版权声明。 在《敏捷测试如何优化业务价值》一文中分享过测试人员对于如何优化业务价值的几个思考维度： 从终端用户角度进行测试 以业务为重点的测试 映射业务影响 关联业务指标 接下来，将跟大家分享业务价值驱动型的测试及其相关落地实践。 01. 业务价值驱动的测试跟传统测试的对比业务价值驱动的测试和传统测试在以下几个维度的关注点都有不同：需求的关注、计划与执行、应对缺陷、测试人员角度、目标、生产力、指标的关注、有效性，详细对比如下表。 从表中可以看到： 业务价值驱动型测试要关注业务的需求，而不仅仅是功能需求； 业务价值驱动型测试以追求快速高质量的交付价值为目标，单纯的测试覆盖率和缺陷数量不再是考核的因素。 业务价值驱动型测试不是不关注缺陷，要以预防缺陷为主，正确跟踪缺陷并进行深入分析是帮助缺陷预防的必要的手段。 业务价值驱动型测试不再简单的根据数量来考核生产力，可以从多个维度评估测试的成熟度，以驱动出持续改进的方案。这个可以参考我的文章《聚焦测试，驱动卓越》 02. 如何阐明业务价值业务价值可能比较抽象，似乎不是那么好理解，况且要跟具体的测...
敏捷测试的核心
本文首发于「BY林子」，转载请参考版权声明。 Q：质量内建跟敏捷测试的关系是什么？能分开吗？ A：我认为质量内建是敏捷测试的核心。 01. 传统测试敏捷测试是相对于传统测试而言的，在聊敏捷测试之前，我们先看传统测试是什么样的。传统测试通常有如下的特点： 独立的测试部门：测试人员跟开发人员不属于同一个部门，各自独立。 测试工作主要由测试人员承担：功能与非功能测试，手动与自动化测试，冒烟测试、回归测试、发布测试等，基本都是测试人员的事情。 详尽的测试用例文档：测试用例文档一般都要求详细的执行步骤。 集中的回归测试：有独立的集中回归测试阶段，对所有功能进行全面的测试覆盖。 发现更多的bug：测试人员的目的是发现更多的bug，甚至有些部门会把bug数量作为绩效考核的目标。 02. 敏捷测试敏捷测试是伴随着敏捷开发过程的所有质量相关活动，有着如下的特点： 不能独立存在，不是一种测试类型或方法 敏捷测试不仅是测试人员的工作，敏捷测试是团队的活动 抛开敏捷开发谈敏捷测试没有意义 敏捷测试的目标也不再是发现更多的bug，而是尽快的交付高质量的软件。 那么软件的高质量怎么获得呢？著名...
软件测试人员的职业发展之路
本文首发于「BY林子」，转载请参考版权声明。 在《关于软件质量，大家都在关注什么》一文中，我们了解到软件测试领域新的关键趋势主要体现在以下几个方面： AI的发展与软件测试 敏捷与DevOps 自动化测试 环境和数据 成本与效能 
Velocity不背这个锅 (Velocity Is Not Responsible For It)
本文首发于个人网站「BY林子」，转载请参考版权声明。 【中文版Chinese Version】 NOTE： The English version can be found after this Chinese version. 01. 那些对速度（Velocity）的误解
敏捷测试如何优化业务价值
本文首发于「BY林子」，转载请参考版权声明。 提到敏捷测试就会提到优化业务价值，优化业务价值是敏捷测试的原则之一，敏捷测试的系列活动都要围绕交付价值服务，那么具体的到底要怎么做才能真正优化业务价值呢？ 我们需要从四个不同维度来思考和组织相应的测试活动以实现优化业务价值，如下图示： 四个维度 01. 从终端用户角度进行测试从终端用户角度进行测试是基本的测试思维，是测试人员必备的技能要求。 在思考、设计测试用例并执行测试的时候，不能简单的套用用例设计方法去机械的进行，而是要考虑用户可能的行为习惯、使用场景等。 下面来看两个例子： 场景一：我们在使用移动设备的时候，一般会设置自动锁屏。当测试某个移动App时，测试人员觉得移动设备的自动锁屏功能会导致测试很不方便，于是关掉了自动锁屏功能，结果后来在一台测试人员自己使用的设置自动锁屏的手机中发现了一个缺陷，就是在每一次锁屏并开启后，充值选项会新加载一遍，可以导致多个重复的充值选项存在。 场景二：测试移动设备断网的情况，通常会采用调成飞行模式或者关闭数据网络的方式，这两种方式对于iOS7以下的版本通常都需要离开所测的App去设置，这样的...
一页纸测试策略
【摘要】测试策略文档通常是篇幅较长、文字为主的形式，编写成本较高，并且写完了很少有人去看，形存实亡。本文介绍可视化的方式，将测试策略用图来表达，并且在一页纸上搞定，这样的策略图非常清晰，关键信息一目了然，并且提供更大的讨论空间，防止僵化，真正能够发挥策略的作用。 本文首发于「BY林子」，转载请参考版权声明。 “测试策略是什么样的？” “测试策略嘛，还不是包括#&~+-=～*-+$这些…” “你们项目的策略有什么特别的吗？” “我们项目嘛，测试策略的内容有点多，从哪说起呢？” 前面那个场景有没有似曾相识？你是否清楚目前你们正在使用的测试策略是什么样的？ 01. 常见测试策略测试策略的内容与形式我们都知道，测试策略包括以下两方面的内容： 测什么（What）？测什么是指质量需求是什么、需要关注质量的哪些方面，比如应用的功能范围、性能、安全、易用性等非功能需求。 怎么测（How）？怎么测就是采用什么办法来帮助系统实现质量需求，而不仅仅是手动和自动化的测试方法，也包括一切为质量保障服务的流程、环境、基础设施和人员等。 为了描述清楚要测的内容以及如何来测，测试策...
2019：我的节奏，由我掌控
本文首发于「BY林子」，转载请参考版权声明。 01
新一代支持BDD的测试框架Gauge+Taiko
本文首发于「BY林子」，转载请参考版权声明。 【摘要】Gauge不强调协作，可以作为自动化测试工具独立存在，同时又支持高效协作、支持实现BDD，是一款灵活性更好的框架。它的秘密武器Taiko是一款优秀的Web UI自动化工具，两者的结合堪称完美，让需求规范、自动化测试和活文档的有机结合真正成为可能。 01 BDD是什么BDD，Behavior Driven Development，行为驱动开发。 如果你不是很了解BDD，可以参考我四年前的一篇文章说起BDD，你会想到什么，其中介绍过BDD的理论和应用。 我们可以这样来概括BDD： BDD采用统一的领域特定语言（DSL）来描述业务场景和用户行为，让团队各个不同角色对业务需求有一致认识，从而做到更有效的沟通和更高效的协作； BDD的目的不是自动化测试，但是BDD可以有效指导自动化测试，基于BDD的自动化测试相当于维护了一份需求活文档，对项目需求的维护和管理非常有价值。 02 BDD应用框架之Cucumber1. BDD的应用BDD是为解决下面三个方面的问题而生： 协作：多个角色在一个团队，如何从一致理解需求开始高效协作？ 语言...
BQConf演讲：软件测试人员该何去何从？
本文首发于「BY林子」，转载请参考版权声明。 下文根据11月23日第39届BQConf北京的演讲《软件测试人员该何去何从》整理，为了便于阅读，稍作修改并增加了不同级别的标题。 三个故事01. 面试中的他两年前的一个下午，天气有些雾霾，在三楼光线不是特别明亮的会议室里，我和另外一位工作年限跟我差不多的同事面试一位有着10年经验的候选人。 对于跟一位工作十年的候选人见面，我和同事都挺期待，提前沟通好，做好了充分的面试准备。走进会议室，看到一位身材高大、略显疲惫的男士，没有我想象的那种阅历丰富、干练自信的样子。 简单寒暄之后，我们正式进入面试流程。他介绍了自己的工作经历，详细描述了自己这些年所从事的工作的点滴，听下来并没有太多的亮点。出于对候选人负责，我们想尽力去挖掘他的一些加分项，但是，很难，最终无果… 他来自某大公司，多年一直处于一个部门，从事几乎没什么变化的手动测试工作，工作强度不大，对技能要求也不是很高，他在那里做的得心应手。不料，公司业务发展调整，需要部分裁员，他不得不另谋出路。 02. 屏幕那头的她一年前，我写了一篇文章《微服务测试的思考与实践》。有位朋友看了我的文章，给...
