While you mention Scrum, a good management practice, you don't describe which testing practice you're using.
If you're using best practices, you should be using Test-Driven Development.
Test-Driven Development means that the testing must be done from the very beginning. The programmers must write tests and fill in classes that pass those tests.
The tester should be writing functional tests on day 1 which the application absolutely fails to pass on day 1. Eventually the application starts to pass those tests and you can call your sprint done.
If you're not doing test-driven development, you should be, and your tester should be writing integration test cases.
If your tester can't code, teach them to code. You must have a tester who can code. And make them start coding functional tests on day 1.
A tester could be going through the spec and writing test scripts / acceptance criteria steps.
As a dev is coming up to completing a task but before check-in they can also do mini test reviews, ie a 5 minute eye ball with the developer as they are completing the work can often turn up a few bugs.
There is always testing the existing application (assuming this isnt the very first sprint of a new product) theres always bugs to find.
Then there is triage of existing bugs, are they high or low priority.
Then there is the testing and closing of bugs that developers have fixed.
Of course the most important is making coffee and wiping the fevered brow of any developer who puts his hand up.
You have uncovered a problem with your Product Backlog. If you have 3 devs coding for 3 days with no testable/releasable code then your stories are too big. You should notice this reflect this fact on your burndown; flatline->big drop at end of sprint. Integration should be a daily routine with new functionality always available for testing.
发布评论
评论（5）
当您提到 Scrum 这一良好的管理实践时，您没有描述您正在使用哪种测试实践。
如果您使用最佳实践，则应该使用测试驱动开发。
测试驱动开发意味着测试必须从一开始就进行。程序员必须编写测试并填写通过这些测试的类。
测试人员应该在第一天编写功能测试，而应用程序在第一天绝对无法通过。最终，应用程序开始通过这些测试，您可以称您的冲刺已完成。
如果您没有进行测试驱动开发，那么您应该这样做，并且您的测试人员应该编写集成测试用例。
如果您的测试人员不会编码，请教他们编码。您必须有一个会编码的测试人员。并让他们在第一天开始编写功能测试代码。
While you mention Scrum, a good management practice, you don't describe which testing practice you're using.
If you're using best practices, you should be using Test-Driven Development.
Test-Driven Development means that the testing must be done from the very beginning. The programmers must write tests and fill in classes that pass those tests.
The tester should be writing functional tests on day 1 which the application absolutely fails to pass on day 1. Eventually the application starts to pass those tests and you can call your sprint done.
If you're not doing test-driven development, you should be, and your tester should be writing integration test cases.
If your tester can't code, teach them to code. You must have a tester who can code. And make them start coding functional tests on day 1.
测试人员可以仔细检查规范并编写测试脚本/验收标准步骤。
当开发人员即将完成一项任务时，但在签入之前，他们还可以进行小型测试审查，即在开发人员完成工作时与开发人员进行 5 分钟的观察，通常会发现一些错误。
总是要测试现有的应用程序（假设这不是新产品的第一个冲刺），总是会发现错误。
然后对现有错误进行分类，确定它们的优先级是高还是低。
然后是测试和关闭开发人员已修复的错误。
当然，最重要的是煮咖啡并擦拭任何举手的开发人员发烧的额头。
A tester could be going through the spec and writing test scripts / acceptance criteria steps.
As a dev is coming up to completing a task but before check-in they can also do mini test reviews, ie a 5 minute eye ball with the developer as they are completing the work can often turn up a few bugs.
There is always testing the existing application (assuming this isnt the very first sprint of a new product) theres always bugs to find.
Then there is triage of existing bugs, are they high or low priority.
Then there is the testing and closing of bugs that developers have fixed.
Of course the most important is making coffee and wiping the fevered brow of any developer who puts his hand up.
您发现产品待办事项列表存在问题。如果您有 3 个开发人员编码了 3 天，但没有可测试/可发布的代码，那么您的故事就太大了。您应该注意到这反映了您的倦怠情况；平线->冲刺结束时大幅下降。集成应该成为日常工作，新功能始终可供测试。
You have uncovered a problem with your Product Backlog. If you have 3 devs coding for 3 days with no testable/releasable code then your stories are too big. You should notice this reflect this fact on your burndown; flatline->big drop at end of sprint. Integration should be a daily routine with new functionality always available for testing.
我同意以上观点。当您为春季选择用户故事时，您应该开始定义如何测试它们
I agree with the above. When you choose your user stories for the spring, you should start defining how they will be tested
怎么样：
自动执行上一个冲刺中手动测试的一些故事测试
自动设置测试数据（和/或机器），以便更快地进行下一轮回归测试。
为一些故事编写测试规范，以便开发人员在开始制作这些故事时获得更好的信息。
How about:
Automate some of the story tests from the last sprint that were tested by hand
Automate the setting up of the test data (and/or machines), so that it is quicker to do the next round of regression tests.
Write the test specs for some of the stories, so that the developers have better information when they get to do those stories.