测试管理 大家对功能分批提测有什么看法?

wallace · January 18, 2019 · Last by lileilei replied at January 22, 2019 · 1768 hits

最近有个和客户合作的项目由于客户要的非常紧急,所以产品想尽快上线提出在开发没有整体完成的情况下分批提测功能,但我是比较排斥分批提测的,原因如下:

1.如果已经提测的功能和未提测的功能有交互,那么未提测功能的改动会影响已经提测的功能。
2.客户的系统没有区分开发环境和测试环境,所以只能和公司的某一个环境交互。如果是开发环境,那么QA在测试环境没法对整个功能做闭环测试,因为需要向客户的系统同步数据;如果是测试环境,那么RD没法在开发环境开发未提测的功能。
3.在没有整体提测的情况下提bug,RD是比较抗拒的,容易产生摩擦,但是不提bug又体现不出QA的工作成果。

请问大家对功能分批提测有什么看法?

共收到 12 条回复 时间 点赞

我们一直是分批提测。服务端和客户端各自测试。等客雾端和服雾端联调完成后,再做集成测试。

恒温 回复

和楼主说的分批提测不太一样吧。楼主说的应该是客户端有五个功能,第一轮提测前两个,第二轮修bug+提测第三四个,等等等

恒温 回复

服务端和客户端测试人员是两拨人吗?

下面是我们的一个流程,供参考

提前介入测试流程

  • 开发做完一个需求,需求的状态改为:编码结束,已送内评

  • 测试组对 编码结束,已送内评 的需求提前介入测试,每天花少量时间(暂定 1 小时)进行验收冒烟测试,提交发现的阻塞性、未实现的 bug。并提醒开发修复。 其他严重的、普通的缺陷只记录 Redmine,正式提测后开发再修复

  • 冒烟测试通过后,需求状态改为:内评通过,已送测试

目标

正式提测前,阻塞性、未实现的 bug,全部修复

分批测试有什么问题呢? 如果所有模块一起提测,你就不用分先后顺序了吗?
项目时间紧的情况下,相对于全部一起提,分批提测下测试执行的时间更为充足。相对于提前介入了

kawa 回复

类似的

分批提测理论上是可以提高交付速度分批提测 分批验证 分批UAT 提高并行度 但是需要需求分解好 同时沟通频率也加大 测试工作量是提高了的 环境问题吗 能做的还是需要基础设施能力 挑战肯定是加大了 能不能快只能说看能力 都说不准 如果马上试肯定会有点混乱的

我们也一直提倡分批提测,理论上一个完整的story完成就可以提测,被依赖的story优先提测,这样比整体提测的效率高很多

国内所谓的敏捷不就是这种节奏么,我们公司一直都是这样,但是环境还好都是开发和测试都是分开的

分批提测,拥抱敏捷吧。
不过大多数公司身处瀑布追求敏捷,结果可能不太理想。

如果贵司的CI、冒烟和以及接口自动化到位,我觉得可以尝试去分批测试。
如果没有达到敏捷的条件,确实可能需要整体交付一个版本后统一测试、再修复、在测试。。。。。。

谢谢大家的回复,看来在环境,流程,能力都满足的情况下,大家对部分提测还是持赞成意见的。

我们之前这么做过,是APP, 也是分开模块提测,开发可以分开模块提测,但是过程中bug全部记录,后期相关模块提测再去验证,最后一周集成测试,这个流程是开发率先提出来的,我们当时 每天进行站立会。来碰头进度。推动各个环节的协作。这种模式在快速开发,快速交付过程中我感觉很普遍的做法。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up