《 软件测试价值提升之路》——2.3 面向企业商业成功

2.3 面向企业商业成功

判断测试将要进行的实践是否在创造新的价值,标准就是这个实践对企业必然会关心的3个方面—质量、成本、效率,是否有帮助。测试需要从这个本质出发,看看自己的工作对质量、成本、效率的显性贡献,即以测试这一角色为主的贡献在哪里。这里想强调“显性”这两个字,意味着不打算去摆弄那些通过复杂计算得到的数据,比如缺陷提前发现对成本的贡献。在我的经验中,通常研发或产品的领导并不会质疑这些数据,但是这些数据无法促使他们支持加大对测试的投资。
那么,产品的领导最重视什么呢?显然是“企业的商业成功”。企业的商业成功,落实到研发体系,就是需要研发提升质量和效率,降低成本。测试团队选择做一项改进或者引进一种技术,首先就要确认所做的工作在研发质量、效率、成本上的目标。并且找到认可这个目标的“同盟军”(指产品团队中,愿意投入这项工作的、测试以外的角色),否则很可能是测试内部的自娱自乐。让我印象最深刻的案例是RBT(基于风险的测试)的第一个应用项目,这原本是一个和研发整体效率非常密切的技术,但是部分产品在应用的时候只强调了用于识别测试重点,结果市场代表、系统工程师、开发工程师都不愿意参与到风险的识别中,使RBT流于形式,没有发挥应有的作用。
我认为,离线发布的产品,可以考虑确定产品质量方面的目标,例如彻底杜绝某一类缺陷遗漏到客户环境中等。在线发布的产品,可以考虑确定成本方面的目标,例如,用户问题快速地察觉、复现和修复,最大限度减少缺陷带来的损失等。以快速发布来抢占先机的产品,应该制订效率方面的目标,例如使用RBT聚焦主要应用场景,缩短研发周期。
总之,创造测试的价值需要“匹配新的业务要求,面向企业商业成功”,就是要测试在产品推出快、变化频繁……的前提下,找到由测试角色主导来实现的、在质量、成本、效率上的“显性”价值。以这些价值来带动团队能力的提升乃至个人的发展。

时间: 2024-10-26 11:30:38

《 软件测试价值提升之路》——2.3 面向企业商业成功的相关文章

《 软件测试价值提升之路》——1.6 华为的软件测试

1.6 华为的软件测试 华为的软件研发特征是:典型的传统软件企业,软件完成后完全部署在用户的环境中使用,有按月交付的业务版本,也有半年甚至更长时间才交付的基础版本或平台版本,产品有一定的继承性,但架构重构也不是小概率事件(这主要是因为华为还是电信领域的新人,对这个领域的把握还不十分老道),十分注重在发布前排除软件缺陷.属于领域跟随者,开发内容绝大部分由客户需求主导.开发测试比是2∶1-10∶1,2∶1是比较核心的平台部门的比例:10∶1是大量测试外包的业务部门的比例.如果加上外包一起计算,比例大

《 软件测试价值提升之路》——3.3 受攻击出错

3.3 受攻击出错 3.3.1 问题案例 我们的产品中遇到的这类问题并不多见,最典型的就是春节.麦加朝觐时,由于通信需求骤然增大对产品产生的浪涌冲击.我们的产品就是在这样的考验下,由最初的业务请求不断堆积形成拥塞,甚至无法进行维护操作,直至系统完全崩溃:到后来在32倍浪涌冲击下,都能保持业务处理能力.相应的测试方法和工具,也是随着产品可靠性能力的增强同步建设完善的. 众所周知,目前很多互联网产品的安全防护能力是较弱的,有一次一个同事兴奋地和我说,他获得了一项新技能,只用最简单的横向越权手段,就通

《 软件测试价值提升之路》——1.4 微软的软件测试

1.4 微软的软件测试 微软的软件研发特征是:典型的大型传统软件企业,软件完成后完全部署在用户的环境中使用(微软还有必应.Skype.OneDrive等自运营产品,这些不在本节考虑之内),版本发布周期半年甚至更长,产品有非常好的继承性,十分注重在发布前排除软件缺陷.属于领域老大,开发内容不由客户需求主导.开发测试比是1∶2(裁员之前),这个比例在测试领域家喻户晓,也常常成为很多测试经理艳羡微软测试的主要原因.但这个比例真正的含义是,微软的测试工程师一定承担了很大的责任,因为开发测试比完全取决于公

