本文主要是介绍随着敏捷的发展，Tester将会被淘汰吗？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
我们常常听到这样的描述：“在敏捷中，不区分任何角色，只有开发团队，团队中的任何人都可以做任何事，当然，这也包括开发人员做测试。”也经常听到这样的说法：“随着敏捷的发展，在不久将来的某一天，项目中将不再有测试人员。”而我们实际的敏捷项目中，也有些项目的确是没有专业的测试人员，开发人员在承担开发工作的同时，也承担测试工作。在敏捷时代，开发人员也可以编写测试代码，似乎测试人员真的可有可无。但，这是不是我们对敏捷的一种误解呢？
在敏捷开发团队中，的确是鼓励团队中的成员参与多个开发活动、承担多种类型的开发任务（包括需求分析、设计、编码和测试等）。一些敏捷先驱不鼓励在开发团队中指定角色，比如明确划分需求分析人员、开发人员、测试人员、 DBA等角色，但是，这个团队中必须有具备这些能力的专业人才。也正是因为这样，很多人都觉得敏捷中就是应该不分角色，也有很多敏捷开发团队中，都没有专业的测试人员，而是由开发人员承担测试任务。我们的项目也曾是这样的运作模式。
然而，随着敏捷的发展日趋成熟和这种开发模式的问题的暴露，一些敏捷团队在敏捷实践的过程中也引进专业的测试人员，而这些团队的敏捷的经验和经历也证明，测试技能和经验对项目的成功至关重要，测试人员也增加了敏捷团队的价值。
但这并不意味着敏捷团队的所有测试活动都是由测试人员来承担，敏捷测试和传统测试其中一个重要区别是“ Whole Team Approach”，在敏捷中不单单是测试人员对团队的质量做保证，而是由这个团队的所有人员一起承担。这意味着所有人都必须对测试负责，由团队的所有成员一起完成这个团队的测试任务，而不仅仅是测试人员单纯地做测试。同时，也意味着，团队在开发设计的时候，必须考虑到测试，设计具有可测试性的框架和代码。这是我非常喜欢的敏捷思想。
我们对比一下传统的测试，开发团队在完成编码工作后就直接 Deliver到测试团队测试，由测试团队对软件的质量把关。在传统的开发模式中，开发团队在设计和实现的时候，很少会考虑到软件的可测试性，这给自动化测试带来一定的困难。而测试团队写好的自动化测试用例，也很可能会因为开发改了代码而导致测试用例运行失败，测试团队需要花很多的时间和精力才可以找到什么改动对测试用例带来的影响。但是，如果由敏捷团队的所有人员一起对软件的质量负责，团队中的测试人员和开发人员紧密合作，这些问题也将迎刃而解。
敏捷测试和传统测试的另一个重要区别是持续地增量测试，测试人员和开发人员紧密地工作在一起，当某个 user story完成编码后马上投入测试，只有编码和测试工作都完成，这个 user story才算 ”Done”。在敏捷中，并不鼓励开发了一大堆 User Story然后再集中式地测试。相应地，敏捷中的测试人员，也并不是一直在等到有测试工作了才有事情做，而主动地承担了测试相关的或测试以外的其它工作，协助团队顺利交互最大价值的产品。
事实上，在敏捷中，测试人员的确起着非常重要的作用。很多敏捷团队的测试人员参与客户团队的需求分析工作，不但帮助激发更完善的客户需求，并且帮助客户用测试的形式来描述需求，这将作为开发的输入和客户验收的依据。同时，作为开发团队的一分子，测试人员会协助开发团队更完善更准确地实现需求，使开发团队交互最大价值化的产品。测试人员是需求和实现的桥梁。
在敏捷开发团队，传统的角色需要转型，测试也不例外，纯粹的手工测试、任务式地完成测试工作的时代不再。敏捷不是不需要测试人员，而是需要具有更全面技能的测试人员，测试人员必须提高自己的能力，需求分析的能力、探索性测试的能力、测试编码的能力、全局把握的能力和沟通协调的能力，这些能力对测试人员在贯穿整个开发周期的过程中帮助开发团队交付更有价值的产品。
这篇关于随着敏捷的发展，Tester将会被淘汰吗？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
