写点什么

敏捷测试过程的度量标准

  • 2013-02-15
  • 本文字数:2494 字

    阅读完需:约 8 分钟

大多数习惯传统阶段性开发模式的测试人员也习惯了制定和使用度量数据、在正式的缺陷跟踪系统中记录缺陷、编写详细的测试计划。这些人在敏捷开发中应该何去何从?许多软件企业必须遵守审计制度或者质量过程模型。这些要求通常不会因为你开始使用敏捷开发实践而消失。事实上,一些人担心敏捷开发与这些模型和标准如 CMMI、ISO 9000 不协调。敏捷测试经理 Lisa讨论了有关度量标准涉及的各个方面。

Lisa 首先阐述了为什么我们需要度量:

我们有充分的理由收集和跟踪度量。当然,也有理由不应该这样做。任何人都可能把良好的度量标准使用得非常糟糕,例如将其作为每个团队成员业绩衡量的基础。但是,如果没有度量,如何测算进度?当度量被用作路标——提醒团队偏离了轨道或者在正确的道路上提供反馈——那么就值得收集。单元测试的数量每天都在增长吗?为何代码覆盖率从 75% 下降到 65%?原因很可能是,我们去掉了测试覆盖的无用代码。度量可以警示我们问题,但是它们通常无法独立地提供价值。

同时,她指出,在实现团队目标的过程中,测算里程碑的度量是有用的。如果目标是把单元测试代码覆盖率提高 3%,那么在每次添加代码后我们都可能运行代码覆盖测试以确保没有放松单元测试。如果没有实现预期的改善,找出原因比抱怨因此而减少的奖金更重要。不应该关注个人度量,而是着眼于目标和到达目标的趋势。

不仅如此,度量还帮助团队(包括客户)跟踪迭代期内和版本期内的进展。如果使用燃烧图,而且一直在上升而不是下降,那么这是一个警示信号,看一看当前的状况,确保我们理解和解决了问题。也许团队缺乏故事的重要信息。度量,包括燃烧图,不应该用作一种惩罚或者责备的形式。举例来说,类似“为何你的估算太低?”或者“为何你不能完成所有的故事?”的问题应该改成团队的形式:“为何我们的估算这么低?”、“为何我们没有完成所有故事?”

度量,如果使用得当,可以激励团队。Lisa 的团队跟踪每一个构建运行的单元测试数量。大里程碑——100 次测试、1000 次测试、3000 次测试——都值得庆祝。单元测试的数量每天都在增长对于开发团队和客户团队来说都是一种良好的反馈。但是,请注意数字本身毫无意义。举例来说,测试可能写得非常糟糕或者必须充分测试产品,那么我们可能需要 10000 次测试。数字不能孤立地看待。

Lisa 还举了一个现实当中的例子:

Pierre Veragen 告诉我,他曾经所在的团队对度量极度厌恶,团队成员决定停止度量测试覆盖的代码范围。六个月之后当他们决定再次度量的时候,惊讶的发现代码覆盖率已经从 40% 降低到了 12%。如果不使用正确的度量,你会付出何种代价?

当你试图找出衡量的内容,首先需要理解你想解决的问题。当你知道问题的描述,那么你可以设定一个目标。这些目标需要是可衡量的。“在 20 位并发用户的压力下把 XYZ 应用的平均响应时间减少到 1.5 秒”比“提高 XYZ 应用的性能”要好得多。如果你的目标是可度量的,你需要收集的测量数据是显而易见的。

请记住,把度量作为一种激励的手段而不是打击士气的方式。再强调一遍:关注目标,而不是度量。可能你没有使用正确的度量来评估是否实现了团队的目标,或者没有根据情境解释它们。缺陷报告数量的增长可能意味着团队测试做得好,而不是他们代码写得糟糕。如果度量没有帮助你了解进度,你可能使用了错误的度量。

接下来,Lisa 提出了一些与度量有关的问题,让读者进一步的思考度量标准的意义和制定规则。

可度量的目标是一件好事。如果无法通过某种方式衡量,就无法证明实现了目标。另一方面,使用度量判断个人或者团队的业绩是危险的。统计数据本身可以被扭曲成任何有害的解释并被利用。传统上,采用代码行数作为一种软件衡量标准。行数多是好事吗,意味着团队生产力高?还是坏事,意味着团队编写了低效的意大利面式的代码?那么发现的缺陷数量呢?通过这些数据来衡量测试人员有意义吗?会怎样帮助他们把工作完成得更出色呢?一个开发团队每行代码产生的缺陷很多,就说工作得不好吗?或者说发现了更多缺陷的团队工作得出色吗?即使存在这种思想,它又如何激励团队与这些数据斗争,会使团队成员开始编写无缺陷的代码吗?

我们都知道度量都会变化。有多少测试运行和通过?多少天才能得到一个稳定的构建版本?整个构建都通过了吗?无法看到和能够轻易解释的度量是没有意义的。如果你想要跟踪测试通过的数量,那么确保度量以正确的方式呈现给合适的人。据我说知,硕大的图表是显示度量最有效的方式。你的度量值得吗?不要为了生产数字而度量。想一想你能从这些数据中得到什么?

