大多数组织都应该软件——也与188金宝搏官网登录app

像许多奥地利人一样,我喜欢“上山滑雪”——将皮我的滑雪板,爬山,也许休息一个安慰的饮料,然后滑翔下来。这需要携带一定数量的装备。即使是在低风险的情况下,您需要一个包你的护目镜,急救箱,一张地图,额外的隔热层,水,一些食物,也许一个小照明灯。更偏远/崎岖的位置,你可能想要增加粮食供应,加上加入雪崩收发机,铲雪探针等。

这是一个微妙的平衡。你不想跳过一些你可能真的需要,如果你遇到雪崩,例如。但是,如果你带太多,你将无法达到预期的速度和敏捷性。在最坏的情况,你有一个沉重的背包塞满太多的一件事,但没有足够的同时另一个——让你没有准备和超载。

这就是大多数企业组织对软件测试站:有罪的太多和太少的测试中,曝光过度的风险,无法快速主。188金宝搏官网登录app让我解释一下…

自定义应用程序:太多的测试

最“定制”的自定义应用程序实际上是overtested。应该尤其流行当测试外包给服务提供商,其付款取决于有多少测试定义和自动化。它经常发生,导致公司支付测试产量有限的业务价值。

当测试人员以测试他们生产的数量来衡量,你会得到比你实际上需要更多的测试,延迟释放通常是所有这些测试被创建、执行和更新。这是测试的一个主要原因是经常被引用为# 1应用程序交付过程中的瓶颈。更糟糕的是,你通常不会得到正确的测试。你得到很多的测试检查同样的事情一遍又一遍。

你怎么解决这个问题?采用一种新的货币来测试:关注业务风险覆盖测试用例的数量。

你可能听说过的80/20规则(即。帕累托原则)。大多数情况下,这指的是20%的努力创造了80%的价值。软件开发188金宝搏官网登录app相当于20%的交易表示80%的你的商业价值…和测试需求的20%可以覆盖80%的业务风险。

即使测试人员是真正试图捂住顶级商业风险(与创建一定数量的测试),得到正确的测试是不容易的。直观地工作,大多数团队实现只有40%的风险覆盖率,最终积累一个测试套件,高度的冗余(也称为“膨胀”)。平均有67%的测试不导致风险覆盖,但他们使测试套件执行缓慢,难以维护。回到我们最初的比喻,这就像是加载你的背包除了水。比你从未真正地需要更多的水在雪地里,那水是占用空间和重量会更好分配给诸如食物和一个额外的隔热层。

如果“业务”给测试人员的准确评估应用程序功能映射到业务风险,测试人员可以覆盖这些风险非常有效。这是一个巨大的未开发的机会测试更快和更有效的。如果测试人员了解风险是分布在整个应用程序和知道这20%的交易相关业务价值的80%,覆盖上是完全可行的商业风险投资没有过高的测试。

一旦清楚真正需要测试,下一步就是确定如何尽可能有效地测试它。就像所有的需求并不平等(从风险的角度来看),同样适用于创建的测试来验证这些需求。一个特意设计测试可以实现,如果不是更多,风险覆盖十其他测试是“直觉”为相同的设计要求。

这就是测试用例设计方法。与一个有效的测试用例设计策略,如线性扩张,测试人员可以尽可能有效地测试风险最高的需求。他们引导尽可能少的测试需要1)达到风险覆盖率目标和2)确保当一个测试失败,团队确切地知道什么应用程序功能进行调查。

当涉及到测试自定义应用程序,少即是多。更有价值的团队和涉众。更多的时间来获得实现的测试时间,这样你就可以释放。和敏捷项目变更课程和测试套件时需要一个重大更新。

打包应用程序如SAP和Salesforce overtesting-undertesting落在另一端的频谱。最常见的策略是什么测试SAP企业应用程序改变——自定义更新、服务包,或紧急补丁?不测试改变!

打包的应用程序:没有足够的测试

