测试在敏捷开发中的特别实践V2.0-敏捷测试

Posted 2021-04-25 大敏捷

引言：2009年3月，笔者阅读了ThoughtWorks覃其慧的《我和敏捷团队的五个约定》（现网址：https://www.infoq.cn/article/thoughtworks-practice-parti/#anch40464 ，搜索标题也可以获得 ），认为没有体现“ 敏捷团队的特点”，因而写下了《 独立测试团队在 敏捷开发中的几个特别实践》一文（见https://blog.csdn.net/zhangmike/article/details/78653154 ，也可点击下方的阅读原文）。时间过去了11年，回顾此文，发现对于当前实践仍然适用，因此改写升级到2.0。

标题上去掉了“独立测试团队”字样，因为这些敏捷测试实践没有一定要求由独立测试团队来完成，无论测试人员融入敏捷小团队，还是保持测试团队独立，如下实践都是可以采用的。

01

—

测试保护开发

通过快速的自动化测试跟进开发，确保新变化符合预期，也确保新变化不破坏已经获得的成果。

典型步骤如下：

1，开发人员根据需求，编写代码，实现界面和接口，无论是否采用TDD，ATDD，BDD。

2，几乎同步，或者略有滞后，测试人员编写自动化测试，首选是接口自动化测试，其次是界面自动化测试。也有做法是测试人员和开发人员一起维护自动化测试，这也是符合测试保护开发的特征。

3，一般保证，新实现代码出来后的第2天，相关的自动化测试得到并且运行通过。

这里紧密相关的实践有TDD、ATDD和BDD，这些都是超短反馈。如果测试人员先写测试再让开发人员实现，这样换人进行，是浪费时间。因此测试人员是难以参与到TDD、ATDD和BDD当中，反过来说，测试人员如果具备ATDD能力，那就不再是测试人员，而是开发人员了。而作为测试人员有测试人员的独立视角，就算开发人员通过诸如BDD已经提供了自动化测试集，测试人员仍然值得按测试视角去开发维护自动化测试。

02

—

测试人员深入参与敏捷团队的各项活动

• 子实践1：参加团队相关会议，如果是SCRUM，参加SCRUM所有要求的会议。注意尤其要参加需求梳理-澄清会议，避免让诸如PO或者产品经理讲两遍。
  

• 子实践2：可以阅读和修改最大范围的配置项（比如文档，代码，工作项）

• 子实践3：一起工作，比如把位子搬到开发人员旁边，如果同时参加多个项目，选择一个较近距离的位子。

说明：这个实践本身的宗旨与传统做法并无根本区别，这里的区别在于程度，甚至有做法把测试人员放入到敏捷团队之内，不再有独立运作的测试团队。

03

—

高频定期运行自动化测试

自动化测试发挥最大作用的途径就是运行得越高频越好，传统理论上认为自动化测试用例至少运行5次，才能覆盖开发自动化测试的工作量成本。因此在敏捷开发下更加值得高频运行。

• 子实践1：维护一套自动化测试环境，可以自动获得最新的自动化测试用例集和构建成果，并且运行自动化测试，至少每天1次。

• 子实践2：测试结果自动发布到合适的地方，得到跟踪管理，确保所发现的问题得到及时解决。

04

—

更多场景化测试用例

关注于局部功能的测试用例在敏捷开发中往往已经被自动化实现了。因此值得设计更多黑盒手工场景化测试用例。选择一些典型场景化测试用例开发为自动化测试用例也是可以的，但是此类测试用例的自动化开发所需工作量较大，要看测试团队的投入和质量目标安排，如果有象早年微软那样的测试开发工程师，那么当然可以安排。

一般而言，从经济角度出发，黑盒手工场景化测试用例是发现潜在缺陷的有效且经济的手段。本实践在传统测试中也有，这里要强调的特别之处是可以考虑手工测试尽量多用场景化测试，大幅减少针对单一功能或局部功能的测试用例。

05

—

开展探索性测试

在2009年3月本文最初版本里面，在场景化测试一节，有如下文字：如果存在丰富经验的测试人员，随机场景测试也是值得更多采用的。当时探索性测试还没有广泛流传，采用了“随机场景测试”说法，其基本特征是没有提前设计的测试用例，由经验丰富的测试人员进行错误发现尝试，当然“随机”这词在这里不是一个恰当的词汇，会让人关联到猩猩随便敲击键盘来测试。

对照到现在，以上测试其实就是探索性测试，英文是Exploratory Testing。探索 性测试经过多年发展，已经得到了广泛的实践。其中的“自由式探索性测试”与随机场景测试极为接近。另外还有基于场景的探索性测试，基于策略的探索 性测试，基于反馈的探索 性测试。

06

—

小结

从以上实践可以看到，测试人员所要掌握的技能有自动化测试、场景化测试，最好也要常握每日构建和自动测试报告。

上述的实践是否有效、是否高效，可以观察如下几点：

• 1，达到发布条件所需的测试是否及时地正常完成（没有过多加班）？

• 2，发布后缺陷数量是否减少或者始终保持在0缺陷交付？

• 3，获得快速发布的能力，工期或者时效是否缩短？

07

—

后记

最新2020年第14次敏捷年度状态报告刚刚发布，里面有个实践调查项是“Single Team（Integrated DEV and TEST）”，结果是51%， 去年第13次调查里面，这个数字是54%。经过了这么多年，这个结果恰恰反映了这方面的真实情况，独立测试团队在敏捷开发当中仍然有一席之地，而且几乎有半壁江山。本文V1.0时限定在了独立测试团队，最新2.0不再限定独立测试团队，但仍然适用于独立测试团队，当然也覆盖了融合开发测试的单一团队里面的测试。详见 ，里面剖析了独立测试团队和融合团队。

----全文完，以下欣奔敏捷星球介绍----

---

笔者自2018年12月开启欣奔敏捷星球，到现在有500多天，在这里记录敏捷教练一线实战情况，记录最真实的具体实例，积累达600多条内容，覆盖了IT敏捷+业务敏捷+DevOps的诸多细节。

本星球展示了更快交付的敏捷方法：在百人级规模，采用需求流模式，让创意从选择启动到上线只需要一个月时间，快速响应市场变化，更快捕捉市场机会。欢迎朋友们来看看:)

欣奔敏捷星球记录了从IT到业务的敏捷实践以及DevOps建设实战情况，提供最鲜活的真实案例。也有成员基于实践情况的提问和解答，星主提供远程教练咨询服务。目前积累内容包括全套敏捷项目管理教材，ScrumBan欣奔版，需求流模式，DevOps具体解决方案。

最新优惠见，截止6月30日12：00。