文本
#不要以质量赌博 了解利益相关者如何优化您的测试策略和最终的软件。
根据我在TW担任高级质量检查顾问的经验，我看到许多组织仅将质量保证（QA）视为项目的额外费用，而忽略了它为软件质量带来的内在价值。
主要原因似乎是项目经理和主要利益相关者不了解质量保证的好处及其为开发团队带来的价值。
在本文中，我将解释为什么了解您的利益相关者是谁以及如何优化测试策略以包括这些利益相关者的利益如此重要。
因为更好的参与度会导致更好的测试策略，从而带来更好的软件。
敏捷 项目中的质量保证
在敏捷软件开发中，重要的是要创建一个以结果为导向并且与团队和组织整体相适应的测试策略。在敏捷中，质量保证是关于将测试集成到软件开发生命周期的每个阶段中，因此测试策略应着重于实现这一目标。
与软件开发的其他方面一样，要创建有效的测试策略，您需要知道谁是利益相关者。您需要一开始就了解他们的要求，兴趣，关注点和目标，并为适应变化做好准备。反过来，这将使更广泛的团队的购买更容易获得保障，他们将对测试结果感兴趣。
谁是测试人员的利益相关者？
最常见的是对测试结果和质量保证提供的信息感兴趣的人：开发人员，设计人员，产品所有者，项目经理，用户和赞助商。
开发者
开发人员是开发产品的人。这些利益相关者需要知道他们的产品出现故障的地方，以便他们可以修复[接近其来源]的缺陷。对于他们而言，在开发过程中尽早发现问题很重要，因为补救的成本会随着时间的流逝而增加，并且发现较晚的缺陷会使项目对这些问题做出响应的灵活性降低。
测试策略应包含良好的开发实践，例如功能分支，请求请求，同行评审和质量度量，例如单元测试覆盖率，集成测试覆盖率，自动冒烟/回归测试，性能测试，安全性测试和代码质量检查。这些措施提供了一个安全网，使开发人员更有信心进行应用程序更改。 设计者
设计人员负责设计产品的用户界面（UI）和用户体验（UX）。这些利益相关者还需要知道他们的设计失败的地方，以便他们解决问题。重要的是尽早发现任何设计问题，通常是在开发开始之前。
测试策略应包括测试技术，例如设计审查，可用性测试，可访问性测试等，以解决这些涉众的利益。 产品负责人和业务分析师（BA）
产品所有者和BA可能会合作开发用户案例并讨论优先级。他们有兴趣了解某个功能是否满足他们的需求和期望。质量检查团队应与PO和BA合作，以了解需求（用户案例）并将其有效地传达给更广泛的团队。
定义明确的用户故事应包括该功能的背景，接受标准和非功能性要求。测试策略应包含活动，以审查用户故事是否可测试，并创建验收测试以验证实现的功能满足验收标准。 项目管理
这些利益相关者需要了解可交付成果的状态（即应用程序功能）：它们是否可用，可接受并且合理地没有缺陷？如果有问题，经理可能需要重新计划或至少管理期望。
在您的质量保证策略中包括测试可交付成果（即测试场景，测试案例，需求可追溯性矩阵（RTM）），进度表和质量度量，以证明正在开发的应用程序的质量非常有用。 赞助商
这些利益相关者需要证据表明系统可以支持其业务目标，并且可以接受失败的风险。重要的是要了解业务目标和产品风险，并将其包括在测试策略中。
展示对测试策略中的业务目标和风险的理解，还将帮助您定义正确的测试方法。 用户数
这些利益相关者需要证据表明该系统将为他们工作。作为质量检查人员，您应该始终将自己视为最终用户。
您的测试策略应解决实时用例场景，例如在不同的浏览器，操作系统，设备中进行测试，可用性测试和可访问性测试。 结论
作为QA，我们需要接受对利益相关者负责的观点；您需要与一系列利益相关者进行互动，协商并进行沟通，并将他们的需求反映到您的测试策略中。测试方法应始终专注于满足其需求。
但是，即使就测试策略达成共识并付诸实践，对于质量检查人员而言，与这些利益相关者进行有效沟通也很重要。有时，这将采取文档，共享Wiki，看板或Scrum板的形式。如果您的测试策略解决了利益相关者的担忧，那么他们将感到参与并在关键时刻为质量保证团队提供支持。
最好的测试策略是探索，思考和协作的结果。
author
石头 磊哥 seven 随便叫
company
thoughtworks
大家好，本人不才，目前依旧混迹于thoughtworks，做着一名看起来像全栈的QA，兴趣爱好前端，目前是thoughtworks 西安QA社区的leader，如果有兴趣分享话题，或者想加入tw，可以找我
roles
QA（营生） dev（front-end dev 兴趣爱好）
联系方式
如果想转载或者高薪挖我 请直接联系我 哈哈
wechat:
qileiwangnan
email:
qileilove@gmail.com
