瀑布式项目管理将开发和测试分为两个不同的步骤：开发人员构建一个功能，然后将其“扔到墙那边”，交给质量保证团队 (QA) 进行测试。QA 团队编写并执行详细的测试计划。他们还在煞费苦心地检查现有功能中可能由新工作造成的回归时，将缺陷归档。
许多使用这些瀑布式或其他传统测试模型的团队发现，随着产品的增长，测试量也在呈指数级增长，而 QA 总是难以跟上。项目负责人面临一个不受欢迎的选择：推迟发布，或者略过测试。（您可以猜一下，哪个选项的获胜比率达到 99％。）与此同时，开发工作已经转向了其他方面。因此，不仅技术债务在增加，而且解决每个缺陷都需要在代码库的两个部分之间进行昂贵的上下文切换。这简直是雪上加霜。
更糟糕的是，QA 团队通常根据发现的缺陷数量获得奖励，这就让开发人员处于守势。如果有一种更好的方法，既能让开发人员和 QA 人员减少代码中的缺陷数量，又能消除项目负责人不得不做出的痛苦权衡，那会怎么样呢？这样不就能创造出更好的全面软件了吗？
从传统测试方法转向敏捷测试方法
敏捷开发和 DevOps 团队的目标是可持续地提供高质量的新功能。但是，传统的测试方法根本不适合敏捷开发或 DevOps 框架。开发的步伐需要一种新方法来确保每个内部版本的质量。在 Atlassian，我们的测试方式是敏捷的。与 Jira Software 的高级 QA 团队负责人 Penny Wyatt 一起详细了解我们的测试方法。
就像复合信用卡债务一样，一开始只有一点痛苦，但很快就会像滚雪球一样，削弱了团队的关键敏捷性。为了应对不断增加的技术债务，在 Atlassian，我们授权（不：期望）我们的开发人员始终以质量为先。我们相信，开发人员会带来有助于提高产品质量的关键技能：
开发人员擅长用代码解决问题。
自己编写测试的开发人员在失败时更倾向于进行修复。
了解功能要求及其测试含义的开发人员通常会编写更好的代码。
我们认为待办事项列表中的每个用户故事都需要功能代码和自动测试代码。尽管有些团队在测试团队进行自动化测试时为开发人员分配了功能代码，但我们发现由一名工程师提供完整的功能代码会更有效。
专业提示
这种模式并不意味着开发人员可以单独工作。团队中也要有 QA 工程师，这点很重要。QA 为功能的开发带来了重要视角，优秀的 QA 工程师知道错误通常隐藏在哪里，并可以就可能的“陷阱”向开发人员提供建议。
通过探索性测试实现人类接触
在我们的开发团队中，QA 团队成员与开发人员配对进行探索性测试，这是开发期间防止更严重错误的宝贵实践。就像代码审查一样，我们已经看到了整个开发团队的测试知识传授正因为此。当开发人员成为更好的测试人员时，第一次就能交付更好的代码。
但是探索性测试不是人工测试吗？不行。至少与手动回归测试的意义不同。探索性测试是一种基于风险的批判性思维测试方法，使测试人员能够利用其对风险的了解、实施细节和客户需求。开发人员或 QA 工程师可以在测试流程的早期了解这些内容，从而快速而全面地发现问题，而无需编写脚本化的测试用例、详细的测试计划或要求。我们发现它比传统的手动测试有效得多，因为我们可以将探索性测试会话中的见解带回原始代码和自动测试。探索性测试还向我们讲述了以脚本测试所没有的方式使用该功能的体验。
要保持质量，就必须将探索性测试和自动测试结合起来。随着新功能的开发，探索性测试可确保新代码在更广泛的意义上符合质量标准，而不是单独的自动测试。这包括易用性、令人愉悦的视觉设计和该功能的整体实用性，此外还有自动测试提供的针对回归的强大保护。
改变可能很难——真的很难
我给大家讲一个自己的故事，能够很好地总结我的敏捷测试历程。我记得在我职业生涯的早期管理过一个工程团队，他们强烈抵制编写自动化测试，因为他们认为“这是 QA 的工作”。经过几次错误代码迭代，听到了自动化测试会减慢团队速度的所有原因之后，我坚定了自己的立场：所有新代码都必须通过自动测试进行验证。
单次迭代之后，代码开始改进。而之前最坚决反对编写测试的开发人员，却是在测试失败后立即采取行动的人！在接下来几次迭代中，自动化测试不断增长，跨浏览器扩展，并改善了我们的开发文化。当然，推出一项功能需要更长的时间。但是错误和返工大幅减少，最终为我们节省了大量时间。
改变通常都不容易。但是，就像大多数有价值的东西一样，如果您开始认真做事并创建新模式，那么很快您就会开始想“为什么没有早点开始？！”