好吧,也许这不是完全准确。大多数组织做一些打包的应用程序的测试。当一个更新需要部署到生产,他们关键用户测试它。

但你猜怎么着?关键用户不喜欢测试。测试通常是一个冗长的打包应用程序更新,手动折磨。业务流程测试可能是过时的,或者更糟的是,无证——运动令人沮丧且容易出错。这些测试职责堆关键用户已经很繁忙的日程安排。一些关键用户承认我,着急的事情,他们主要是测试用例,他们知道将会过去。他们的策略:“我们测试绿色!”

这些都是新闻运营团队,当然可以。处理缺乏有效的预发布测试,他们经常添加一个”hypercare”阶段的上线后立即更新。Hypercare是一个“甲板上所有的手”期间组织的最昂贵的资源(通常是开发人员和项目人员)进入待命状态,随时解决紧急问题,因为他们出现在生产。是明确的——这些问题在预发布测试,没有发现时,他们也会明显更容易、更经济的解决!因为hypercare阶段是如此普遍,如此昂贵的——有专注于向客户提供hypercare支持的公司。

超过90%的SAP企业客户选择该部署策略,这是漫长的,因为它是昂贵的。关键用户测试通常持续一至两周。hypercare阶段可以持续三个月,在此期间的大部分负担造成的缺陷是感觉——你猜对了——那些可怜的关键用户。

对于大多数组织,依靠关键用户测试+ hypercare测试他们的打包应用程序,我有坏消息,我有好消息。首先是坏消息。SAP(以及其他打包应用程序供应商)将会比以往更频繁地交付更新。这意味着客户必须找到方法来跟上。

现在好消息。有一个更好的选择关键用户测试和hypercare:变化的影响分析。改变你整个SAP生态系统影响分析分析和报告——一夜之间。

• 什么变化对业务和技术风险
• 什么测试需要创建或运行基于这些风险
• 什么新的或现有的测试覆盖经常变化的“热点”,因此应该自动化
• 你不使用定制代码(和不需要测试)。

简而言之:它将帮助您确定需要测试什么。你要测试你需要生存,但最终你不会背负着比你真的需要更多的测试。

然而,一个警告对变更影响分析。鉴于大型打包应用程序的复杂性,改变某个中央组件可能会影响许多对象,将显示为“受到影响。“这减少了该技术的有效性。减轻您的测试负载,进一步缩小测试,考虑到对象的依赖关系(关注“高危”对象)。

测试数据:不够的

现代应用程序摄取、集成和转换大量的数据。有无数的数据变得妥协的机会,通常很少有(如果有的话)形式化过程整个景观完整的数据,确保数据的完整性。

也许你已经设法获得适量的测试在所有自定义应用程序和打包的应用程序收集数据并将其转换成有价值的信息。不过多久,如何彻底,底层数据被测试吗?系统的其他组件的样子表现与预期完全一致,但如果数据,业务需求没有被满足。事实上,商业被放置在极端风险。

假设一个打包的应用程序更新数据格式引入了一个微妙的变化,这一变化防止1每100000条记录被处理。你会立即知道,还是会被忽视,直到一个愤怒的顾客(或挑剔的监管机构)来调用吗?如果您的组织引入了一个新的领域(例如,COVID-19测试状态),然后一个月后,一个团队的bug修复最终覆盖状态无论何时更新用户配置文件?

与自动“质量门”不断地检查数据输入和移动应用程序,你可以赶上他们介绍等问题。之前你也可以消除它们的影响业务,需要大量的数据检查/维修手册。

到目前为止,金融,保险,和医疗保健公司一直引领自动化端到端数据测试。他们实现一些成果显著——比如能够自动测试2亿个值在短短20分钟。如果你工作在消费上的应用程序,操作,或输出数据(而不是吗?),不要离开这个重要的背后。没有它,微妙的数据问题可以迅速扩大成为一场危机,你需要一个相当雪崩铲挖出来的。

注意:这个内容最初发表在《新栈