紧急情况下压缩了测试周期应该怎么办?

提问:紧急情况下压缩了测试周期应该怎么办?

  回答:本期话题分几个要素点,我将根据命题划分的几个关键词:紧急情况,压缩,测试周期,来一起分析探讨。

  项目中难免会碰到很多“紧急情况”,如:

  1、需求变更

  客户是善变的,我们必须伺候好客户,不是么?没有任何理由,他们要变更需求,一般情况下,最为乙方、丙方只有服从。

  2、项目外包

  很少有人碰到过吧?不过的确存在!项目进行到一半时由于自身团队或者高层决策、成本等方面上的要求,直接将项目外包出去,或者重新让一个项目团队接手。

  3、开发设计架构存在明显严重缺陷

  显然,架构师、项目经理等没有在前期做好评审和确认,但是很多项目,尤其是政府项目团队成员很随意,反正是有扶持款项。但这不是质量低下的理由!

  4、不确定因素造成人员减少

  如核心员工跳槽离职、女同事怀孕、家里生老病死等。

  5、客户要求提前上线

  在交付阶段,再次回到客户,他是老大,出钱的,给项目的!甲方要求提前项目上线,这不得不加快进度,不是么?

  关键点把握——“压缩”

  综合上述我列举的几个原因,在项目决策和进度上已经批复下来,我们必须得“压缩”进度安排。这里明显不存在沟通、协商的必要了,或者说与相关部门、人员沟通/协商无效了。

  但是对于我们测试团队的“测试周期”,个人认为,有必要澄清或者继续不断与相关涉众进行沟通和协商!毕竟整个周期被砍,直接最大影响的是我们测试部门同事!

  这里根据之前列举的5大理由,我会有侧重地整理下解决方案:

  1、需求一旦变更,项目团队前面阶段也肯定有影响,开发需要重新设计编码,然后才是到测试阶段。由于需求变更是客户方提出的,我们有权利去交涉争取最长“测试周期”。这里作为测试经理必须和项目经理统一战线,和客户方达成共识。因项目后期客户自身提出的临时需求变成要求,本不在合约范围内,所以综合已有的项目计划和人员安排,在强制要求“压缩”进度、或者保证原有进度的情况下,个人认为必须给客户列举出详细的测试风险和影响要素。让客户方明确在进度被压缩的前提下,我们能保证的质量效果和最佳状态!知道风险是多方面必须一起承担的。

  2、项目突然被外包给别人,有点不可思议!但是整个项目被第三方接手,这里的交接情况,主要是新项目组对需求的快速把握、理解,开发方对项目架构、设计及代码的熟悉都是不得不去考虑的。这样对于测试团对来说,只能延后开始执行测试时间点,那势必得把握测试要素的重点。个人建议按测试优先级、功能重要等级进行分类和划分,给客户方一个明确能保证质量的测试业务点清单。毕竟不可能在短时间项目被重新分包情况下,让测试团队控制什么进度来交付产品/项目。这个是整个项目进度的问题。

  3、开发设计有严重问题。这个是自己团队得承担的责任!但是也因此影响到了测试部门人员。我们在开发人员紧急处理问题时,可以同步参与单元测试接口测试等。因为已经大架构上错误了,测试人员协助开发人员一起确保系统设计、搭建没有问题,其实是不能再出问题!

  4、非受迫性减员很普遍,但是各项目组或者总的测试团队负责人/测试项目经理必须分配好冗余资源进行补充,自己得多承担责任。作为缺岗人员的备份者,更加要协调好剩余同事的任务安排,稳定军心。

  5、客户要求赶工上线,正常情况下不能保证质量是否完全可靠,同问题1,得让他们承担接受潜在风险!上线交付是个很严肃的过程,对系统功能、性能、安全、稳定性,软、硬件环境要求必须都满足上线的前提,才能正式交付,客户在计划外要求提前上线,除去自己业务方面需求,没有对项目团队有啥合理理由或者要求,我们作为测试团队,得把握其上线要求的最佳业务点,如某个功能模块一定要运行正常稳定,有侧重的去测试该部分,若他们可以接受条件的话。

  其实上述方面我还是侧重与责任方进行交流沟通!虽然已经被压缩了进度,但有些情况必须阐明,才能安心工作,对于测试部门,测试经理也有义务进行责任承担的同时,给予同事们最大程度保护!

  对于传统的加班加点,加人加米等方式,这里我其实不想多说,因为这些都是非正常的要求,才称之为“紧急情况”,所以除去那些人力、费用、资源等成本不说,在项目进度,这里主要是测试进度加快情况下,只能先理清思路,针对不同要求去协商并沟通,争取最佳的效果吧。尽可能保证项目在预期内打到理想的最好质量状态。

  我个人是没有见过被压缩进度下,又要做到很好,又要满足各种要求的!这不现实!这里只是给出最可能的、理想的、较好的处理方式和技巧而已~

时间: 2024-10-01 07:34:08

