现在我的问题是，何时开始手动测试以及如何（可能基于我们的手动测试用例）。和自动化一样。
还如何确定，哪个测试用例需要自动化，哪个测试用例需要手动测试？
#1 楼
有几个问题需要解决。首先，何时开始进行为期2周的冲刺测试：尽快。许多经验丰富的Scrum团队专注于将一个或两个积压项目转换为可测试状态，然后再进行其他测试，以便测试人员可以进行处理。这样可以通过测试创建更好的工作流程，从而使最终不会全部堆积。
或者，首先进行测试：甚至还有诸如测试驱动开发和行为驱动开发之类的技术，您在编写任何代码之前先编写失败的测试。这就要求开发人员，测试人员，采购订单和利益相关者紧密合作，并不断整合这两项活动。在这两种情况下，您一次都使用一个测试用例，发展为该测试用例，然后再移至下一个。 TDD专注于代码级别，由单元测试驱动，测试和开发的平均周期通常以分钟为单位。 BDD是更高级别的，可能更像您正在考虑的测试，但是即使有了这些，定义和解决每个测试用例的整个周期也很少超过几个小时。
手册，我的最佳经验是对待他们的方法相同。我可以定义一个测试场景，然后如果我想重复测试它，请在开发过程中使其自动化。否则，请保留手册。对于大多数团队来说，这为测试自动化打开了更多选择。事后，如果质量检查工程师必须自动化测试，他们通常会被困在进行自动化黑盒测试的过程中。当您在开发过程中实现自动化时，开发人员可以帮助在不同级别的代码中创建钩子，非常接近其源代码测试行为，而不必从三个级别进行测试，从而使测试更有效，更不脆弱。
最后，我对PO批准感到好奇。高级测试用例通常与验收标准密切相关。实际上，有一种名为Spec by Example的实践，其中两者是同一件事。我希望在将待办事项放入冲刺之前，已定义并同意所有这些类型的测试用例。这并不是说在探索性测试中不会出现某些问题，但是我已经习惯于看到这些结果导致与PO进行快速的走廊对话，而不是正式的过程。另一方面，与实现本身相关的测试通常是团队的职责，而不是产品所有者的职责。
#2 楼
在您的团队中使用3个好友。因此，基本上在冲刺开始时，产品负责人，开发人员和测试人员坐下来谈论用户开发系统应该做的故事。产品负责人描述了用户故事。
开发人员和测试人员提出问题（并提出建议），直到
他们认为他们可以回答基本问题，“我怎么知道这个故事已经完成？”
无论如何或何时完成，这三个朋友必须对此基本标准达成共识。否则，事情将会出错。将此协议转换为一个自动接受测试（或三个），可以使其具有经常测试该协议并发现用词模糊不清或冲突定义的精度。
如果您的测试是完全手动执行的，那么您将遇到问题，即测试人员必须等到开发人员认为完成之后才能开始验证功能。这使测试人员从一开始就落后了。当该功能无法正常运行时，还会延迟对开发人员的反馈，并导致认为代码完整的错误修复周期。这些事情结合在一起会减慢开发速度。
在仍编写代码的同时使这些测试自动化的价值更高。随着开发的进行，您可以看到这些测试开始通过，从而清楚地指示了进度。如果开发人员编写了预期可以使特定测试方案正常工作的代码，但是测试失败，那么您可以立即深入研究问题。代码，测试中是否有错误，还是对我们打算做的事情存有持久的分歧？
自动验收测试表达了我们应用程序中功能的增长。
这样，您还可以模糊手动测试和自动测试之间的界限。
除此之外，您还可以根据需要始终在边缘周围执行其他探索性手动测试。
来源：http：//blog.gdinwiddie.com/2009/06/17/if-you-dont-自动化验收测试/
#3 楼
你迟到了。在提交测试以进行检查之前，您应该已经开始测试自动化。实际上，您不应该提交测试以进行审查，因为您的测试应该在开始实施功能之前根据产品所有者提供的接受标准进行构建。我相信，在两周的迭代中自动执行测试的最有效方法是开始使用BDD方法，就像您要为每个特定的接受标准引入BDD“包装器”一样，而不考虑已完成的功能除非您有该包装。因此，核心声明是您只能在描述接受标准的水平上进行自动化。除非您获得在BDD中实现的良好的业务操作库，否则您将手动执行所有其他测试。