敏捷测试者对传统测试者.？

Question

传统的手工测试人员在基于瀑布的项目中工作的角色与在基于敏捷的项目中工作的敏捷测试人员的角色有什么不同？

我的项目已经开始遵循敏捷实践，但我不知道，作为QA/Tester，我是否应该改变我的工作风格或方法？我现在该怎么做？

我应该改变设计测试用例的方式，执行测试用例还是发现bug？我应该做更多的探索性测试还是使用新技术？我糊涂了！

帮帮忙吧。谢谢!

Answer 1

我建议您首先看看一些相关的问题及其答案，特别是这一个和这一个。

另外，如果你没有克里斯平和格雷戈里的敏捷测试，那就去拿吧。

我发现一些有用的东西包括：

• 测试计划仍然会发生--但它们往往更轻量级，并且在测试时构建。有些工具对此的支持要好于其他工具。
• 测试用例也变得更轻:如果您已经在详细的“单击此链接，输入文本，单击此按钮”级别创建测试用例，则可以(谢天谢地！)别再这么做了，多看看更轻盈的风格。
• 一般来说，测试用例来自用户故事和验收测试:例如，验收测试可能是“作为登录用户，当我导航到订单管理页面时，我希望看到我的所有订单及其当前状态的列表”。这可能会产生一些类似于以下内容的测试用例：
  • 如果用户已登录，则主页上有指向订单管理页的链接。
  • 如果用户未登录，则没有指向订单管理页面的链接。
  • “订单管理”页面列出了登录用户的所有订单，按日期从最近的到最旧的排序，并显示每个订单的状态。

• 如果您的团队正在创建单元测试，您应该熟悉他们正在测试的内容，因为这简化了您的测试:良好的单元测试将涵盖业务逻辑，并允许您的手动测试集中在端到端的场景上。
• 首先测试快乐路径/钢丝绳。这是满足用户故事/验收测试/用例所必需的最低功能。
• 探索性测试会议应该有文档化和时间限制(“花一个小时探索订单管理页面的行为”)。
• 通常，不报告正式意义上的问题会更容易，特别是如果您的团队没有在迭代中运行一个迷你瀑布--我的方法是在我发现一些奇怪的事情时，向开发人员检查，如果他们已经在处理这个问题，或者他们可以在一天内对我进行修复，这就是所发生的一切。只有在一天内无法得到修复的情况下，我才会向待办事项报告中报告一些内容，并得到优先排序--这大大减少了我创建bug报告的时间。

这些都是我在敏捷过渡期间所做的事情，而这并不是一个完整的列表。关键是实际的测试没有改变:改变的是它是如何被记录下来的，当它发生的时候，以及--希望--其中有多少是自动化的(如果做得好的话，变成回归测试的自动化测试将节省大量的工作)。

Answer 2

敏捷测试通常是指在敏捷工作流环境中测试软件的实践。

当以敏捷的方式进行测试时，很少(如果有的话)严格遵守需求文档和检查列表。相反，我们的目标是在任何时候做任何必要的事情来满足客户的要求，用面对面的会议代替文档，用统一的、自组织的项目团队来代替封闭的功能。

在敏捷公司的文化中，每个人都应该紧密合作，无论他或她的角色，以实现一个单一的目标:一个高质量的软件产品，以满足所有的基本规格，客户或设计师要求的每一次迭代。软件开发人员、测试人员和质量保证人员不时互戴帽子，虽然可能有一组人在运行大多数测试，但对于许多产品团队来说，单独的测试团队的概念完全消失了，对于那些外部机构(甚至法律)要求进行正式和/或外部版本候选测试的组织来说，这种概念在核心开发周期中消失了。即使在这些情况下，这个单独的候选版本“测试”也不是为了发现问题或改进产品而进行的测试，而是在验证、法规遵从性和/或审计跟踪完成方面的练习。

Answer 3

对我来说，敏捷测试器是指没有在某个阶段工作的人。敏捷框架的目标是团队之间的凝聚力。每个人都参与沟通，并在问题出现时解决问题。

例如，QA分析人员发现了一个bug，并将问题通知dev成员，如果该bug未被验证为先前存在，则它们一起工作以实现解决方案。这个过程要快得多，手放在上面，而且是直接的。它消除了对可能占用更多时间的正式bug报告的需求。它也不会在测试周期接近尾声的时候推动解决方案，从而允许在过程中更早地发现其他错误，并且可以节省开发团队的时间，避免可能的重构，并节省公司的费用。在开发周期中，发现bug的时间越晚，从本质上讲，它就会花费公司更多的时间和人力。

在瀑布环境中，通常有一个测试阶段发生在开发完成之后，并被推向开发的后期阶段。当然，这并不意味着所有公司都应该立即转向敏捷，因为某些团队/项目在这种环境下工作得更好，但这只是两者之间的一些优缺点。