紧急情况下压缩了测试周期应该怎么办?的相关文章

紧急情况下压缩了测试周期应该怎么办

这是一个典型的项目管理中时间管理的问题,在测试过程中仍然可以应用项目管理的方法进行管理.一般碰到该问题,首先想到的是提报风险,将风险作为最高等级来汇报.并且跟各干系人左沟通右沟通,希望争取更多的时间,希望得到应有的测试周期.而结果一般来说却是风险汇报了,领导也知会了却没有任何指示,也就是按既定方针办.测试负责人死缠烂打.满地打滚也没有争取到半点额外的时间.但测试还得继续,这时候能怎么办?还能怎么办呢,加班呗,做不完也硬着头皮上呗,不然还能怎么办?这里我不是说不要汇报风险,不要去尽量沟通.而是风险

紧急情况下测试周期被压缩该如何测试?

紧急情况下测试周期被压缩在国内大多数公司都会出现这种情况,那出现这种情况该如何去面对并展开测试呢? 首先我们需要弄清楚是什么原因导致出现这种情况.到底是内部原因导致还是外部原因导致,说到底如果是外部原因导致基本都是由于需求变更引起的,内部原因通常为开发延期导致. 在下面我会列举常见的处理方法: 1.如果是需求变更导致的测试周期被压缩,那我们测试的时候必须先跟项目经理.测试经理说明该情况并得到统一的意识,并与客户沟通争取更长的软件周期. 2.如果是内部原因引起的测试周期被压缩,那我们可以通过以下方

异常情况下的Activity生命周期分析

情况1:资源相关的系统配置发生改变 资源相关的系统配置发生改变,举个栗子.当前Activity处于竖屏状态的时候突然转成横屏,系统配置发生了改变,Activity就会销毁并且重建,其onPause, onStop, onDestory均会被调用.因为实在异常情况下终止的,所以系统会调用onSaveInstanceState来保存当前Activity状态.这个方法是在onStop之前,与onPause没有固定的时序关系.当Activity重建的时候系统会把onSaveInstanceState所保

在Node.js中在保持目录结构的情况下压缩指定目录

最近在做一个文件升级的功能,需要从下载服务器中指定目录下的文件.在学习了zlib后发现这个模块达不到这个功能 在查找资料后发现后发现 archiver 模块很好用,不过我也发现大部分中文资料没有如果查询压缩进度,所以在此分享一下: archiver的github地址: https://github.com/archiverjs/node-archiver API文档地址: https://archiverjs.com/docs/ 压缩等级说明: var archive = archiver('z

Activity在异常情况下的生命周期——Android开发艺术探索笔记

欢迎转载,转载请注明出处 http://blog.csdn.net/l664675249/article/details/50638398 Activity在异常情况下的生命周期 关于Activity正常情况下的生命周期请参考这篇文章,本文主要讲解Activity在异常情况下的生命周期. 情况1:资源相关的系统配置发生改变 资源相关的系统配置发生改变,举个栗子.当前Activity处于竖屏状态的时候突然转成横屏,系统配置发生了改变,Activity就会销毁并且重建,其onPause, onSto

高并发情况下Redis 的可用性测试与分析及部署架构说明

一.Redis AOF模式设置 修改配置文件redis.conf参数: appendonly yes # appendfsync always appendfsync everysec # appendfsync no 二.测试方法 创建多线程,其中每一个线程执行一个无限循环向Redis 发送set key-value命令,由于处理器执行一次循环操作的速度非常快,因此这样每一个线程都模拟了一个多并发的情况. <span style="font-size:18px;">cla

Activity 各种情况下的生命周期总结

Situation1: 正常启动: onCreate()  →   onStart()  →  onResume(); 返回健退出: onPause()  →   onStop()  →   onDestory(); Situation2: 正常启动 : onCreate()  →   onStart   →  () onResume(); 按home健: onPause()  →   onStop(); 正常启动:onRestart()  →   onStart()   →  onResume

盘点异常情况下的紧急处理

盘点异常情况下的紧急处理: update kwkctab set kcl = (select pdl from view_kw10 where view_kw10.itemno = kwkctab.itemno and view_kw10.KW = kwkctab.KWand view_kw10.gys = kwkctab.gysand view_kw10.pdl is not null)  where kwkctab.itemno in (select itemno from view_kw1

异常情况下的生命周期分析

这里所说的异常主要是分为以下这在两种情况下的异常: 情况1.资源相关的系统配置发生改变Activity被杀死并被杀死重新创建Activity 情况2.资源内存不足导致低优先级的Activity被杀死 情况一具体: 那最简单的加载图片资源文件的机制来说,我们将图片放进drawable目录下,开发时为了兼容不同的设备,可能放的不只放在这一个目录中,还有drawable-mdpi, drawable-hdpi这些目录中,当程序启动的时候会根据设备的情况进行加载合适的图片资源,比如手机的横屏向竖屏进行切