我在一个团队，一直在做传统的发展瀑布方法工作多年。 最近，我们已经被告知，未来的项目将要实现敏捷（Scrum的特别）方法移动。 恰巧，我的项目将是第一个，所以我们基本上将豚鼠在未来数个月内，以消除如何才能使过渡。
该项目本身就是一个非常早期的阶段，我们通常会从释放什么测试团队多月了，但现在我们将直接与他们合作了前面。 其结果是，我很担心，以测试者的这样一个项目，在这个阶段中的作用。 我有几个问题/顾虑其希望一些有经验的敏捷开发者可以回答：
如何将传统的测试团队成员在敏捷项目中发挥作用？
保持忙碌的测试人员往往作为一个项目成熟时变得更加容易（还有更多的考验！），但以下几点在早期阶段也适用：
测试人员可以（或同时）它们在付诸实施前准备他们的测试计划，测试用例，并为用户故事自动化测试。 这可以帮助团队发现在用户故事任何不一致或含糊不清甚至在开发人员编写任何代码。
在我个人的经验，测试人员不用在单元测试中有任何牵连; 它们唯一的测试代码，通过了所有的自动化单元，集成和验收测试，其全部由开发者编写的。 这种分裂可以是不同的其它地方，虽然; 例如您的测试人员可以编写自动化验收测试。 单元测试真的应该由开发商然而写，因为它们都写在代码的串联。
他们的工作量将冲刺之间有所不同，但回归测试仍需要对这些变化运行...
你也可能会发现有测试人员花费了第一对夫妇每个冲刺从以前的冲刺可以帮助测试任务的天，但是我觉得这是更好地让他们明确，开发商要通过合作的事情写自己的测试计划。
理想的情况是QA和测试人员应该参与如果不从一个，那一天从一个软件开发项目的早期阶段，无论使用（瀑布或敏捷）的过程中。 测试团队将需要：
确保项目或冲刺的要求是明确的，可衡量和测试。 在一个理想的世界每一个需求将在这个阶段写下一个合适的标准。 确定需要什么样的信息被自动记录到解决任何缺陷。
准备一个项目的具体测试策略，并确定将要需要QA步骤，并在该项目阶段：整合，压力，兼容性，渗透，一致性，可用性，性能，beta测试等确定可接受的缺陷阈值和制定分级制度缺陷严重程度，指定缺陷报告准则。
指定，安排和准备测试环境：测试基础设施和模拟服务作为必要的; 获得，消毒和准备测试数据; 编写脚本在必要时快速刷新测试环境。 建立缺陷跟踪，通信和分辨率过程; 招聘或招聘为用户测试，可用性或验收测试做准备。
提供所有相关信息，形成项目进度，工作分解结构和资源计划。
编写测试脚本。
使自己达到这个问题域，系统AS-IS和建议的解决方案，以加速。
通常，这是不是一个测试团队是否会提供任何有用的投入在早期项目中的问题，也不如果这种输入是有益的。 这是一个问题，然而，一个组织可以得到上述活动的程度。 总是有关可用时间，预算与最终结果已知质量水平之间和资源贸易。
好的职位。 我大约3年前，在同样的情况，并从瀑布到敏捷的过渡是棘手。 我中招遇到了很多的痛点，但一旦我克服了它们，我的角色发生了变化，我意识到，这种工作方式很适合测试。
不需要的测试人员共同的神话是很容易消除。
1.尽管显影剂被编码的任务时，这是不可能的测试器进行测试（它还不存在）。 那么，什么是一个测试仪在这一点上的作用
在我的经验，测试仪可以与客户合作，以微调在冲刺的故事。
它们通常与开发商合作，以微调它们提供的代码。 即在边缘情况咨询，流动，错误等
他们往往可以参与设计，该编码器将写入执行TDD测试。
如果敏捷团队是相当先进的，则测试仪通常会被写入ATDD（验收测试驱动开发）的测试。 这可能是在为FitNesse的这样一个工具或机器人框架或他们可能是更高级的宝石的测试，甚至一些其他的编程语言。 在某些情况下，简单的记录和回放往往是为少数的测试是有益的。
他们显然被编写测试和规划一些探索性的测试方案或想法。
有时理解为球队棘手的是，这个故事并不一定是完整的，以便将其拖放到测试组进行测试。 例如，程序员可以拖放屏幕，计划在它的领域的一半。 而另一半则是在早期的测试结果被编码，因此反馈测试仪可以测试这个一半。 测试并不一定发生在“已完成”的故事。
2.是否测试仪现在从事单元测试？ 这是做平行于黑盒测试？
理想情况下，编码器将做TDD。 编写测试，然后编写代码来使测试通过。 而如果编码器是想真正的好TDD那么他们将与测试仪liasing想出测试。
如果没有正在做TDD则编码器应在同一时间编码编写单元测试。 这可能是一个思想后或任务后，该软件已被删除后不应该。 测试整点是对软件进行测试是正确的，以避免日后浪费时间下来就行了。 这是所有关于即时反馈。
3.什么是测试人员，其中主要的基础设施已经作了修改冲刺，那可能只是在单元测试检验的过程中呢？
理想情况下，测试者将与团队和客户一起工作（谁的方式，是团队的一部分！）来定义计划的故事和建立一些好的，详细的验收条件而定。 这是非常宝贵的，可以节省大量的时间晚了线。 该测试仪还可以学习新的自动化技术，规划测试环境，帮助文件规划的结果。
理想的情况是在冲刺每个故事会以某种方式，形状或形式测试。 这并不意味着它应该是由测试团队，而应是可检验的。 所以测试人员可以与团队的其他成员一起工作制定出如何确保故事的可测试性。
我在这里发表一些敏捷提示： http://thesocialtester.posterous.com/
希望这可以帮助你抢..
只是一些想法，肯定是不完整的：
虽然开发商的编码任务，测试人员可以检查规范（从客户或要求，如果没有正式的规范），以及编写测试计划。 这可以包括需要测试什么的概念框架，但它也应该包括正式写测试套件（是的，在代码中）为好。 这对于团队转移到敏捷相当大的挑战，因为很多测试人员都无需编程技能录用。 （在很多地方，现在看来似乎是不能够代码的要求 。）
测试者可以通过测试具有一个干净的界面组件或库参与单元测试，或在稍高的范围。
测试人员应始终执行回归测试，负载测试，以及其他任何类型的，他能想到的测试，以及写作测试套件下一个冲刺。 它通常测试人员奋发进取的发展（在准备测试环境）一个冲刺，以及背后的发展一个冲刺（在测试的内容开发商刚生产）的情况。
我看到了一个很好的谈话最近在此。 基本上，这个团队开始时做了比较规范的Scrum过程，然后过渡到看板和精益。 其中一个他们做的最重要的事情是要逐渐侵蚀测试人员和开发人员之间的区别。 测试者参与了编写单元测试和代码，开发者带来更多更高层次的测试在开发早期。 它是为测试一个陡峭的学习曲线，但是值得的，因为球队正在建设从一开始就质量。 现在的测试者称自己的开发人员，因为他们的工作是如此集成在编写代码的过程。
在我的公司，我们使用和认可敏捷。 我们的QA团队成员都参与了单元测试的创建，维护回归测试的基础设施和，就像在瀑布，他们还完成后，测试每个功能。
在做基础设施的变化，他们也参与，以确保新的基础设施测试。
所以，从我有限的经验，我会尽量回答你两点：
最自然的方法来测试在敏捷环境在我看来是探索性测试http://en.wikipedia.org/wiki/Exploratory_testing 。 听起来不像的话
据塞姆·卡纳和詹姆斯·巴赫，探索性测试更多的是[心态]或“......想测试的方式”比的方法
要么
对测试
听起来很熟悉敏捷developpers。 测试人员可以在过程中更早地参与比传统的测试。
1）尽管显影剂被编码的任务时，这是不可能的测试器进行测试（它还不存在）。 那么，什么是一个测试仪在这一点上的作用
测试者可能仍然创建测试计划，并有一个什么样的测试将创建一个列表。 也可能有需要测试人员得到培训，如果发展涉及到一些现成的，现成的软件，例如，如果你正在做一个Sitecore的CMS项目，然后测试人员应该了解Sitecore的几件事情。 此外，还可以测试人员，开发人员和最终用户或BA的一些合作，知道什么是需求和期望，让没有手指指点，可以在模糊的需求弹出。
2）是测试仪现在参与单元测试？ 这是做平行于黑盒测试？
没有在我们的例子。 该测试仪正在做更多的整合/用户验收测试，而不是低级别单元测试。 在我们的例子中，单元测试，来之前任何QA测试，开发人员创建的功能将创建一个测试的层。
3）什么是测试人员，其中主要的基础设施已经作了修改冲刺，那可能只是在单元测试检验的过程中呢？
回归测试！ 在进行基础设施的变化，没有什么突破？ 一个如何彻底的测试套件可以开发运行相比，QA？ 在不久前，我们在冲刺过这样的，大部分的冲刺工作是水暖返工所以没有太多比看到事情之前的工作还是工作后，测试等。
在我们的例子中，我们测试从我们的开发环境上一级，但仍预生产环境。 我们的想法是让QA冲刺，以验证所做的工作和被发现的任何关键或高严重性错误，并释放到临时最终用户验收测试之前固定的，所以如果开发者在冲刺X工作那么QA是验证冲刺X-1和生产可以根据最终用户验收测试和部署时间表，不是每个冲刺将它投入生产QA给出了确定移动到升级后有冲刺X-2或更早版本的运行。 有配对练习，一旦开发完成的任务的初始编码，以确保两个测试者和最终用户对什么建搁笔，可以发生。 这是我们的努力质量控制融入项目，所以它仍然是一项正在进行的工作已在已经发展了几下第三或第四个版本。
像其他一些受访者都表示，测试人员应该从一开始就参与其中。 在Sprint的零，他们应该参与，确保产品负责人是生产的故事是可测试（例如核查的一次编码）和（当你去，虽然UAT即）“可以接受的”。 一旦产品积压最初填充那么测试人员可以在测试情况下工作的内定为当前冲刺的故事，有一次有一个产品对他们进行测试（理想情况下在某处你的第一个冲刺），然后就可以开始测试。
如果这听起来像绝不会有任何东西来测试一些冲刺，你有你的故事是错误的。 一个Sprint的目的，即使一个早期之一，是有可能的系统的一个薄片。 注重“阿司匹林”（即，如果建立一个药物处方系统，你怎么在2-4周内提供可测试功能？建立一个处方阿司匹林的那些）和“曳光弹”故事（的人，当组合全触控拍摄该体系结构的有风险的份）。 你会惊奇地发现你可以用手在什么测试早期。 如果测试人员做空闲时间结束，让他们结对编程与开发。 它会建立关系和相互尊重。
这种方法的benfits很多，但主要是你考出了很好的协议开发的内部人流程（切换从需求，开发，测试，也是反向），其次是整个团队（中提到的所有三个学科）看到的快速反馈的好处是生产可执行软件的结果。
这听起来不可能的，但我已经看到了它的工作。 只要确保你不要贪太大的块开始。 让自己轻松进入它，你会惊讶。