最后,Lisa 谈到了度量的投资回报率:

当你定义所需的度量时,确保代价是合理的。如果连续构建产生了有用的数据,那么度量是有意义的。如果无论如何都要运行构建并提供我们额外的信息,那么是额外的收获。如果需要做大量额外的工作以获得信息,想想是否值得。

Lisa 的团队花费了不小的精力去跟踪比较每个故事使用的实际时间和评估时间。除了发现评估也不过如此之外还学到没的东西了吗?没什么。一些经验丰富的团队不需要 sprint 的进度图,因为任务会议提供了度量进度的足够信息。他们能够把花在评估任务和计算剩余时间的时间用在更有生产力的活动上。这并不意味着我们建议你停止跟踪评估。新的团队需要理解速度和进度,因此才能逐步提高。

缺陷率是传统的软件度量标准,它们对于致力于零缺陷的团队来说可能没有多大价值。知道开发过程中发现和修补的缺陷率没有什么意义,因为发现和修补是开发的必要部分。如果测试人员向开发人员展示了一个由其代码引起的缺陷,并且编写了单元测试,缺陷立刻被修补,那么就没有必要记录这个缺陷。另一方面,如果在产品发布时发现了很多缺陷,那么有必要跟踪其数量以查看团队是否改进。

当 Lisa 的团队开始重写错误不断的遗留应用时,他们设定了一个目标:在产品发布的六个月内新代码不能出现超过六个严重缺陷。制定一个直接和容易跟踪的目标有助于帮助团队想办法在开发阶段减少缺陷并达到目标。记录每一个度量标准的投资回报并决定是否跟踪或者维护它。收集数据的精力与其产生的价值相称吗?容易交流和理解吗?总之,视情况而定。在几个 sprint 阶段实验一个特定度量标准,然后评估其是否成功。

2013-02-15 20:182642
用户头像

发布了 501 篇内容, 共 266.5 次阅读, 收获喜欢 61 次。

关注

评论

发布
暂无评论
发现更多内容

产品思维

lenka

5月日更

数据预处理&特征工程

Qien Z.

Python 5月日更

520节日快乐

IT蜗壳-Tango

5月日更

❤【520特别祝福篇】愿有情人终成眷属,已成眷属爱情稳固

码界西柚

爱情 5月日更 520单身福利 520 单身福利

区块链技术在数字农业领域的应用挑战

CECBC

亚马逊云科技宣布在上海设立生命健康行业数字化赋能中心

亚马逊云科技 (Amazon Web Services)

数据挖掘从入门到放弃(七):TensorFlow和keras实现线性回归LinearRegression

数据社

机器学习 5月日更

【偶尔一道ctf】xctf adword mobile easy-apk

Thrash

ArrayList vs LinkedList

ltc

ArrayList linkedlist

Flink的广播变量

大数据技术指南

大数据 flink 5月日更

520,珍惜眼前人

数据社

520 520单身福利 520 单身福利

架构学习笔记:复杂度来源

风翱

5月日更 架构复杂度

SWOT分析模型

石云升

创业 战略 职场经验 5月日更

夺魁!亚马逊云科技荣膺中国数据管理解决方案领导者!

亚马逊云科技 (Amazon Web Services)

写给大神

小梨蕊

情人节 520单身福利 520 单身福利

Nginx基础配置-反向代理

梁龙先森

nginx 大前端

【epoll】epoll多路复用和Reactor设计思想

Linux服务器开发

后端 网络编程 C/C++ epoll Linux服务器开发

为什么“放弃”?

Nydia

学习

API网关才是大势所趋?SpringCloud Gateway保姆级入门教程

Zhendong

Java spring API 网关

造车潮

ES_her0

5月日更

Dubbo 延迟与粘滞连接

青年IT男

dubbo

浪潮云洲链斩获2020-2021年度新一代信息技术创新产品殊荣

Golang function

escray

学习 极客时间 Go 语言 5月日更

发布两小时,Github访问量破百万,阿里内部首次公布的 Java10W 字面经有多强?

Java 程序员 架构 面试

一款开源小工具,提升K8S资源管理幸福感!

Rancher

高性能 JavaScriptの笔记(四)

空城机

JavaScript 大前端 5月日更

音频均衡器EQ

floer rivor

音视频 Eq

破茧成蝶,如何用数据之力重塑您的业务?| 云途专栏

亚马逊云科技 (Amazon Web Services)

线程与线程池的那些事之线程篇

秦怀杂货店

Java 线程 多线程 进程 并发

父母为什么催婚,而你又在逃避什么

小天同学

婚姻 爱情 5月日更

珠联壁合地设天造|M1 Mac os(Apple Silicon)基于vscode(arm64)配置搭建Java开发环境(集成web框架Springboot)

刘悦的技术博客

Java vscode spring Boot Starter JDK11 m1

敏捷测试过程的度量标准_DevOps & 平台工程_崔康_InfoQ精选文章