敏捷测试指引（7）- 敏捷项目中的测试员

 

敏捷测试指引（7）- 敏捷项目中的测试员

陈能技

2007-9-27

 

原文：Agile Testing Directions –Testers on agile projects（Brian Marick）

 

敏捷项目中是否应该有测试员呢？

 

首先：替换测试员的是谁？是让非测试专业人员（程序员、业务专家、技术文档编写人员等）来执行这样的活动：帮助创建指导性的例子和对产品进行批判？还是，反过来，让测试员来做编程、业务分析、技术写作等工作呢？把“测试”仅仅作为技能的集合而存在，在项目中拥有充足的数量，用于服务所有需要这些技能的任务。

 

为什么非专业测试员会是个坏主意？这里是一些可能的原因：

l         测试技能很难学到。如果你尝试作为测试员同时是程序员，或者作为测试员同时是技术文档编写人员，你不会拥有所需要的最少的技能来成为足够好的测试员。

 

l         假设你是世界上最好的篮球运动员，同时是最棒的洗车工。你可能还是愿意让别人帮你洗你的车，因为比起你自己洗车省下的钱，你可以赚取更多的时间来打篮球。这就是相对优势的一个例子。因此，为什么不让一个懂得测试的诀窍的人只是做测试，而让一个在编程方面相对强的人专注于编程呢？

 

l         测试虽然说不上是是一种天生的技能，但是某些人就是喜欢吹毛求疵，有些人则不擅于批判。

 

l         很多人在找自己工作的错误时会有困难。因此把测试和其它任务混在一起的话会测试得很糟糕。中间存在太多情绪上的利益冲突了。

 

l         测试员能从“有用的无知”得到很多益处。不知道实现的细节使得他们更容易从用户的角度看什么类型的错误是用户容易犯的。

 

论据

让我首先解释一下“最小所需技能”和“相对优势”。这些论据在面向技术的产品批判中是最强的，像安全性测试或可用性测试。在一个实际的项目，我一定能看到专门的安全性测试员。在小一点的项目，我能看到临时出现的安全性测试员。

 

对于我在面向业务的产品批判中所依赖的探索性测试员，我不那么确信。探索性测试员发现的这么多的bug中，很多是程序员可以预防的，如果他们能经常看看那些bug并使它们内在化。把bug内在化的最好的途径是把程序员纳入到寻找bug的行列，而不仅仅是修改bug。如果测试人员来写其中的一些代码，则bug会少些。因此这个论据是反对拥有专业的测试员的。

 

换言之，我认为人们都有最小所需的探索性测试技能。

 

我想相同的原因适用于矩阵的左边-面向技术的检查性例子（单元测试）和面向业务的检查性例子（客户测试）。我把这些方面的东西教给测试员。程序员也可以做。业务专家也可以做，虽然可能很少有人有机会达到最小技能的水平。那是为什么面向业务的例子是被团队创建的，而不是仍过墙的。实际上，团队沟通是如此的重要，以致应该把所有相对优势的影响淹没。

 

现在，让我们看看所谓的“天生的能力”。当Jeff Patton给我们展示以使用为中心的设计的例子时，其中一个练习是为一个假想的会议文件评审系统创建角色。我当时创建了类似“不情愿的文件评审者”、“过度疲劳的会议主席”、“拖延的作者”等角色。有些人评价说，“你能看得出Brian是个测试员”。我们都轻笑为什么我会倾向于悲观的例子。

 

但是最重要的是 – 那是学术行为。我这样做是因为我有意识地去找出那些会跟开发人员希望不一致的操作系统的人。我的预感是我天生比别人更倾向于批判，但是我学着成为一名合适的测试员。我想普通的程序员也可以。我还没有碰到过一名程序员是过分乐观主义者，以致认为其他人的软件是世界上最好的。

 

是你自己引起的所谓“情绪上的利益冲突”。我曾经让Elisabeth Hendrickson对我的一个程序进行探索性测试。我颇为得意-我认为我的面向技术和面向业务的例子都通过了。当然，她很快地发现了一个严重的bug。我不仅仅是震惊，而且做出了很多测试员都很熟悉的自我保护性的反应。

 

后来我在最后期限之前做了一些探索性测试，意识到我在用户界面的“不重要的”部分编码工作做得不够好，但是我感觉不情愿去攻击这些GUI，因为我实在是不希望修改bug。

 

因此这是个真正的问题。我希望我们可以通过一些实践来减少它。例如，就像结对编程的程序员倾向于保持诚实地重构，那么在探索性测试时保持诚实地攻击代码。在进度压力下不愿意重构 – 导致的是设计的“债”的积累 – 不是一个可以永远摆脱的问题，但是项目组要学会处理它。也许对于情绪上的利益冲突也一样。

 

跟情绪上的利益冲突相关的问题是“有用的无知”。假设是在第五次迭代。由测试员/程序员/其他人员组合在一起，从开始就工作在一起。当对产品进行探索时，他会有开发习惯。如果有两种方法做某件事，他会选择同一个。当他使用产品时，他不会犯很多概念上的错误，因为他知道产品应该是怎样工作的。他的团队已经写了很多指引性的例子 – 在他们做这个的时候，已经建立了一个清晰的“理想用户”应该是怎样的一个模型，他们会在想象其他类型的用户会怎样方面碰到麻烦。

 

这是个很难解决的问题。角色扮演能帮助解决。Elisabeth Hendrickson教测试员在测试过程中要时不时假定极端的人物。如果Bug Bunny来使用这个产品会发生什么事情呢？他是个麻烦制造者，总是探究别人的弱点，总是愚弄权威。想象一下卓别林在摩登时代的角色：天真、毫无准备、被迫工作得更快。另外一个有用的技术是Hans Buwalda的肥皂剧测试方法（Soap Opera Testing）。

 

我希望这些技术能帮助解决问题，尤其是结对在一起时（互相之间会感染）。但是我不禁要想伪造的无知不能替代真实的东西。

 

组队

因此，是否应该包含测试员在敏捷项目中呢？要看情况而定。但是如果我负责一个重要的产品的敏捷项目组的组队，我会考虑以下方式作为默认的做法：

l         我会找一到两个拥有丰富测试经验的人。他们应该懂一些编程的知识。他们应该擅长于跟业务专家讨论并很快地获取一些领域知识。首先，我会依靠他们来确保面向业务的例子可以很好地工作。然后我会期待他们学习更多的编程，编写基础代码，教程序员，成为程序员一样的人。

 

个性非常重要。他们必须喜欢新奇的事物，他们不应该把他们的个性情绪化地包含到工作中，他们应该习惯于服务其他人。

 

l         如果这些人在探索性测试中做得很出色应该受到赞赏。但是，不管怎样，整个项目组都会得到关于探索性测试的培训。我会让外部的探索性测试教练定期地来造访。他们既会扩展培训，还会做一些探索性测试。作为一个持续的监督，用于防止项目组过于习惯于产品而不能找到足够的bug。

 

l         对于非功能缺陷，像可用性、安全性、性能比较看重的产品，我会购买专门的技术（定点的顾问、造访型的顾问、或者招聘这方面的专门技术人员）。他们会对创建产品提出建议、培训项目组、测试产品。

 

l         我会极力让真正的用户参与（不仅仅是代表用户的业务专家）。可能会让项目组成员到用户那边，而不是反过来。我会让项目组成员把自己想象成人类学家来研究产品所在的领域，不仅仅是倾听bug和功能特性的请求。

 

是否有测试员在项目组中？谁关心这个？- 总之会有好的测试，即使指出某个活动中有测试会日益地困难，像说“那里，就在那里。那就是测试，没别的”一样。