There isn't any testing team in Scrum. Its development team which is cross functional. Scrum discourages specialists in the team so as to avoid dependencies. So the role of tester is somewhat different in Scrum than in Waterfall. Its another debate but for now lets stick to the question at hand.
I would suggest you to slice the stories vertically in as smaller the tasks as you can during how part of the sprint planning meeting. Its recommended to break the tasks to as small units so that they can be completed in a day or two.
Define a DoD at the start of the project and keep on refining it. Work on one task at a time and limit work in progress. Work in order of priority and reduce waste in your system. Do not go for detailed upfront planning and delay your best decisions till the least responsible moment. Introduce technical competencies like BDD and Automation.
And remember that the quality is the responsibility of the whole team so don't worry about testing being done by a dedicated person.
1 正如 Mary Poppendieck 所写，测试人员的工作应该是预防缺陷（必要），而不是发现缺陷（浪费） .
In an ideal Scrum team, testers and developers are part of the team and testing should occur in parallel of the development, the phases are overlapping, not sequential (doing things sequentially inside a Sprint is an anti-pattern known as Scrumerfall). And by the way, contrary to some opinions expressed here, an ultimate Scrum implementation produces DONE DONE stories so testing - including IST, UAT - should be done during the Sprint.
And no, testers don't have to wait for Product Backlog Items (PBI) to be fully implemented to start doing their job, they can start writing acceptance tests scenarii, automate them (e.g. with FitNess), set up test data set, etc (this takes some time, especially if the business is complicated) as soon as the Sprint starts.
Of course, this requires very close collaboration and releasing interfaces or UI skeletons early will facilitate the job of testers but, still, testers don't have to wait for a PBI to be fully implemented. And actually, acceptance tests should be used by developers as DONEness indicator ("I know I'm done when acceptance tests are passing")1.
I'm not saying this is easy, but that's what mature (i.e. Lean) Scrum implementations and mature Scrum teams are doing.
You definitely don't want to do all development in the first half of the sprint and all testing in the second half. That's just a smaller waterfall.
Your stories and tasks should be broken up into very small, discrete pieces of functionality. (It may take a while to get used to doing this, especially if the software you're working on is a monolithic beast like a previous job of mine that moved to using scrum.) At the beginning of the sprint the testers are developing their tests and the developers are developing their code, and throughout the sprint the tasks and stories are completed and tested. There should be fairly constant interaction between them.
The end of the sprint may feel a bit hectic while you're getting used to the methodology. Developers will feel burdened while they're working on the rest of the code and at the same time being given bugs to fix by the testers. Testers will grow impatient because they see the end of the sprint looming and there's still code that hasn't been tested. There is a learning curve and it will take some getting used to, the business needs to be aware of this.
It's important that the developers and testers really work together to create their estimates, not just add each other's numbers to form a total. The developers need to be aware that they can't plan on coding new features up until the last minute, because that leaves the testers there over the weekend to do their job in a rush, which will end up falling back on the developers to come in and fix stuff, etc.
Some tasks will need to be re-defined along the way. Some stories will fail at the end of the sprint. It's OK, you'll get it in the next sprint. The planning meeting at the start of each sprint is where those stories/tasks will be defined. Remember to be patient with each other and make sure the business is patient with the change in process. It will pay off in the long run, not in the first sprint.
The sprint doesn't end with perfect code; if there are remaining bugs, they can go in the very next sprint, and some of the other items that would have went in the next sprint will need to be taken out. You're not stopping a sprint with something perfect, but ideally, with something stable.
You are (ironically) applying too much rigor to the process. The whole point of an agile process like scrum is that the schedule is dynamic. After your first sprint, you work with the users/testing team to evaluate the progress. At that point, they will either ask you to change details and features that were delivered in the first sprint, or they will ask you to do more work. It's up to them.
It's only eventually, once you have determined the velocity of the team (ie. how many stories one can reasonably accomplish in a sprint) that you can start estimating dates and things for larger projects
First of all, not every Sprint produces a Big Release (if at all). It is entirely acceptable for the first sprints to produce early prototypes / alpha versions, which are not expected to be bug free, but are still capable of demonstrating something to the client. This something may not even be a feature - it can simply be a skeleton UI, just for the user to see how it will look and work like.
Also, developers themselves can (and usually do) write unit tests, so whatever is delivered in a sprint should be in a fairly stable working state. If a new feature is half baked, the team simply should not deliver it. Big features are supposed to be devided into small enough chunks to fit within a single sprint.
A Scrum team is usually cross-functional, which means that the entire team is responsible for building completed pieces of functionality every Sprint. So if the QA testers did not finish the testing, it only means the Scrum team didn’t finish the testing. Scrum counts on everyone to do their part. Whenever any is needed, the people with those skills take the lead, but they all have to do their part.
Try to do continuous integration. The team should get into this habit and integrate continuously. In addition, having automated unit test suite built and executed after every check-in/delivery should provide certain level of confidence in your code base. This practice will ensure the team has code in working and sane condition at all time. Also it will enable integration and system test early in the sprint.
Defining and creating (automated) acceptance tests will keep people with primary QA/testing skills busy and involved right from the sprint start. Make sure this is done in collaboration with Product Owner(s) so everyone is on the same page and involved.
We started our agile project with developers first (a lot of training in Enterprise Framework, etc.) in the first sprint. Then we added QA slowly into the second sprint. At the end of sprint 2, QA started testing. Closing in on the end of sprint 3 QA had picked up the pace and where more or less alongside the developers. From sprint 4 and out, QA is more or less done with testing when the developers have completed the stories. The items that are usually left to test are big elephants that include replication of data between new and legacy system. And it is more a 'ensure data is OK' rather than actual tests.
We're having some issues with our definition of Done. E.g. we have none. We're working on a completely new version of a system, and now that we are closing in on the end of sprint 6, we are getting ready for deployment to production. Sprint 6 is actually something I would call a small waterfall. We have reduced the number of items to implement to ensure that we have enough time to manage potential new issues that come up. We have a code freeze, and developers will basically start on the next sprint and fix issues in the branch of necessary.
Product Owner is on top of the delivery, so I expect no issues in regards to what we deploy.
I can see that Pascal write about mature sprint teams + the definition of Done. And agile always focus on 'delivery immediately after sprint has reached its end'. However - I'm not sure if there are very many teams in the world actually doing this? We're at least not there yet :)
发布评论
评论（9）
Scrum 中没有任何测试团队。它的开发团队是跨职能的。 Scrum 不鼓励团队中的专家以避免依赖。所以测试人员的角色在 Scrum 中和 Waterfall 中有些不同。这是另一场争论，但现在让我们继续讨论手头的问题。
我建议您在冲刺计划会议期间将故事垂直分割为尽可能小的任务。建议将任务分解为小单元，以便在一两天内完成。
在项目开始时定义国防部并不断完善它。
一次只处理一项任务并限制正在进行的工作。
按优先顺序工作并减少系统中的浪费。
不要进行详细的预先计划，并将最佳决策推迟到最不负责任的时刻。
引入 BDD 和自动化等技术能力。
请记住，质量是整个团队的责任，因此不必担心测试是由专职人员完成的。
There isn't any testing team in Scrum. Its development team which is cross functional. Scrum discourages specialists in the team so as to avoid dependencies. So the role of tester is somewhat different in Scrum than in Waterfall. Its another debate but for now lets stick to the question at hand.
I would suggest you to slice the stories vertically in as smaller the tasks as you can during how part of the sprint planning meeting. Its recommended to break the tasks to as small units so that they can be completed in a day or two.
Define a DoD at the start of the project and keep on refining it.
Work on one task at a time and limit work in progress.
Work in order of priority and reduce waste in your system.
Do not go for detailed upfront planning and delay your best decisions till the least responsible moment.
Introduce technical competencies like BDD and Automation.
And remember that the quality is the responsibility of the whole team so don't worry about testing being done by a dedicated person.
在理想的 Scrum 团队中，测试人员和开发人员是团队的一部分，测试应该与开发并行进行，阶段是重叠的，而不是顺序的（在内部按顺序做事） Sprint 是一种反模式，称为 Scrumerfall）。顺便说一句，与这里表达的一些观点相反，最终的 Scrum 实现会产生“完成”故事，因此测试（包括 IST、UAT）应该在 Sprint 期间完成。
不，测试人员不必等待产品待办事项 (PBI) 完全实施才能开始工作，他们可以开始编写验收测试场景，并将其自动化（例如使用 FitNess）， Sprint一开始就设置测试数据集等（这需要一些时间，特别是业务复杂的时候）。
当然，这需要非常密切的协作，并且尽早发布界面或 UI 框架将有助于测试人员的工作，但测试人员仍然不必等待 PBI 完全实现。实际上，开发人员应该将验收测试用作完成度指标（“当验收测试通过时，我知道我已经完成了”）1。
我并不是说这很容易，但这就是成熟（即精益）Scrum 实施和成熟 Scrum 团队正在做的事情。
我建议阅读 Henrik Kniberg 的 Scrum And XP from the Trenches，这是非常好的实用指南。
1 正如 Mary Poppendieck 所写，测试人员的工作应该是预防缺陷（必要），而不是发现缺陷（浪费） .
In an ideal Scrum team, testers and developers are part of the team and testing should occur in parallel of the development, the phases are overlapping, not sequential (doing things sequentially inside a Sprint is an anti-pattern known as Scrumerfall). And by the way, contrary to some opinions expressed here, an ultimate Scrum implementation produces DONE DONE stories so testing - including IST, UAT - should be done during the Sprint.
And no, testers don't have to wait for Product Backlog Items (PBI) to be fully implemented to start doing their job, they can start writing acceptance tests scenarii, automate them (e.g. with FitNess), set up test data set, etc (this takes some time, especially if the business is complicated) as soon as the Sprint starts.
Of course, this requires very close collaboration and releasing interfaces or UI skeletons early will facilitate the job of testers but, still, testers don't have to wait for a PBI to be fully implemented. And actually, acceptance tests should be used by developers as DONEness indicator ("I know I'm done when acceptance tests are passing")1.
I'm not saying this is easy, but that's what mature (i.e. Lean) Scrum implementations and mature Scrum teams are doing.
I suggest reading Scrum And XP from the Trenches by Henrik Kniberg, this is very good practical guide.
1 As Mary Poppendieck writes, the job of testers should be to prevent defects (essential), not to find defects (waste).
您绝对不想在冲刺的前半部分进行所有开发并在后半部分进行所有测试。那只是一个较小的瀑布。
您的故事和任务应该分解为非常小的、离散的功能块。 （可能需要一段时间才能习惯这样做，特别是如果您正在开发的软件是一个整体野兽，就像我以前的工作转向使用 Scrum 一样。） 在冲刺开始时，测试人员正在开发他们的软件测试和开发人员正在开发他们的代码，并且在整个冲刺中任务和故事都被完成和测试。他们之间应该有相当持续的互动。
当您习惯该方法时，冲刺结束时可能会感觉有点忙碌。开发人员在处理其余代码时会感到负担重，同时测试人员会给出需要修复的错误。测试人员会变得不耐烦，因为他们看到冲刺即将结束，而且仍然有代码尚未经过测试。有一个学习曲线，需要一些时间来适应，企业需要意识到这一点。
重要的是，开发人员和测试人员真正共同努力来创建他们的估计，而不仅仅是将彼此的数字相加形成总数。开发人员需要意识到，直到最后一刻他们才计划编写新功能，因为这会让测试人员在周末匆忙地完成他们的工作，这最终会落在后面的开发人员身上 一些任务需要在此
过程中重新定义。有些故事会在冲刺结束时失败。没关系，你会在下一个冲刺中得到它。每个冲刺开始时的计划会议是定义这些故事/任务的地方。请记住彼此要有耐心，并确保企业对流程的变化有耐心。从长远来看，它会得到回报，而不是在第一个冲刺中。
You definitely don't want to do all development in the first half of the sprint and all testing in the second half. That's just a smaller waterfall.
Your stories and tasks should be broken up into very small, discrete pieces of functionality. (It may take a while to get used to doing this, especially if the software you're working on is a monolithic beast like a previous job of mine that moved to using scrum.) At the beginning of the sprint the testers are developing their tests and the developers are developing their code, and throughout the sprint the tasks and stories are completed and tested. There should be fairly constant interaction between them.
The end of the sprint may feel a bit hectic while you're getting used to the methodology. Developers will feel burdened while they're working on the rest of the code and at the same time being given bugs to fix by the testers. Testers will grow impatient because they see the end of the sprint looming and there's still code that hasn't been tested. There is a learning curve and it will take some getting used to, the business needs to be aware of this.
It's important that the developers and testers really work together to create their estimates, not just add each other's numbers to form a total. The developers need to be aware that they can't plan on coding new features up until the last minute, because that leaves the testers there over the weekend to do their job in a rush, which will end up falling back on the developers to come in and fix stuff, etc.
Some tasks will need to be re-defined along the way. Some stories will fail at the end of the sprint. It's OK, you'll get it in the next sprint. The planning meeting at the start of each sprint is where those stories/tasks will be defined. Remember to be patient with each other and make sure the business is patient with the change in process. It will pay off in the long run, not in the first sprint.
冲刺并不以完美的代码结束；而是以完美的代码结束。如果还有剩余的错误，它们可以进入下一个冲刺，并且需要删除一些本应进入下一个冲刺的其他项目。你不会用完美的东西来停止冲刺，但理想情况下，用稳定的东西来停止冲刺。
The sprint doesn't end with perfect code; if there are remaining bugs, they can go in the very next sprint, and some of the other items that would have went in the next sprint will need to be taken out. You're not stopping a sprint with something perfect, but ideally, with something stable.
（讽刺的是）你对这个过程过于严格了。像 scrum 这样的敏捷流程的要点在于时间表是动态的。第一次冲刺后，您与用户/测试团队合作评估进度。那时，他们要么要求您更改第一个冲刺中交付的细节和功能，要么要求您做更多工作。这取决于他们。
最终，一旦您确定了团队的速度（即一个人可以在一次冲刺中合理完成多少个故事），您就可以开始估计大型项目的日期和事项
You are (ironically) applying too much rigor to the process. The whole point of an agile process like scrum is that the schedule is dynamic. After your first sprint, you work with the users/testing team to evaluate the progress. At that point, they will either ask you to change details and features that were delivered in the first sprint, or they will ask you to do more work. It's up to them.
It's only eventually, once you have determined the velocity of the team (ie. how many stories one can reasonably accomplish in a sprint) that you can start estimating dates and things for larger projects
首先，并不是每个 Sprint 都会产生一个大版本（如果有的话）。第一个冲刺产生早期原型/alpha 版本是完全可以接受的，这些版本预计不会没有错误，但仍然能够向客户展示一些东西。这个东西甚至可能不是一个功能——它可以只是一个 UI 框架，只是为了让用户看到它的外观和工作方式。
此外，开发人员自己可以（通常也确实）编写单元测试，因此冲刺中交付的任何内容都应该处于相当稳定的工作状态。如果一个新功能是半成品，那么团队就不应该交付它。大的功能应该被分成足够小的块以适合单个冲刺。
First of all, not every Sprint produces a Big Release (if at all). It is entirely acceptable for the first sprints to produce early prototypes / alpha versions, which are not expected to be bug free, but are still capable of demonstrating something to the client. This something may not even be a feature - it can simply be a skeleton UI, just for the user to see how it will look and work like.
Also, developers themselves can (and usually do) write unit tests, so whatever is delivered in a sprint should be in a fairly stable working state. If a new feature is half baked, the team simply should not deliver it. Big features are supposed to be devided into small enough chunks to fit within a single sprint.
Scrum 团队通常是跨职能的，这意味着整个团队负责在每个 Sprint 中构建完整的功能。因此，如果 QA 测试人员没有完成测试，则仅意味着 Scrum 团队没有完成测试。 Scrum 依赖每个人尽自己的一份力量。每当需要时，具有这些技能的人都会带头，但他们都必须尽自己的一份力量。
A Scrum team is usually cross-functional, which means that the entire team is responsible for building completed pieces of functionality every Sprint. So if the QA testers did not finish the testing, it only means the Scrum team didn’t finish the testing. Scrum counts on everyone to do their part. Whenever any is needed, the people with those skills take the lead, but they all have to do their part.
尝试做持续集成。团队应该养成这个习惯并不断整合。此外，在每次签入/交付后构建和执行自动化单元测试套件应该可以为您的代码库提供一定程度的信心。这种做法将确保团队的代码始终处于工作和正常状态。它还将在冲刺早期启用集成和系统测试。
定义和创建（自动化）验收测试将使具有主要 QA/测试技能的人员从冲刺一开始就忙碌并参与其中。确保这是与产品负责人合作完成的，以便每个人都在同一页面上并参与其中。
Try to do continuous integration. The team should get into this habit and integrate continuously. In addition, having automated unit test suite built and executed after every check-in/delivery should provide certain level of confidence in your code base. This practice will ensure the team has code in working and sane condition at all time. Also it will enable integration and system test early in the sprint.
Defining and creating (automated) acceptance tests will keep people with primary QA/testing skills busy and involved right from the sprint start. Make sure this is done in collaboration with Product Owner(s) so everyone is on the same page and involved.
我们在第一个冲刺中首先与开发人员一起启动了敏捷项目（进行了大量企业框架培训等）。然后我们慢慢地将 QA 添加到第二个冲刺中。在 sprint 2 结束时，QA 开始测试。冲刺 3 即将结束，QA 已经加快了步伐，并且或多或少与开发人员并肩作战。从 sprint 4 开始，当开发人员完成故事时，QA 或多或少就完成了测试。通常留下来测试的项目是巨大的，包括新系统和旧系统之间的数据复制。它更多的是“确保数据正常”而不是实际测试。
我们对“完成”的定义存在一些问题。例如我们没有。我们正在开发一个全新版本的系统，现在 sprint 6 即将结束，我们正准备部署到生产环境。 Sprint 6 实际上是我所说的小瀑布。我们减少了要实施的项目数量，以确保我们有足够的时间来管理出现的潜在新问题。我们有一个代码冻结，开发人员基本上将开始下一个冲刺并修复必要分支中的问题。
产品负责人负责交付，因此我预计我们的部署不会出现任何问题。
我可以看到帕斯卡写的是成熟的冲刺团队+完成的定义。而敏捷始终关注“冲刺结束后立即交付”。但是 - 我不确定世界上是否有很多团队实际上在这样做？至少我们还没有到那一步:)
We started our agile project with developers first (a lot of training in Enterprise Framework, etc.) in the first sprint. Then we added QA slowly into the second sprint. At the end of sprint 2, QA started testing. Closing in on the end of sprint 3 QA had picked up the pace and where more or less alongside the developers. From sprint 4 and out, QA is more or less done with testing when the developers have completed the stories. The items that are usually left to test are big elephants that include replication of data between new and legacy system. And it is more a 'ensure data is OK' rather than actual tests.
We're having some issues with our definition of Done. E.g. we have none. We're working on a completely new version of a system, and now that we are closing in on the end of sprint 6, we are getting ready for deployment to production. Sprint 6 is actually something I would call a small waterfall. We have reduced the number of items to implement to ensure that we have enough time to manage potential new issues that come up. We have a code freeze, and developers will basically start on the next sprint and fix issues in the branch of necessary.
Product Owner is on top of the delivery, so I expect no issues in regards to what we deploy.
I can see that Pascal write about mature sprint teams + the definition of Done. And agile always focus on 'delivery immediately after sprint has reached its end'. However - I'm not sure if there are very many teams in the world actually doing this? We're at least not there yet :)