后来我在最后期限之前做了一些探索性测试，意识到我在用户界面的“不重要的”部分编码工作做得不够好，但是我感觉不情愿去攻击这些GUI，因为我实在是不希望修改bug。
因此这是个真正的问题。我希望我们可以通过一些实践来减少它。例如，就像结对编程的程序员倾向于保持诚实地重构，那么在探索性测试时保持诚实地攻击代码。在进度压力下不愿意重构 – 导致的是设计的“债”的积累 – 不是一个可以永远摆脱的问题，但是项目组要学会处理它。也许对于情绪上的利益冲突也一样。
跟情绪上的利益冲突相关的问题是“有用的无知”。假设是在第五次迭代。由测试员/程序员/其他人员组合在一起，从开始就工作在一起。当对产品进行探索时，他会有开发习惯。如果有两种方法做某件事，他会选择同一个。当他使用产品时，他不会犯很多概念上的错误，因为他知道产品应该是怎样工作的。他的团队已经写了很多指引性的例子 – 在他们做这个的时候，已经建立了一个清晰的“理想用户”应该是怎样的一个模型，他们会在想象其他类型的用户会怎样方面碰到麻烦。
这是个很难解决的问题。角色扮演能帮助解决。Elisabeth Hendrickson教测试员在测试过程中要时不时假定极端的人物。如果Bug Bunny来使用这个产品会发生什么事情呢？他是个麻烦制造者，总是探究别人的弱点，总是愚弄权威。想象一下卓别林在摩登时代的角色：天真、毫无准备、被迫工作得更快。另外一个有用的技术是Hans Buwalda的肥皂剧测试方法（Soap Opera Testing）。
我希望这些技术能帮助解决问题，尤其是结对在一起时（互相之间会感染）。但是我不禁要想伪造的无知不能替代真实的东西。
组队
因此，是否应该包含测试员在敏捷项目中呢？要看情况而定。但是如果我负责一个重要的产品的敏捷项目组的组队，我会考虑以下方式作为默认的做法：
我会找一到两个拥有丰富测试经验的人。他们应该懂一些编程的知识。他们应该擅长于跟业务专家讨论并很快地获取一些领域知识。首先，我会依靠他们来确保面向业务的例子可以很好地工作。然后我会期待他们学习更多的编程，编写基础代码，教程序员，成为程序员一样的人。
个性非常重要。他们必须喜欢新奇的事物，他们不应该把他们的个性情绪化地包含到工作中，他们应该习惯于服务其他人。
如果这些人在探索性测试中做得很出色应该受到赞赏。但是，不管怎样，整个项目组都会得到关于探索性测试的培训。我会让外部的探索性测试教练定期地来造访。他们既会扩展培训，还会做一些探索性测试。作为一个持续的监督，用于防止项目组过于习惯于产品而不能找到足够的bug。
对于非功能缺陷，像可用性、安全性、性能比较看重的产品，我会购买专门的技术（定点的顾问、造访型的顾问、或者招聘这方面的专门技术人员）。他们会对创建产品提出建议、培训项目组、测试产品。
我会极力让真正的用户参与（不仅仅是代表用户的业务专家）。可能会让项目组成员到用户那边，而不是反过来。我会让项目组成员把自己想象成人类学家来研究产品所在的领域，不仅仅是倾听bug和功能特性的请求。
是否有测试员在项目组中？谁关心这个？- 总之会有好的测试，即使指出某个活动中有测试会日益地困难，像说“那里，就在那里。那就是测试，没别的”一样。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
