(六)敏捷测试指引-敏捷项目中的测试员

敏捷项目中是否应该有测试员呢？
 
        首先：替换测试员的是谁？是让非测试专业人员（程序员、业务专家、技术文档编写人员等）来执行这样的活动：帮助创建指导性的例子和对产品进行批判？还是，反过来，让测试员来做编程、业务分析、技术写作等工作呢？把“测试”仅仅作为技能的集合而存在，在项目中拥有充足的数量，用于服务所有需要这些技能的任务。
 
为什么非专业测试员会是个坏主意？这里是一些可能的原因：
        测试技能很难学到。如果你尝试作为测试员同时是程序员，或者作为测试员同时是技术文档编写人员，你不会拥有所需要的最少的技能来成为足够好的测试员。
 
        假设你是世界上最好的篮球运动员，同时是最棒的洗车工。你可能还是愿意让别人帮你洗你的车，因为比起你自己洗车省下的钱，你可以赚取更多的时间来打篮球。这就是相对优势的一个例子。因此，为什么不让一个懂得测试的诀窍的人只是做测试，而让一个在编程方面相对强的人专注于编程呢？
 
        测试虽然说不上是是一种天生的技能，但是某些人就是喜欢吹毛求疵，有些人则不擅于批判。
 
        很多人在找自己工作的错误时会有困难。因此把测试和其它任务混在一起的话会测试得很糟糕。中间存在太多情绪上的利益冲突了。
 
        测试员能从“有用的无知”得到很多益处。不知道实现的细节使得他们更容易从用户的角度看什么类型的错误是用户容易犯的。
 
论据
        让我首先解释一下“最小所需技能”和“相对优势”。这些论据在面向技术的产品批判中是最强的，像安全性测试或可用性测试。在一个实际的项目，我一定能看到专门的安全性测试员。在小一点的项目，我能看到临时出现的安全性测试员。
 
        对于我在面向业务的产品批判中所依赖的探索性测试员，我不那么确信。探索性测试员发现的这么多的bug中，很多是程序员可以预防的，如果他们能经常看看那些bug并使它们内在化。把bug内在化的最好的途径是把程序员纳入到寻找bug的行列，而不仅仅是修改bug。如果测试人员来写其中的一些代码，则bug会少些。因此这个论据是反对拥有专业的测试员的。
 
        换言之，我认为人们都有最小所需的探索性测试技能。
 
        我想相同的原因适用于矩阵的左边-面向技术的检查性例子（单元测试）和面向业务的检查性例子（客户测试）。我把这些方面的东西教给测试员。程序员也可以做。业务专家也可以做，虽然可能很少有人有机会达到最小技能的水平。那是为什么面向业务的例子是被团队创建的，而不是仍过墙的。实际上，团队沟通是如此的重要，以致应该把所有相对优势的影响淹没。
 
        现在，让我们看看所谓的“天生的能力”。当Jeff Patton给我们展示以使用为中心的设计的例子时，其中一个练习是为一个假想的会议文件评审系统创建角色。我当时创建了类似“不情愿的文件评审者”、“过度疲劳的会议主席”、“拖延的作者”等角色。有些人评价说，“你能看得出Brian是个测试员”。我们都轻笑为什么我会倾向于悲观的例子。
 
        但是最重要的是 – 那是学术行为。我这样做是因为我有意识地去找出那些会跟开发人员希望不一致的操作系统的人。我的预感是我天生比别人更倾向于批判，但是我学着成为一名合适的测试员。我想普通的程序员也可以。我还没有碰到过一名程序员是过分乐观主义者，以致认为其他人的软件是世界上最好的。
 
       

原文转自：http://www.ltesting.net