大家关于XP的理解，我发现至少有3种以上： 1、 书上说的（Kent Beck的《Extreme Programming Explained》 、 Kent Beck 和Martin Fowler的《Planning Extreme Programming》） 2、 经过XP专家指导和培训，项目组的理解 3、 只是看过书，自己的理解 按书上说的，XP包括单元测试（由程序员完成）和可接受性测试（由“客户”完成）。程序员使用单元测试只是验证软件是与所期待的一样工作。可接受性测试需要验证软件是像顾客需要的一样工作。
这里很明确，“客户”是被期待成这样的工作角色：编写用户故事（类似用例），然后编写对用户故事的测试。书中对于“客户”是谁说得有点含糊，所以这里要加上引号。“客户”是做出业务决定的人。在XP之外，这个人通常被称为产品经理或业务分析员。 即使是在很好地培训过XP的团队，也很难让这个“客户”编写可接受性测试。所以最后还是开发人员或测试人员来写，并且很晚才写。的确，研究表明可接受性测试的编写是XP中最难被认同的实践之一（\"Circle of Life, Spiral of Death,\" Ramachandran and Shukla, in XP/Agile Universe 2002 Proceedings, Wells & Williams, ed.）。为了弥补这个不足，XP的创始人之一Ward Cunningham最近开发了一个开源的测试框架来解决可接受性测试的问题(Framework for Integrated Test, Ward Cunningham)。 XP的书上没有要求程序员替代测试员测试。更恰当地说，他们主张测试的总体代价要降低，主要是通过避免那些通常会困扰软件项的冗长的测试阶段。但是测试还是必须要做的，从程序员方面和客户方面都要。 有些人主张XP应该抛弃测试人员。这个论调其实是双面的。一方面鼓励程序员应该做好单元测试。一方面也是在指责一些任性的、不关注项目成败的测试员。Lisa Crispin写了一本书来为XP项目组中的测试员争取更多的尊重（Testing Extreme Programming, Lisa Crispin and Tip House）。
对于最后的测试，无疑是需要测试员的。但是XP要求测试员作为项目组的服务。如果测试员没有得到恰当的方法培训，则会导致失败。 的确，有些人认为XP是想最小化黑盒测试员的角色，因为有着对低效率的测试员的不好的经验。主要是抱怨测试员： 1、 反对不符合他们传统观点的过程改进 2、 过分关注对于项目影响很小的bug 3、 缺乏有贡献性的技术、技能 [Page]4、 缺乏对现代开发方法和架构的理解
Cem kaner曾经说过，“除非我们领域的技能水平得到充分的提高，否则程序员还是会继续找方法旁路测试组。如果我们继续在我们的项目组中应用低技能的传统的过程、审判式的、政治活动式的过程，我想我们会看到测试员被持续地、合理地、可怜地从项目的重要角色中排除出去。”
如果你是XP项目组中的测试员之一，这里有几个方法你可以向你们团队展示你的价值： 1、 展示你在软件期待值方面（需求）的有用的观点，一个与程序员或“用户”不一样的、对项目成败有用的观点。 2、 展示你对自己作为信息提供者的角色很满意，而不是坚持作为“守门员”或“质量警察”（\"Don’t Become the Quality Police,\" Pettichord, Stickyminds.com, 1 July 2002）。 3、 展示你能适应迭代的开发方式，随着项目方向的改变而改变，而不是强调项目组要坚持按计划行事。 4、 展示你可以在缺少正式的规格说明书的情况下也能工作，当你需要的时候寻找更多的信息并在需要的时候自己主动记录下关键的信息。
有趣的是，这些不仅仅是测试员提供给XP项目组的价值标准，同时也是探索性测试的组成部分。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
