《 软件测试价值提升之路》——1.7 优秀软件公司测试团队职责的启示

1.7 优秀软件公司测试团队职责的启示

总结以上典型软件公司的测试团队职责见表1-1。

通过这些软件公司的测试团队职责,可以看出以下几点:
1)产品的特点和测试的职责有关:如果产品是自运营的,首先,用户使用问题可以第一时间反馈到研发团队;其次,研发团队可以通过灰度发布、沙箱等手段控制缺陷的影响范围,降低缺陷的风险;最后,修改缺陷以后,上线的过程不会太繁琐。缺陷生存的时间较短,可以容忍一部分缺陷在产品上线之后被客户发现。因此自运营的产品研发团队对功能缺陷并不十分敏感,也没有强调测试应该保障质量。这些测试团队通常具有较强的工程能力,能够帮助产品在保证基本功能正确的前提下,尽可能快速地发布产品,有些团队还在“更快获知客户的问题和体验”上进行创新,帮助提升运营维护的效率。
如果产品是客户运营的,研发团队和产品用户之间的联系比较弱,产品缺陷的反馈、确认和修改的链条比较长,产品发布后发现的缺陷,其修复成本会很高。因此研发团队强调测试应该保障质量,尽可能减少发布产品的缺陷,降低研发和维护的成本。
2)测试团队规模和测试的职责有关:以产品日常的功能测试为主要职责的团队,无论是否肩负了“保障质量”的职责,都会需要比较多的测试工程师。而只要做产品日常的测试,无论能覆盖的范围、能达到的深度是什么,都或多或少地承担了质量目标。
3)测试工具开发测试是测试团队绕不过去的工作:并非所有的测试团队都以产品日常的测试为主要职责,但几乎所有的测试团队都进行工具的开发,无论是为了解决测试手段,还是为了提升效率。在测试的工作中总是会发现:要不就是没有合适的工具;要不就是现有的工具还需要一些二次开发,总之,每个测试工程师都需要一定的工具开发能力。

时间: 2024-10-25 17:36:35

《 软件测试价值提升之路》——1.7 优秀软件公司测试团队职责的启示的相关文章

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

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

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

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

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

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

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

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

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

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

《 软件测试价值提升之路》——3.2 正常使用中部分出错

3.2 正常使用中部分出错 3.2.1 问题案例 我们的产品中遇到的大部分客户问题都属于此类.例如: 某产品的客户端是运行在浏览器上的,支持IE8.IE9.Firefox,但是经常出现某些页面在其中一款浏览器上显示不全或者错位等问题,有个产品由于问题太多,以至于不再支持Firefox.对于移动应用,最常见的是APP在某个终端品牌或操作系统版本上不能正常使用. 某产品新版本逐渐替换老版本的过程中,客户开始使用时都没有发现问题,到某个客户那里突然和原有的功能不兼容.分析发现某个接口字段的合法取值是0

《 软件测试价值提升之路》——第3章 拦截缺陷 3.1 用户无法正常使用

第2部分 扫 门 前 雪作为一个测试团队,基本的职责是:测试产品,发现缺陷,报告结果,使每个版本的测试水准稳步提升.这些价值是作为一个测试所必须具备的,发挥这些价值能够让测试获得研发团队的基本信任.这类价值分为3部分:1)拦截缺陷,即对产品进行测试,尽可能把产品的缺陷拦截在研发阶段.2)提供数据,即提供产品的质量结论,并且给出支撑这些结论的数据.3)测试过程可控,提升测试团队和测试工程师的能力,使得产品测试的效率.质量.成本都处于可控状态."扫门前雪"说明这些价值基本上是测试的本职工作

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

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

《 软件测试价值提升之路》——第2章 价值实现的起点 2.1 首先打破一些常规

第2章 Chapter 2 价值实现的起点 为了实现新的价值,测试工程师首先需要改变观念.看清环境.本章将要讨论的是,打破哪些已经不适应现在软件开发需要的"准则",明确需要在什么样的环境下.瞄准什么目标来实现测试的价值. 2.1 首先打破一些常规 在讨论测试的价值的时候,首先需要破除一些"成见".这些思维逻辑从测试成为一个职业起就一直存在于测试工程师的潜意识里,但是这些逻辑也是在寻求测试新价值时的障碍.测试是测试团队的事.这里不准备论证开发也要做测试,而是说需要打开