赞
踩
如果几年前,质量管理部门都试图通过ROI指标来证明对测试的投资是合理的,那么现在情况发生了变化,是时候重新审视这个问题了。当实施连续测试,并且每天在不同的环境下以不同的角色运行多次测试自动化时,由于测量方法与以前大不相同,因此ROI成为不合时宜的术语。试图衡量和证明测试投资合理性的未来5-10年的关键术语应该是VALUE。
在说明投资回报率一词之前,让我们先设定一下现代测试自动化尤其是连续测试的目标。
在敏捷测试宣言中,我用粗体标记了此类测试背后的关键价值。
如果要应用上述方法,则此类测试的主要目标是通过整个团队对产品进行的高价值测试以及整个测试类型(功能性和非功能性)来识别业务风险。在上面的陈述中,除了测试的值之外,没有任何度量或量化方法。
为了实现连续测试, 组织应着重于内部创建测试自动化的能力,并在可靠的实验室中以及一天结束时按需大规模执行它,或者使用智能方法分析结果以使测试有意义量化的结果数据。
如果上述支柱符合组织的测试策略和优先级,则用于创建和执行测试的工具和技术将相匹配是有具有非常重要的意义的。
这里最大的问题是:我该如何证明在上面的提到的方面进行的投资?有哪些相关措施?每个步骤中谁都拥有什么样的权利?什么样子才是正确的?
为了解决上述问题,让我们确定谁在当今的敏捷和DevOps实践中进行测试。提供高质量和高价值的软件是功能团队的责任。考虑到这一点,将业务测试人员,开发人员和测试自动化工程师一起工作,并创建自动化测试方案以及手动探索性测试以实现其目标。虽然可能有现代化的COE或质量领导职能来监督组织内部的测试策略,确定预算和工具,但实际工作实际上是在团队内部完成的。
如果您与我一致认为价值是测试中最重要的事情,那么让我们尝试将价值分解为度量:
尽管还有其他指标,但上面的指标清楚地表明了测试实际上是否符合他们期望的发现错误,或者仅仅是在制造麻烦和软件团队浪费。
从一些市场标准来看,每个KLOC(1000行代码)平均存在10-15个缺陷,每个KLOC都有0.5个缺陷逃到生产中。如果遵循这个数字,很明显,现在发现和报告的绝大部分的缺陷都是误报。要在连续测试中取得成功,需要有纪律和对价值的正确衡量,以确保报告为错误的大多数失败测试确实存在问题,相反的情况会在整个DevOps团队中造成混乱。
考虑到这一点,团队必须承认测试质量和产品质量是及时的事实,因此,您需要不断地对其进行测量和维护,以获取产品的实际状态。
长话短说,在测试生命周期中,只有一个地方可以提供整个测试活动的价值,这就是测试报告!
如果您从编写代码的那一刻起就考虑到测试的整个生命周期,包括调试,执行和提交到现行中,那么开发人员(无论可能是谁)都会在测试“通过”之时告别测试。在他的环境中。只有在正式测试周期中测试失败(可能是CI,其他事件触发的回归等)时,测试所有者和测试之间的团聚才会发生。这意味着,从测试集成到套件直到失败为止,都有一个盲区。除了对测试感到满意以外,没有真正的理由来复盘它(如果它当然是一项高价值的测试)。现在,考虑一下一组1000个平均失败率为10%的测试案例。这意味着我们现在有100个失败的测试场景,需要有人审查和报告。每KLOC 10-15个缺陷,事实表明至少有80%的测试不是真正的bug。该团队现在必须处理80个测试用例的调试,这些调试可能会也可能不会增加产品的价值。
我认为到目前为止,这一点很明确–> 测量测试自动化值是从上述指标开始的,并且大多数测试用例的概念在以10倍的时间作为回归运行时都不会揭示关键的错误。要了解哪些测试可以增加价值,什么没有增加价值,什么仅仅是误报和不稳定的软件工程,您需要对测试活动的每个领域都具有适当的测试报告和质量可视性。
底线–投资时间,即金钱的资源,应牢记这些测试的附加值。每个周期使用老式的通过/失败测试效果不错,但无法跟上当今技术的步伐,因此,需要对测试如何实时,随时间,针对每个平台,针对每个功能区域进行更认真的检查。不要太依赖您的测试代码,如果短时间后仍不能证明自己,只需删除它即可。您只能通过报告评估测试是否带来了价值。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。