测试人员的新思想
过去，我们注意到按照传统的方法，当项目快要结束时，开发出来的软件才被交给测试人员，让测试人员通过找到软件的缺陷来为软件“注入质量”。每一个测试人员都可能会退缩，因为通过经验他们知道这种方法是多么没有效率和令人失望的。
使用迭代的开发方法，测试人员仍然要负责确定系统的质量是否足以发布，但是他们确保完成高质量系统的方法却从根本上发生了变化。首先，测试人员在项目非常早的时候就参与其中，因为每一个迭代（可能除了第一个迭代）都会产生可以被立即测试的可执行的结果。在项目早期，测试更关注找到“影响大的”问题，而不是验证代码是不是已经可以交付了。这就意味着你不能简单的将代码交给测试人员；相反，测试人员需要与分析人员和开发人员密切的合作以便他们能够理解在每个迭代中什么是需要被测试的。
此外，测试人员必须向 团队的其他能够适当的改经需求、设计、代码和其他支持性的产物的成员提供测试的反馈。测试人员可以通过这些任务来帮助其他项目成员的工作：通常他们可以帮助产生更好的需求，因为他们在计划方法来测量一个需求是否被满足的方面是经过训练的。同时，现代的集成测试和开发环境允许他们通过使用基线的代码配置进行连续的测试工作。
就像分析人员和开发人员承担了更多的任务一样，测试人员也承担起了更多的任务。在项目周期的后期，测试人员作为质量专家，对整个开发团队提供专家意见。例如，除了执行大量了集成和验收测试之外，他们可以在质量的相关决定上对 项目经理进行指导。
因为贯穿整个项目中需求是被迭代的识别、细化、开发和测试的，因此项目团队并不应该过早的生成所有被执行的测试的详细说明。相反，早期的焦点应该是理解对于一定的阶段或者迭代的测试的目标 — 他们应该完成什么。这将焦点移到了识别每个迭代的潜在的问题领域上，并且开发测试以暴露那些问题领域。
迭代开发意味着在项目的早期你就要开发测试系统的关键能力。同时也意味着你需要在后续的迭代中测试和重新测试这些能力以确保你认为应该被解决的问题不会再一次出现。不通过有效的自动化测试进行完全的回归测试是不切合实际的 — 而且通常是不可能的，因此你必须要在整个项目中不断的开发出可自动化的测试。有效的实现这一点的诀窍是理解在迭代不断持续时什么元素是可以保持稳定的；通过这种方法，你可以避免为每一个迭代重写自动化测试。这就要求你对系统的体系架构有一定的了解；在比较靠后的迭代中，测试应该更注重系统详细的功能性。
文章来源于领测软件测试网 https://www.ltesting.net/
