从测试自动化中实现价值–>价值与投资回报率

在我们准备结束另外十年的软件开发和测试时，我认为这也是摆脱旧有和过时的条款和方法的好时机–在此简短的帖子中，我将尝试消除术语ROI并建议更换它具有价值 。

如果直到几年前，质量管理部门都试图通过ROI指标来证明对测试的投资是合理的，那么现在是时候进行更改了。

当实施连续测试，并且每天在不同的环境下以不同的角色运行多次测试自动化时，由于测量方法与以前大不相同，因此ROI成为过时的术语。

试图衡量和证明测试投资合理性的未来5-10年的关键术语应该是VALUE 。

在说服投资回报率一词之前，让我们先设定一下现代测试自动化尤其是连续测试的目标。

在敏捷测试宣言中，我用粗体标记了此类测试背后的关键价值。

• 持续测试超过最终测试。
• 涵盖所有测试活动 ，而不仅仅是自动化功能测试。
• 测试比测试一切更有价值 。
• 在整个团队中进行测试，而不是在孤立的测试部门中进行测试。
• 产品覆盖率超过代码覆盖率。

如果要应用上述方法，则此类测试的主要目标是通过整个团队对产品进行的高价值测试以及整个测试类型（功能性和非功能性）来识别业务风险。

在上面的陈述中，除了测试的值之外 ，没有任何度量或量化方法。

为了实现连续测试，组织应着重于内部创建测试自动化功能的能力，并在可靠的实验室中以及一天结束时按需大规模执行它–使用智能方法分析结果以使测试有意义结果数据。

如果上述Struts符合组织的测试策略和优先级，则用于创建和执行测试的工具和技术将相匹配是有意义的。

这里最大的问题是- ^ h OW做我证明$$在上面的柱子任何投资？ 有哪些相关措施？ 每个步骤中谁都拥有质量？ 什么样子好看 ？

为了解决上述问题，让我们确定谁在当今的敏捷和DevOps实践中进行测试。 由于DevOps团队分为功能组，测试工程师和开发人员在迭代和sprint中共同处理特定功能，因此没有人真正地进行测试。 提供高质量和高价值的软件是功能团队的责任。 考虑到这一点，您将发现业务测试人员，开发人员和测试自动化工程师一起工作，并创建自动化测试方案以及手动探索性测试以实现其目标。 虽然可能有现代化的COE或质量领导职能来监督组织内部的测试策略，确定预算和工具，但实际工作实际上是在团队内部完成的。

如果您与我一致认为价值是测试中最重要的事情，那么让我们尝试将价值分解为度量：

• 周期内的片状测试数量
• 重复发现缺陷的测试数量
• 导致CI作业失败的测试数量
• 因根本原因（对象ID，实验室，编码技能，平台状态等）分类失败的测试数量。

尽管还有其他指标，但上面的指标清楚地表明了测试实际上是否符合他们期望的发现错误，或者仅仅是在制造噪音和软件团队浪费。

从一些市场标准来看，每个KLOC （1000行代码）平均存在10-15个缺陷，每个KLOC都有0.5个缺陷逃到生产中。 如果遵循这个数字，很明显，今天发现和报告的大多数缺陷是噪声与真实缺陷。 要在连续测试中取得成功，需要有纪律和对价值的适当衡量，以确保报告为错误的大多数失败测试确实存在问题–相反的情况会在整个DevOps团队中造成混乱。

考虑到这一点，团队必须承认测试质量和产品质量是及时的事实，因此，您需要不断地对其进行测量和维护，以获取产品的实际状态。

我如何实现比价值？

长话短说，在测试生命周期中，只有一个地方可以提供整个测试活动的价值与浪费之间的一小部分–这就是测试报告！

如果您从编写代码的那一刻起就考虑到测试的整个生命周期，包括调试，执行和提交到管道中，那么开发人员（无论可能是谁）都会在测试“通过”之时告别测试。在他的环境中。 只有在正式测试周期中测试失败（可能是CI，其他事件触发的回归等）时，测试所有者和测试之间的团聚才会发生。 这意味着，从测试集成到套件直到失败为止，都有一个盲区。 除了对测试感到满意之外，没有真正的理由来复习它（如果它当然是一项高价值的测试）。 现在，考虑一下一组1000个平均失败率为10％的测试案例。 这意味着我们现在有100个失败的测试场景，需要有人审查和报告。 除此之外 ，上面提到的每个KLOC有10-15个缺陷的事实，事实表明， 至少80％的测试不是真正的bug 。 该团队现在必须处理80个测试用例的调试，这些调试可能会或可能不会增加产品的价值。

我认为（和希望）到目前为止，这一点很明确–> 测量测试自动化值是从上述指标开始的，并且大多数测试用例的概念在以10倍的时间作为回归运行时都不会揭示关键的错误。 要了解哪些测试可以增加价值，什么没有增加价值，什么仅仅是噪声和不熟练的软件工程，您需要对测试活动的每个领域都具有适当的测试报告和质量可视性。

底线–投资时间，即金钱的资源，应牢记这些测试的附加值。 每个周期使用老式的通过/失败测试效果不错，但无法跟上当今技术的步伐，因此，需要对测试如何实时，随时间，针对每个平台，针对每个功能区域进行更认真的检查。 是的-不要太依赖您的测试代码，如果短时间后仍不能证明自己，只需删除它即可。 您只能通过报告评估测试是否带来了价值。

根据测试投资与测试价值实现，以下视觉分解了连续测试（CT）的四个Struts。

祝新的软件测试十年

翻译自: https://www.javacodegeeks.com/2019/11/realizing-value-test-automation-value-roi.html