质量检查团队快速交付高质量软件的10个最佳实践
作为质量保证(QA)团队的负责人，我必须每六周签署一次主要版本的质量。每个主要版本通常包括两个新的大特性和三个较小的特性，比如用户界面(UI)的更改或一个新的报告，以及稳定性问题和bug修复。我有8名QA工程师，他们负责30名开发人员开发的代码。
这是一项艰巨的任务。因此，为了避免不得不在晚上和周末工作，我们的团队采用了这10个最佳实践，使工作负载易于管理，同时确保我们批准的版本保持最高的质量标准。
- 摆脱质量检查的传统角色和职责 我们在两个方向都突破了边界。我们是一个面向客户的部门，我们从客户那里听到他们所经历的问题，以及他们希望在我们的产品中看到什么特性。另一方面，我们积极参与设计讨论，提供来自客户的输入。
此外，我们的代码测试知识和经验帮助我们在任何人花费时间编码之前识别设计缺陷，这极大地减少了开发周期，并帮助我们在自适应地发布新版本时满足客户的期望。
仔细选择发布标准 您不可能产品中的每个版本都进行测试，幸运的是，您不需要这样做。 如果您关注代码中最重要的更改所在的区域，那么您仍然可以对所批准的产品充满信心。 在新的发布周期开始之前，我们的团队与所有利益相关者坐在一起，以了解新的或更新的代码将涉及产品的哪些部分。 我们使用该信息确定测试工作的优先级 。 我们专注于代码的那些部分，并使用现有的自动化测试来处理其他部分。 如果您知道在上一发行版中有某些工作，并且在此发行版中没有涉及，则您无需花费太多时间进行测试。 因此，您的发布条件应基于要添加的新代码。
根据使用情况对bug修复进行优先级排序 修复bug是任何新版本的重要组成部分，但是您应该将精力集中在哪些bug上呢?我们的答案是使用数据。我们使用谷歌分析来查看终端用户在没有负载测试工具的情况下是如何交互的。这给了我们大量的重要信息。例如，如果我们知道应用程序的某个区域很少使用，那么该部分代码中的bug的优先级就会降低。如果只有不到1%的用户使用某个特定的浏览器，那么针对该浏览器的特定问题就会得到较少的关注。但我们也倾听客户的意见。我们想要的最后一件事是让我们的用户体验错误。 如果确实发生了什么事情，并且用户发现了错误，则这些错误将在下一发行版中作为修复的优先级。
采用两层方法进行自动化测试 如果开发人员对主干的提交以任何方式破坏了构建，我们将尽快通知他们。也就是说，我们不能对每个提交都运行详尽的系统测试。这将花费太长时间，而且在发现问题之前，开发人员可能已经转移到其他地方了。因此，我们采用了两层的方法来测试自动化。对代码库的每次提交都会触发第1层，它提供对开发人员更改的快速验证，并在几分钟内完成完整性测试。第二层运行更详尽的回归测试，并在晚上自动运行，这时我们有更多的时间来测试更改。决定每一层应该有多轻或多彻底是一门艺术。但是一旦您开始像这样工作，您将很快学会如何在白天的正常测试和夜间的回归测试之间取得平衡。
密切关注相关环境
每个QA团队都听到过开发人员的评论，“……但它对我的机器有效。”如何避免这种情况?
我们的QA和我们的开发团队运行完全相同的环境。然而，当我们的构建通过pipeline时，我们必须在生产条件下测试代码，因此我们构建stg环境来模拟客户的生产环境。
- 成立专门的安全测试小组
因为客户使用我们的产品即软件即服务(SaaS)，所以我们将所有数据存储在服务器上，并且需要在每次发布之前执行安全测试。SaaS平台上的安全漏洞往往会被用户发现，而这些问题会迅速赶走客户。为了防止这种情况发生，我们成立了一个专门的测试团队，对即将发布的产品和更新的稳定版本进行了为期一周的渗透测试。在开始测试之前，我们向团队简要介绍即将发布的版本和产品环境中的新特性。团队使用这些信息来测试安全漏洞，试图渗透系统。这些团队成员经过严格的安全培训，熟悉相关的企业和ISO安全标准，并精通云应用。
在他们的帮助下，我们的团队最近发现了一个由顶级云环境提供商之一创建的安全漏洞，该漏洞将允许恶意黑客获取有价值的信息。我们迅速更新了亚马逊云上的基础设施，以防止黑客入侵。
- 组建专门的性能测试团队
让专门的性能团队在产品稳定后立即运行测试，并向团队简要介绍新版本和特性，以便他们能够评估性能风险。当开发人员引入一个对性能没有影响的新特性时，例如屏幕上的按钮，我们只运行回归测试。但是，如果我们怀疑某个特性可能会影响性能，我们还会编写和执行新的性能测试。
始终使用所有相关信息更新您的安全性和性能团队，并为他们提供尽可能接近生产的环境。在我们最近发布的一个版本中，性能工程师发现了一个内部的、第三方SaaS环境中的重大瓶颈，因为该提供商的数据库中有一个新的配置。如果性能团队没有测试环境，就会导致崩溃。这一步至关重要。如果您没有办法组建自己的专用性能团队，可以培训一些QA团队成员进行性能测试。
- 运行一个回归循环
我们在产品稳定的最后阶段运行我们的回归周期，正是这个过程触发了进入生产的绿灯。由于此时开发中的更改很少，所以您有机会验证整个产品。我们从概念上将产品建模为具有模块和组件分支层次结构的树，以帮助我们从客户的角度理解产品。当任何分支被修改时，层次结构会显示它下面的哪些分支将受到影响，并需要额外的QA测试。
我们的回归循环使用红绿灯方法。如果每个分支都获得绿灯(通过所有测试)，则认为产品已经准备好交付了。如果分支收到黄灯(所有测试都通过了，但是有一个或多个报告的警告)，我们将与涉众讨论这个问题。最后，如果分支收到红灯(一个或多个测试失败)，我们将停止并处理该问题。我们还自动化了我们的回归周期，因此只需几天就可以运行。
- 模拟生产中的客户帐户
由于我们在数据库中维护客户数据，我们必须确保它与我们发布的任何新版本保持兼容。Eating our own dog是至关重要的，因此当QA团队运行数据迁移测试时，我们创建一个在我们的生产系统上管理的测试帐户。我们使用这个帐户不断地生成数据和填充我们的数据库。
当我们发布一个新版本时，我们运行更新来检查没有数据被破坏，如果我们发现任何破坏数据的bug，这些bug将成为我们的最高优先级。我们还会花上一两天的时间进行手动向后兼容性测试，同时逐步寻找一种自动化的、更有效的方法。但是，您仍然需要进行一些手动测试，因为这是生产之前的最后一个阶段。
- 在产品上执行完整性测试
我们在生产帐户上执行发布后的完整性测试，以验证一切都如预期的那样工作，包括所有第三方系统。我们首先使用现有的生产帐户执行测试，然后创建一个新帐户，以验证在新客户注册时流程将继续正常工作。我们进行了半天的完整性测试，其中一部分测试旧的帐户，另一部分测试新创建的帐户。最后，我们测试第三方组件，例如计费系统，以确保版本兼容性。
性能工程改变了QA工程师的传统角色和流程。今天，您必须拥有高度专业化和专门的团队，以及从生产到生产的持续的QA过程。此外，为了彻底地履行你的角色并满足你的客户，你必须愿意自己成为客户。
为了在保持产品质量的同时满足频繁的产品发布的需求，QA测试人员必须打破传统的模具。您必须开发新的技能，例如软件设计和开发，这样您就可以更多地参与开发过程的不同阶段。遵循这10个最佳实践对您的团队和业务来说是双赢的。如果做得好，您将缩短开发周期，并使QA专业人员的工作更有吸引力。
