敏捷测试人员与传统测试人员...？

#1 楼

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

此外，如果您没有Crispin和Gregory的敏捷测试，请获取它。

我发现有帮助的一些事情包括：


测试计划仍然会发生-但它们在测试时会变得更加轻巧和易于构建。有些工具对此的支持要比其他工具好得多。
测试用例也变得更加轻松：如果您一直在详细地“单击此链接，输入文本，单击此按钮”级别创建测试用例，则可以（非常感谢！ ）停止这样做，而将目光转向更轻盈的风格。
通常来说，测试用例来自用户案例和验收测试：例如，验收测试可能是“作为登录用户，我希望在我查看所有订单及其当前状态的列表时导航到订单管理页面”。这可能会产生看起来像这样的测试用例：


如果用户登录，则主页上有指向订单管理页面的链接。
如果用户尚未登录，没有到订单管理页面的链接。
订单管理页面列出了已登录用户的所有订单，按日期从最新到最早的顺序排序，并显示每个订单。


如果您的团队正在创建单元测试，则应该熟悉他们所测试的内容，因为这可以简化您的测试：好的单元测试将涵盖业务逻辑并允许您进行手动测试专注于端到端方案

先测试快乐路径/钢螺纹。这是满足用户案例/验收测试/用例所必需的最低功能。
探索性的测试会话应记录在案并进行时间限制（“花一个小时探索订单管理页面的行为”）。
通常，不正式地报告问题会更容易，特别是如果您的团队没有在迭代中运行小瀑布时-我的方法是在发现一些奇怪的东西时与开发人员联系，以及他们是否已经在处理它否则他们可以在一天内为我解决，这就是全部。我会报告一些积压的东西，并且只有在一天之内无法解决问题时才进行优先级排序，这大大减少了我花在创建错误报告上的时间。

这些都是我发现自己在敏捷过渡期间所做的所有事情，但这还不完整。关键是实际测试不会改变：改变的方式是文件的记录方式，过程中何时发生，以及-希望其中有多少是自动化的（成为回归测试的自动化测试节省了大量工作量）从长远来看，如果做得好）。

#2 楼

敏捷测试通常是指在敏捷工作流程的上下文中测试软件的实践。

以敏捷方式进行测试时，几乎没有（如果有的话）严格遵守需求文档和清单。相反，目标是简单地随时满足客户的需求，用面对面的会议代替文档，并用统一的，自组织的项目团队代替孤立的功能。

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

#3 楼

对我来说，敏捷测试员是一个不按阶段工作的人。敏捷框架的目标是团队之间的凝聚力。每个人都参与交流并解决出现的问题。

示例QA分析人员发现了一个错误，并通知开发人员该问题，如果该错误未得到验证，则他们将共同实施解决方案。该过程更快，更动手，更直接。它消除了需要占用大量时间的正式错误报告的需要。它还不会将解决方案推到测试周期的末尾，从而可以在过程中更早地发现其他错误，并节省开发团队进行可能的重构的时间，并节省公司资金。在开发周期中发现错误的时间越晚，从本质上讲，这笔钱越多，这将花费公司更多的时间和人力。推向发展的后期。当然，这并不意味着所有公司都应该立即转向敏捷，因为某些团队/项目在这种环境下表现更好，但这只是两者之间的优缺点。

#4 楼

我知道这是一个非常老的话题，但是以防万一有人从最近的搜索中找到关于这些话题的幻灯片，可能对这些有关敏捷测试的幻灯片很有用。 -automation-help