极限编程敏捷环境中的QA

Question

我以前在敏捷环境中做过QA，但现在我发现自己在一家对T进行极端编程的公司工作，我想知道你们认为一个有点传统的测试人员可能适合这样的环境或开发周期。特别是，这里的所有开发人员都在迭代TDD，编写自己的自动化测试，并在完成后立即提交到他们的CI。

我希望有人能为我提供一些关于这个问题的文献，或者分享他们的一些经验。

Answer 1

简短的版本:不管开发方法如何，您的角色都是提供有关应用程序总体质量的信息。您可以通过测试不包含在开发人员维护的自动化中的任何内容，以及检查开发人员维护的自动化来实现这一点。

长篇版本：这个问题及其答案是一个很好的起点。除此之外，您还可以在这个环境中进行测试，有几个方向：

• 测试需求/用户案例/用例--不管需求文档被称为什么，开发团队都在研究如何构建，以及用户接受测试是什么。您的部分角色是与应用程序的其他部分一起在上下文中检查这些内容，并查找隐藏的假设、遗漏或无效的条件以及其他类似的情况。对于大型、复杂的产品，这意味着您将需要大量关于该产品和客户/用户基础的知识。
• 测试测试--如果您有任何自动化方面的经验，请检查开发自动化代码，看看有什么遗漏了。即使在拥有最好的开发人员的最佳环境中，也会错过一些东西。在一个大型，复杂的产品，这是一个保证，某些条件将被忽视。
• 测试用户界面-没有任何自动化工具可以替代与应用程序交互的智能人员，并找到尴尬、丑陋或完全违背直觉的地方。如果你真的想玩得开心，你可以在这里玩角色，模仿不同的用户配置(包括意想不到的用户档案，比如首席执行官无聊的3岁，他喜欢漂亮的照片和手电筒)。在这里，您还可以发现表单字段是否受到了保护，不受非逻辑输入(负年龄等)、交叉验证(生日比雇用日期晚、配置永远不可能发生的待售期、能够配置与您已经选择的内容不兼容的设置等等)。
• 测试端到端的处理--几乎可以保证完整的流程是在单独的切片中开发的。如果开发人员在构建过程中没有考虑到完整的流程，那么就会有空白(无论如何，可能会有缺口)。

Answer 2

听起来他们可能在寻找更多的测试分析师。

您拥有知道应该执行哪些测试的专业知识，即使您没有亲自编写测试，而且至关重要的是，您应该知道哪些测试不能自动化，哪些测试不应该自动化。

Answer 3

我们的软件供应商之一在这个庄园工作，但我们仍然发现39个错误，当测试他们的最新交付。

马克·史密斯。