敏捷测试指引(5)- 用面向业务的例子批判产品

翻译 2007年09月26日 23:35:00
 
敏捷测试指引(5)- 用面向业务的例子批判产品
陈能技
2007-9-24
 
原文:Agile Testing Directions – business-facing product critiques(Brian Marick)
 
为了帮助讨论和理解,我把“敏捷项目中的测试”这一主题分解成4个区分的主题。今天,我开始讲矩阵的右边:产品批判。
 
使用面向业务的例子来设计产品是好的,但是假设例子是错误的怎么办?谁都会犯错误。业务专家会忘记一些用户真正需要的东西。或者业务专家错误地表达了需求,而程序员却非常忠诚地实现了错误的东西。
 
那些错误,如果记起来了或注意到了,则可能会当作bug,也可能被认为是需要的功能特性。但两者的界限很模糊。我会简单地把它们叫做“问题”。
 
问题是如何引起项目组的注意的呢?
l         很多敏捷项目组会在一个迭代结束时向业务专家和感兴趣的外部人员演示软件系统。这时候会是激怒某个人的时候,“噢…我是那样说过,但是我不是这个意思”。
l         敏捷项目喜欢频繁地发布软件给它的用户(可能比用户希望更新的频率还要频繁)。当用户试用产品的时候,他们会指出存在的问题。
 
这些反馈循环很紧凑,比传统的项目要紧密,因为敏捷项目喜欢短的迭代。但是它们不是最理想的。业务专家可能由于过于靠近项目而不能以新的、没有偏见的眼光去发现问题。用户通常不报告他们在软件使用中发现的问题。当他们反馈问题时,报告得又不够专业以致没办法执行。而反馈的周期不能像敏捷项目希望的那样的频繁。可能仅仅是针对一行代码的改变的反馈,但是需要等上3个月才能从用户那收集到。
 
因此,我们需要额外的产品批判形式 – 能注意到用户会怎样,而且能及时注意到。
 
产品批判的方式拥有前期创建的例子所不具备的资源:一个新的迭代版本的真正工作的软件。当你描述某些目前不存在的东西的时候,你是在脑海里操作一个抽象的东西,一个你想象中的物品。当你亲手操作一个产品的时候会激发不同的理解和判断。你可能注意到,当试驾一辆汽车的时候,你不会专注于它的规格说明。操纵是与思考不一样的。
 
因此,面向业务的产品批判应该专注于操作方面,尝试逼近真正的不同用户的体验。就像James Bach,Cem Kaner,Elisabeth Hendrickson他们所说的探索性测试(Exploratory)的形式。
 
进一步的,我发现我们在尝试至少5种类型的探索性测试:
1、 一个探索性测试员
2、 结对探索性测试员。James Bach 和Cem Kaner可能在这方面有最多的经验。
3、 探索性测试员与一个程序员结对。Jonathan Kohl会在2004年1月的STQE杂志(http://www.stqemagazine.com/)有一篇这样的文章。我在这方面没有什么经验,程序员也喜欢这样的方式。值得注意的是,当我在RoleModel Software进行这种方式的时候,它导致了一个有趣的并且有用的关于基础程序的讨论。那样的话,它成了一种类似回顾的方式,这进一步让我相信它是迭代结束时很好的一种活动。
4、 让探索性测试员与项目中的业务专家结对
5、 让探索性测试员与感兴趣的非参与者(用SCRUM的术语来说就是“chickens,小鸡”),例如经理主管、新用户等等。
 
对于每一种,我们应该探索关于什么时候测试员应该是项目组外的人的问题。这些外部的测试人员不会存在偏见和先入为主,但是存在缺点就是:他们需要花更多的时间来学习一些基本的东西。那也会使发现的问题存在一些偏离。
 
当我一年前开始在敏捷项目谈论探索性测试的时候,我想它会在发现bug的同时对提出一些大胆的关于产品的新构思有启迪作用。一个过程能发现两类问题。有一段时间,我把它叫做“探索性学习”来强调它的扩展的角色。
 
后来我推断这两个目标不能很好地走在一起。因为找bug实在是太诱人了 – 对于功能特性的思考会在探索性测试的过程中迷失。有些时候能同时出现,但是不足够。所以我想可能需要一个单独的功能特性的脑力风暴活动。关于这一点,现在我还没有什么特别好的主意。“需要进一步的研究”。
 
 
 
 
 
 
 
 
 

相关文章推荐

基于nRF24L01+产品测试指引

  • 2015年10月29日 16:36
  • 712KB
  • 下载

思考:你的互联网+项目为何敏捷不起来?一、占领制高点的业务架构、产品规划

首先,敏捷的特征是什么?迭代、增量、小 团队。那边它最怕的是什么?需求变更!已经上线的功能,已经完成的同一需求,如何还经常变更,会使团队很气馁,觉得之前开发的东西没有任何价值和意义,会使士气低落!那为...

敏捷开发产品管理系列之八:基于业务设计技术架构(兼谈12306性能问题)

本文是敏捷开发产品管理系列的第八篇。(专栏目录)在产品开发中,常常遇到产品性能问题,这些性能问题会很大程度上影响到产品的架构。但解决这些性能问题,切莫认为只是技术人员的事情,产品经理和产品总监也要参与...

【腾讯TMQ】敏捷测试-快速俘虏产品&开发

快速互联网的状态下,测试的价值体现在哪里?俗话说,长江后浪推前浪,前浪拍死沙滩上。我们在新人面前标签应该不仅限于工龄属性上的增长,在经验累积上也是有加分项的。那么问题来了,能体现我们经验值的有什么呢?...
  • TMQ1225
  • TMQ1225
  • 2016年11月24日 16:48
  • 386

巴巴运动网 (18--20) 用泛型技术对产品分类的业务管理Bean抽象,测试,重载

package com.itcast.service.base; public interface DAO { /** * 保存实体 * @param entity 实体id */...

敏捷测试理论以及实践 - 5

转自:http://blog.csdn.net/softerwarer/article/details/6901872 【本篇是《敏捷测试理论以及实践》第五篇,(第一篇,第二篇,...

敏捷测试理论以及实践 - 5

以前在《结合工具来实现敏捷开发》这篇文章中,我已经谈到了我们公司目前的开发情况,在这里也不再重复介绍了,反正主要就是用 TechExcel的 DevSuite 系统来进行管理整个流程。至于很多人可能...

敏捷测试理论以及实践 - 5

【本篇是《敏捷测试理论以及实践》第五篇,(第一篇,第二篇,第三篇,第四篇,第五篇,第六篇,第七篇)】     以前在《结合工具来实现敏捷开发》这篇文章中,我已经谈到了我们公司目前的开发情况,在这...

微服务产品级敏捷: 重新定义产品的集成测试

微服务产品的集成测试主要区分为: 1. 微服务内的 User Stories 的集成测试 2. 特性内的微服务的集成测试 3. 微服务产品内的特性的集成测试...

android学习笔记5--------------业务bean(单元测试) .

android的单元测试非常好用,它可以检测你的功能类或方法是否正确,而不依赖于一些复杂的操作。 单元测试配置: 1.单元测试类继承AndroidTestCase 2.AndroidManife...
  • yf210yf
  • yf210yf
  • 2011年09月27日 11:58
  • 1457
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:敏捷测试指引(5)- 用面向业务的例子批判产品
举报原因:
原因补充:

(最多只允许输入30个字)