问如何在两周内计划手动和自动化测试？

EN

里面有几个问题要解答。

首先，什么时候开始测试2周的冲刺:尽快.许多经验丰富的Scrum团队专注于在转移到其他项目之前将一到两个待办事项转移到可测试状态，以便测试人员能够在这些项目上工作。这会在测试过程中创造出更好的工作流程，这样就不会在最后堆积起来。

或者，先进行测试:甚至还有一些技术，比如测试驱动开发和行为驱动开发，在编写任何代码之前编写失败的测试。这要求开发人员、测试人员、PO和涉众非常紧密地一起工作，并不断地集成这两个活动。在这两种情况下，您每次只接受一个测试用例，开发到该测试用例，然后转移到下一个测试用例。TDD集中在代码级别，由单元测试驱动，测试和开发的平均周期通常以分钟为单位。BDD级别更高，可能更像您正在考虑的测试，但即使有了这些测试用例，定义和解决每个测试用例的完整周期也很少超过几个小时。

至于自动化和手动，我最好的经验是对待它们的方法是一样的。我可以定义一个测试场景，然后如果它是我想要反复测试的东西，在开发过程中自动化它。否则，把它放在手册上。对于大多数团队来说，这为测试自动化打开了更多的选项。当QA工程师不得不在事后自动化测试时，他们经常被困在自动黑匣子测试中。当您在开发期间自动化时，开发人员可以帮助将钩子创建到不同级别的代码中，测试行为非常接近源代码，而不必从三个级别对其进行测试，从而导致更有效和更不脆弱的测试。

最后，我对PO的批准很好奇。高级测试-用例通常与验收标准密切相关。事实上，有一种叫做Spec的实践，在这种情况下，两者是相同的。我希望在将待办事项带入sprint之前定义并商定任何这类测试用例。这并不是说在探索性测试中有些事情不会出现，但我习惯于看到这些结果在走廊上与PO进行快速对话，而不是一个正式的过程。另一方面，与实现本身相关的测试通常是团队的权限，而不是产品所有者。

在你的团队中使用3个朋友。

因此，基本上在sprint开始时，产品负责人、开发人员和测试人员坐下来讨论正在开发的系统应该做的用户故事。产品负责人描述用户故事。开发人员和Tester提出问题(并提出建议)，直到他们认为他们可以回答基本的问题，“我怎么知道这个故事已经完成了？”不管是怎么做的，或者什么时候做的，这三个朋友都必须在这个基本的标准上达成一致，否则事情就会出错。将此协议转换为自动验收测试(或三次)可以使其精确到经常测试协议，并在我们使用的词语中揭示出模糊性或相互冲突的定义。

如果您的测试完全是手动执行的，那么您就会遇到问题，测试人员必须等到开发人员认为他们完成之后才能开始验证功能。这从一开始就把测试人员放在了后面。当功能不像预期的那样运行，并在被认为是完整的代码上导致错误修复周期时，它也会延迟反馈给开发人员。这些因素结合在一起，减缓了发展速度。

当代码还在编写时，自动化这些测试就更有价值了。随着开发的进行，您可以看到这些测试开始通过，提供了进度的明确指示。如果开发人员编写的代码可以使特定的测试场景正常工作，但是测试失败了，那么您可以立即深入研究这个问题。在代码中、测试中是否有错误，或者仅仅是对我们打算做的事情有一个长期的分歧？

自动验收测试表达了应用程序中功能的增长。这样，您还模糊了手动测试和自动测试之间的界限。

除此之外，您还可以根据需要对边缘执行额外的探索性手动测试。

来源：http://blog.gdinwiddie.com/2009/06/17/if-you-dont-automate-acceptance-tests/

你迟到了。在提交测试供评审之前，您应该已经开始测试自动化。实际上，您不应该提交测试以供评审，因为您的测试应该建立在产品所有者在开始实现该特性之前提供的验收标准之上。

我认为，在两周的迭代中自动化测试的最有效的方法是开始使用BDD方法，就像您为每个特定的验收标准引入BDD“包装器”一样，除非您已经设置了该包装器，否则不会考虑所做的功能。因此，核心声明是，您只在所描述的验收标准级别上进行自动化操作。除非您获得了一个在BDD中实现的良好的业务操作库，否则您正在进行的所有其他测试都是手动的。