庆贺第一个版本

在经历了两周最早10点,最晚1点的艰苦奋战之后,终于集成了一个版本,它包含一半多功能(总共有9个业务组件,业务组件之间项目独立又相互耦合,研发人员总数在170个以上,牵扯到5个二级部门,分3个项目来协作),顺利完成功能自测并提交功能测试,当然不可能一点问题都没有,还遗留一些小问题,不过这些小问题相对于成功来说,已经是微不足道了;

这中间经历了种种问题,回忆起来也是感慨万千;

1/2早上突然说需要基于上周的版本集成新的3个组件,而这3个组件中有一个组件是节前刚刚编码完的,连前后端都没有连调完。一周要完成前后端联调、业务联调以及功能自测并完成版本提交还是有一些困难的。而其他两个组件虽然上周在其它项目被集成过,但与我们的项目集成还是存在部分改动的,总体上看,集成的决策略显急促。会上项目经理反对拿这些版本统一集成并提交转测,并建议先把自测和集成两个过程分开,集成还是安排,但集成的结果不提交转发,线下安排研发先对未自测的功能进行自测,并按照原计划每个组件各自提交各自的测试计划,统一集成测试放到下下周,建议被领导否决,计划不变,3个组件本周完成集成并提交转测,同时细化了周计划,在周三完成第一个版本的集成,并完成环境搭建,研发人员在周四和周五基于周三搭建的环境进行功能自测和修改阻塞性缺陷,并在周五晚上完成第二个版本的集成和环境搭建,周六再基于周五搭建的环境进行基本功能回归,回归没有问题之后提交转测申请。期间讨论了采用什么粒度自测用例以及谁来执行的讨论,最终确认测试用例由测试同事进行梳理,梳理出主体功能用例供研发人员使用,转测提交前要把自测报告提交上来。

1/3早上,项目经理开完早会,明确集成包的范围,通知邮件往外一发,邮件中说明了收包范围的策略,但是直接给了结论,还有就是犯了一个基本的问题,结论没有与相关责任人沟通,没有与一个项目的项目经理沟通策略,他们项目进度快,有一套相对比较细的体制来保障质量,而我们整体相对较慢,时间资源比较赶,验证机制就相对较粗一些,如用例的粗细程度会偏粗,整体上也没有统一的要求,以各个组件自己识别为准,这两者之间差异导致他们对安排不太满意,需要再明确下范围以及细节和责任人。归纳总结起来说,我们自测以研发验收为准,用例研发自己来写,只要求保证主体功能即可,而他们验证会有两种机制来保障,接口自动化和测试人员验证,两边的认知存在冲突,且他们想按照他们的模式来约束整个项目。本身从做事情方式上看,他们的方式更加合理,但机制要结合当前的实际情况来看,我觉得研发自测更符合当前比较紧张的情况,只有2天时间还需要进行团队之间的切换,效率可想而知,同时主要约定好检测的用例,执行对象测试人员和研发之间研发会更好一些,第一用例是主体功能,比较粗,研发也熟悉,不存在遗漏;第二,研发自测修改问题效率会更高,减少两个团队之间沟通,节省时间。最终确认,明天和后天的测试有条件的有测试人员来完成,没条件的测试和研发一起完成,能保证完成即可。

晚上9点45,要求的业务组件完成了功能自检,提交了安装包,但是出现安装包的无法安装的事情,在2个小时之后还是无法解决,总结原因明天与相关领导再确认改进措施。凌晨1点多,安装包终于安装起来,环境搭建完成,虽然还有些小问题,但也算是初步集成起来了。

1/4,与责任人明确今天的目标,基于昨晚的环境进行功能自测,晚上要提交自测报告,今天都是研发的问题,主要的问题是环境的不稳定,研发集成之间的问题较多,至于问题原因,心里已经有预期,但是事后复盘还是要准备,下周复盘了再总结。

1/5 14点,最后的版本集成开始,结果安装包程序由出现了问题,连续安装了5次才成功,成功后对问题进行了总结,下午单独约负责该项工作的总监,预约晚上谈下改进计划。在验证过程中,环境不稳定的情况依旧,各个组件频繁更新包,根本无法管控,只能由各个组件进行汇总,然后复盘时在开发过程中改善。由于安装失败的问题,导致晚上计划顺延2个板小时,不过进度还算正常,完成了单日的目标。

1/6 14点,有研发反馈一个牵扯范围很广的A组件必须要更新,否则无法使用。马上安排该A组件更新,更新之后马上进行验证,1.5个小时之后,安装完成,验证通过,这时最终的更新包也已经陆续上来,在这个环境上对更新的包进行了逐一更新。替换完发现菜单没有了,A组件的同事马上排查问题,半个小时之后排查出来说是底层B服务返回的菜单信息是空的,半个小时后B组件排查结果是安装方式上存在这个问题,一时半会难以解决且一旦更新B组件,应用很多测试通过的功能需要重新做,权衡风险和利弊之后,先用安装包的方式进行统一安装,下午16:30总算完成了一套可用的环境。晚上21:30各个业务组件反馈还有些缺陷需要更新,这时更新的范围项目经理进行了管控,对严重的问题进行了放行,小问题遗留到下周的迭代,自测完整后再提交,再次更新之后进行回归,23点45,所有组件主体功能回归完成,遗留8个问题,因为有些部门不在一个办公区域的同事(下午再三沟通要晚点回去等提交后再下班)已经离开,无法排查,只能当做遗留问题处理,版本提交转测。

最明显的问题有两个,基础功能的不稳定导致其它同事的等待,以及反复更新反复验证的重复性工作,软件有它自身的一个规律,靠人堆来压缩时间不一定能达到事半功倍的效果。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值