我如何证明/展示我作为自动化测试人员为(高)业务增加的价值？

Question

说我是一个新项目中唯一的QA，也是部门自动化测试的第一次(没有经验或支持网络)。最初参与项目(几个星期)进展顺利，甚至得到了团队的积极评价。问题是，在最后一次sprint中，由于以下原因，任何进一步测试的创建都会被阻止：

1. 缺乏新功能(我已经自动化了我现有的功能)，
2. devs不想让我“测试CSS”，而是只做视觉回归的工作(没有详细说明为什么，设计或者需求会改变吗？)
3. 我只有一个本地环境，无法使用"dev“环境进行访问/身份验证，而且每个人都太忙，无法解除对我的限制。

现在，我被告知，作为这个sprint的一部分，我需要向高级经理“证明/推销”自动化测试的想法。

我已经编写了关于我的设置和测试内容的wiki文档(我在电子表格中也有)，我用柏树做了可视化回归，并生成了令人毛骨悚然的报告。

根据你的经验，我应该如何处理这种情况？我如何生成测试计划，并潜在地跟踪度量/KPI，以展示无需手工操作所获得的时间，或者测试如何防止可视化/功能回归？

附注：我已经阅读了50多个可能相关的问题，但我认为它们没有涉及到我的问题的关注，所以我将尝试为我的案例提供一些背景。请注意，我考虑在"workplace.SE“中张贴，但我不关心团队的动态或潜在的”削减成本“在这一点。

Answer 1

简短的回答:自动化的价值是经过数周、几个月甚至几年的长期回归测试。

长答案：

(从业务角度来看)覆盖范围越广，自动化执行越频繁，就越能增加节省手动测试周期的价值，从而使所需的ROI能够说服/出售给管理层。

话虽如此，它并不是解决所有测试问题，甚至完全取代人工测试的银弹。

在最好的情况下，它称赞周到，熟练和创造性的手工探索性测试。

实用建议:开发POC

在给定的场景中，我将确定应用程序中最小的可能区域&高度浓缩的区域(基于手动测试经验)，其中大多数/或主要错误以前经常被发现。

我将自动化2-3场景，以POC (概念的证明)结果分析作为Demo的一部分来展示对涉众的实用价值。

Answer 2

最终，我的目标是提供自动化，在编写代码的时间点和发现缺陷的点之间建立一个更快的反馈循环。通过减少这个反馈循环中的时间，您可以在更短的时间内解决缺陷，而代码在他们的头脑中仍然更新鲜，而且修复对于开发人员来说更容易、更快。

对于我来说，自动化的第二个目标是处理回归。在敏捷中，如果是手动完成的话，很少有时间进行完全回归。这需要某种程度的自动化来验证日常操作是否仍然有效。

Answer 3

首先阅读测试自动化的经验 (链接到一个示例)，您可能会得到一些想法。

然后问问自己，有没有人诚实地回答：“我的自动化给团队带来了什么真正的价值？”

如果您不计算在开发自动化过程中发现的问题或立即跟踪问题(因为随后会使用工具进行探索性测试)，那么您很有可能会对答案感到惊讶。我的经验表明，答案将是“不多”。

那你打算怎么做？试着把自己描绘成一个现代的测试者，其工作是加速可运输质量的实现，即原则在这里，但是如果你去寻找它的话，会有很多材料。