《 软件测试价值提升之路》——1.5 腾讯的软件测试

1.5 腾讯的软件测试 腾讯的软件研发特征是:典型的互联网企业,产品完全是自运营,以周或者更短的周期发布版本.有追求快的新业务,也有平台性质的QQ.需求的提出并非客户主导.属于领域的领先者但并非先驱,所以快是首要要求.开发测试比是3∶1.这是电商产品线的比例情况,其他产品的测试团队以前也类似,但近年收缩,外包的比例加大.测试职位的名称:TE.TE既做测试也做工具,主要职责如下:1)在业务上线之前尽可能地发现导致商业目标无法达成的缺陷.比如业务不能正确工作,正常完成操作很困难,性能极差等,如果在计

《 软件测试价值提升之路》——第1章 Chapter 1 他山之石 1.1 测试困局

第1部分 引 子测试工作是否有价值,这似乎是一个不值得讨论的问题,因为几乎所有的软件公司都有测试团队,既然一个以盈利为目的的组织,舍得为了测试进行投资,那么测试工作就一定是有价值的.但是另一方面,无论是从业界了解的情况,还是从我们测试团队自身看,测试工程师转行的比例都高于同级别的开发工程师和系统工程师,这些转行的测试工程师在新的职业道路上大多获得了更高职位.更好的发展.这说明他们在测试岗位上的发展受阻,并非由于自身的素质和能力造成的,很可能是由于工作的价值没有得到肯定.测试的工作大多数是属于破坏

《 软件测试价值提升之路》——1.3 谷歌的软件测试

1.3 谷歌的软件测试 谷歌的软件研发特征是:典型的互联网企业,产品完全是自运营,以周或者更短的周期发布版本.有创新型.实验性质的新业务,也有平台性质的搜索引擎.需求的提出并非客户主导.开发测试比是20∶1.这个数据从很多渠道都可以看到,曾有产品研发经理用这个数据"鞭策"测试经理,说测试应该提升能力.但是测试最应该提升的是能力吗?不是,是定位.测试职位的名称:SDET(软件开发工程师,测试方向).在谷歌,这些人的主要职责不是功能测试设计.执行以及自动化实现,而是以下几点:1)帮助开发更

《 软件测试价值提升之路》——2.4 寻找价值的最佳人选是自己

2.4 寻找价值的最佳人选是自己 企业调整测试投资的根本原因通常是:减少年度操作成本,加速上市,提高产品质量和服务,保证与法律.法规的一致.但是以下内容经常以问题的形式抛给测试团队:测试结果数据不完整,测试结果和客户使用的感知不一致.测试的结论是功能正确了,但是到客户那里有基本功能验收不通过:测试说性能能达到100,但客户说到60就不能用了.在这些情况下,最直接的反应就是,产品到底有没有经过测试!测试工程师就算有千百条理由去解释发生偏差的原因,都会显得苍白无力,如果发生的概率高,就会直接导致客户

《 软件测试价值提升之路》——2.2 匹配新的业务要求

2.2 匹配新的业务要求 这些年软件发生了什么变化?前面的章节已经提到,软件的应用已经从特定的行业渗透到了各行各业,包括日常生活.软件的用户已经由专业人员扩展到了社会上的每一个人.所以对于软件至少有以下几个特点是需要测试去适应的: 推出快.这是一个快鱼吃慢鱼的时代,即使产品面对的是行业市场,也会面临着客户今天想出来的主意,明天就想看到东西的紧迫感.所以以前的软件公司要过CMM认证,现在讲的是敏捷,而测试需要具有适应这种开发模式的工具.方法和组织结构.变化频繁.跟着用户的需求走,而不是跟着标准走,

《 软件测试价值提升之路》——3.4 随机出错

3.4 随机出错 3.4.1 问题案例 十多年前我曾经参与解决一个产品的随机问题,这个问题导致产品宕机,重启后就能正常处理业务,但是宕机在一个月内总会发生,时间不固定,也没有发现和哪些操作有关系.这个问题持续影响客户的应用长达几个月,一直无法定位解决.后来公司在面对各方的巨大压力下,暂停新特性的开发,让整个团队花了一个月的时间,终于定位了这个由于魔鬼数字引起的问题,仅仅问题重现就花了差不多3周. 这类问题典型的有:产品偶尔无规律地宕机:用户偶尔无规律地无法操作或操作出错:进行简单恢复后,不再必然