什么使敏捷测试与“其他”测试不同？

问题（仔细阅读！）：什么使敏捷测试与“其他”测试不同？

敏捷与敏捷？

什么是敏捷测试？什么是敏捷？我先说我不区分敏捷和敏捷。对我来说一切都是一样的。敏捷是一种思维方式，是一种看待世界的方式。对我来说，这不是一个过程或方法。它更像是一种容器，而不是一种工作方式。这篇博文讨论了敏捷与敏捷，我喜欢它。它将敏捷描述为一种思维模式，敏捷地将资本A描述为商业广告：“这里的问题是，所有这些明智的建议都被形式化为”敏捷“，并带有资本A.这套建议似乎是”有效的“盒装在一个顶部有弓的包裹中，卖给公司和经理。”

敏捷测试？

敏捷测试？什么是敏捷测试？我更愿意在敏捷环境中进行测试而不是敏捷测试。通过首先查看具体情况的详细信息，可以在敏捷环境中进行良好的测试。记住上下文驱动测试的第7个原则：“只有通过判断和技能，在整个项目中合作运行，我们才能在正确的时间做正确的事情来有效地测试我们的产品。”

测试是软件实现的重要部分。在敏捷环境中实施测试是一项挑战。它为测试人员带来了一些有趣的挑战：

通过工作的迭代性，与我们大多数人在更传统（瀑布式）环境中习惯的测试相比，测试的时间更少。它需要不同的测试方法。在敏捷环境中进行测试的阶段不同。

我怎样才能确保我能够足够快地执行足够的测试以跟上项目的步伐？

测试人员需要确保“自我管理团队”做足够的测试

应对不断变化的团队动态，人们的工作和互动很重要

在变化很常见的环境中集成结构化测试

当没有可测试的软件时，作为测试人员提供附加值

测试人员需要立即提供价值。在敏捷的环境中，快速反馈可以让团队不断前进。测试应立即提供有关正在开发的产品状态的有用且可理解的信息。它使团队能够不断为业务提供富有洞察力的价值并取得最大进步。

不同？

那么区别是什么呢？我认为测试本身并没有太大的不同，它是你进行测试的上下文不同。如果你的目标是瀑布和敏捷之间的差异，我最重要的差异列表将是：

更少的准备，执行和报告时间（短期冲刺）。

迭代和增量方法：出色的单元测试至关重要。

测试自动化（有些称之为自动检查或工具辅助测试）对于快速反馈和持续集成至关重要。

角色转变：减少测试，更多教练。测试人员成为“测试教练”或“质量总监”，以确保团队正在进行充分的测试。够了（不是太多也不是太少）而且质量很好。

应对不太确定：变化很常见。测试文档需要通过透明，使用简单的仪表板和轻量级测试文档来处理变更。

团队合作：许多测试人员习惯在测试团队中工作，他们现在在开发团队工作。

持续的批判性思维：测试人员需要通过思考对影响和风险的批评来帮助团队。在编写像主测试计划这样的文档时，测试人员习惯于这样做，他们现在必须在整个项目中不断地做到这一点：在美容课程，每日立场，计划会议等等。但也在他们自己的工作中：做出选择什么覆盖：广泛和深度。

再说一次：测试本身并没有太大的不同，它是你进行测试的上下文不同！

最后跟大家推荐一个学习资料分享群：672899761

里面大牛已经为我们整理好了许多的学习资料，有自动化，接口，性能等等的学习资料！人生是一个逆水行舟的过程，不进则退，咱们一起加油吧！