Lam是一位资深的敏捷测试专家，他最近撰文分析了测试人员在敏捷过程中的挑战，指出现在许多敏捷实践忽视了测试人员的处境和压力，并提出了自己的一些解决办法。他说，Agile宣言已经诞生十多年了，从那时起，越来越多的开发人员投入到敏捷的怀抱，如今，敏捷方法已经主宰了软件开发领域，从而取代了瀑布式方法的领导地位。但是在实现敏捷的过程当中，有一些人被忽视了——测试人员。关注于交付高质量产品、无需太多的文档记录，对于开发人员来说是一种积极的转变。通过时刻谨记最终用户的需求、积极地建立用户反馈过程，项目通常会交付更快更好地交付软件。有时候开发人员会以为敏捷方法就是针对开发者自身的，从而忽视了测试人员。正如敏捷指南所说的，敏捷团队必须邀请测试人员参与。

Vu表示，很显然，敏捷软件模式会完全地颠覆传统测试实践，但是很多公司在帮助测试人员处理这些新挑战方面无动于衷。他举了一个例子：

假设一个典型的敏捷团队，由五位开发人员和两位测试人员组成。从开发的角度来看，五位开发人员能够以一种稳定、可衡量的速度工作，在新版本中加入新特性。但是对于测试人员来说，事情没有这么简单。

起初，测试每一个冲刺（Sprint）不是问题，因为此时测试人员面对的特性数量有限，并不多。但是随着开发过程前进，测试人员需要测试新特性、验证bug修复，同时还要执行回归测试。一切都要在单个冲刺中测试完毕。冲刺周期越短，回归测试的次数就越多。很多，测试团队就不堪重负了。

自动化单元测试可以提高代码的质量，缓解测试人员的压力，但是他们的负担还是很重。两位测试人员如何同时测试所有新特性同时还做验证和回归测试？答案就是No。

为了确保高质量的产品，Vu指出，管理层可能会考虑随着开发进度扩大测试团队的规模，但是还有其他更有效率的解决方案。回归测试可以做文档记录并且自动化。在代码交付之前，测试人员是无法完成这些测试用例和脚本的。新功能测试和Bug验证是测试人员应该重点关注的地方。

对于敏捷测试来说，Vu表示，测试人员需要和开发人员一样采纳相同的敏捷思想，但是抛弃传统的瀑布式过程需要引入一些规划。在敏捷之前，测试人员的工作包括阅读和理解用户需求，编写测试用例，然后测试软件。对于敏捷项目来说，测试人员无法在构建产生之前完成测试用例，因为需求不是很详细。

因此，测试人员必须做出改变——利用探索性测试来处理新功能，同时编写一定数量的核心测试用例用于以后的回归测试，并且尽早自动化。

Vu建议，因为缺乏详细的需求和文档，敏捷模式下的测试人员必须尽量理解最终用户的需求，这包括了解他们需求什么和如何使用软件。这意味着测试人员需要参加Scrum会议、研究用户故事、提出问题。理想情况下，测试人员应该是最终用户的代言人。

测试人员需要具备怎样的敏捷思想？测试专家Janet在“敏捷测试指南”一书中对敏捷测试思想做了详细的描述。

如何使一个团队变得“敏捷”？对我们而言，敏捷团队持续关注如何最出色地工作并发布最优秀的产品。根据我们的经验，这需要大量的训练、学习、时间、实验和协同工作。这并不适合所有人，但是对那些希望自己团队充满活力并关注持续改进的人来说非常适合。成功的项目总是因为优秀的人才完成了出色的工作。在敏捷团队中做一名成功的测试人员所需要的特质可能与在任何团队做一名高水平的测试人员所需要的相同。

敏捷测试人员不会把自己看作是质量管理办公室的主管以保护客户避免受到缺陷代码的伤害。她会乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自己的需求，从而得到他们需要的功能，同时向所有人提供项目进展的反馈。

正如Janet所述，敏捷测试人员，可能包括其他拥有正确技能和思想的测试人员，都在不断想办法使团队能够更好地生产高质量的软件。对个人来说，这可能意味着需要出席本地用户组会议或者圆桌会议看看其他团队在做什么，同时寻找新的工具以帮助团队通过测试描述、执行和自动化用户需求。基本要求就是敏捷测试人员和其他敏捷团队成员一样，乐于学习新技能和面对新挑战，不会仅仅局限于测试问题。这不只是测试人员的特征，所有敏捷团队人员都具有。敏捷测试人员帮助开发人员和客户团队解决可能出现的任何问题。测试人员提供信息以帮助团队回顾和了解哪些方案有效、哪些无效。创造力、接受新思想、乐于承担任何任务或角色、重视客户和持续关注全局只是敏捷测试思想的组成部分。优秀的测试人员都有一种直觉和理解力：软件可能在何处失败？如何定位失败？测试人员可能在测试领域拥有特殊的技能和经验，但是一名优秀的测试人员并不惧怕参与一场设计讨论，提供有助于测试性或者构建更良好方案的建议。敏捷测试思想是面向结果的、技术性的、协作的、乐于学习的、勇于不断生产业务价值的。