但是最重要的是 – 那是学术行为。我这样做是因为我有意识地去找出那些会跟开发人员希望不一致的操作系统的人。我的预感是我天生比别人更倾向于批判，但是我学着成为一名合适的测试员。我想普通的程序员也可以。我还没有碰到过一名程序员是过分乐观主义者，以致认为其他人的软件是世界上最好的。
是你自己引起的所谓“情绪上的利益冲突”。我曾经让Elisabeth Hendrickson对我的一个程序进行探索性测试。我颇为得意-我认为我的面向技术和面向业务的例子都通过了。当然，她很快地发现了一个严重的bug。我不仅仅是震惊，而且做出了很多测试员都很熟悉的自我保护性的反应。
后来我在最后期限之前做了一些探索性测试，意识到我在用户界面的“不重要的”部分编码工作做得不够好，但是我感觉不情愿去攻击这些GUI，因为我实在是不希望修改bug。
因此这是个真正的问题。我希望我们可以通过一些实践来减少它。例如，就像结对编程的程序员倾向于保持诚实地重构，那么在探索性测试时保持诚实地攻击代码。在进度压力下不愿意重构 – 导致的是设计的“债”的积累 – 不是一个可以永远摆脱的问题，但是项目组要学会处理它。也许对于情绪上的利益冲突也一样。
跟情绪上的利益冲突相关的问题是“有用的无知”。假设是在第五次迭代。由测试员/程序员/其他人员组合在一起，从开始就工作在一起。当对产品进行探索时，他会有开发习惯。如果有两种方法做某件事，他会选择同一个。当他使用产品时，他不会犯很多概念上的错误，因为他知道产品应该是怎样工作的。他的团队已经写了很多指引性的例子 – 在他们做这个的时候，已经建立了一个清晰的“理想用户”应该是怎样的一个模型，他们会在想象其他类型的用户会怎样方面碰到麻烦。
这是个很难解决的问题。角色扮演能帮助解决。Elisabeth Hendrickson教测试员在测试过程中要时不时假定极端的人物。如果Bug Bunny来使用这个产品会发生什么事情呢？他是个麻烦制造者，总是探究别人的弱点，总是愚弄权威。想象一下卓别林在摩登时代的角色：天真、毫无准备、被迫工作得更快。另外一个有用的技术是Hans Buwalda的肥皂剧测试方法（Soap Opera Testing）。
我希望这些技术能帮助解决问题，尤其是结对在一起时（互相之间会感染）。但是我不禁要想伪造的无知不能替代真实的东西。
组队
因此，是否应该包含测试员在敏捷项目中呢？要看情况而定。但是如果我负责一个重要的产品的敏捷项目组的组队，我会考虑以下方式作为默认的做法：
我会找一到两个拥有丰富测试经验的人。他们应该懂一些编程的知识。他们应该擅长于跟业务专家讨论并很快地获取一些领域知识。首先，我会依靠他们来确保面向业务的例子可以很好地工作。然后我会期待他们学习更多的编程，编写基础代码，教程序员，成为程序员一样的人。
此文章共有3页 上一页 1 2 3 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
