其他分享
首页 > 其他分享> > 【测试经验向】提测质量差 + `测试工期压缩,我要怎么办?

【测试经验向】提测质量差 + `测试工期压缩,我要怎么办?

作者:互联网

写下这行标题,其实我的内心是崩溃的,因为还在等待bug修复

开个玩笑,其实还好啦,作为一个快5年的测试中鸟,这点自我调节能力还是有的。

新工作入职小半年,最近其实才陆续铺开工作。那这头一个开干的项目其实就是一个很简单的营销内容小程序,大概样子就是一个极简版大众点评or马蜂窝babala...

核心无非就是前端页面展示后端接口吐出来的各种数据,但是即便如此,居然还是跟小伙伴提了100多个bug。

那么这种简单项目却问题很多,都是因为啥呢?姑且来分析分析,当做一个简单的复盘好了。

项目小盘

一、项目流程

流程上问题不大,虽说这里是个创业型公司,但是规模不算小。

另外这个项目虽然一期内容简单,但是后续要迭代的内容不少,也承担着未来营销内容的重任,所以项目流程基本上都是按规矩来的。

1. 立项 - 确定好项目核心成员
2. 排期 - 各团队负责人计划自己的工作周期
3. 测试设计 - 测试大纲设计、测试用例评审
4. 提测
5. 冒烟、正式测试、bug修改
6. 开发、UI、验收走查
7. 测试报告

虽然流程大面上没啥问题,但是细节上还是存在的,这个放到后面问题里一起说。

二、团队结构

由于公司控制正岗的HC,于是招聘了大量的外包的同事过来参与进各种项目的工作,所以这个小程序项目也不例外。

测试是1正+1外,小程序前端是2正+2外,后端系统(接口服务+后台系统)算是3正+3外,项目周期从立项到预计上线是1个月多点。所以,结合人力和周期来看,应该还是比较宽裕的。

那么都存在哪些其他问题呢?

三、问题梳理

1. 需求层面

唯一一点我要吐槽的就是PM希望提前2天上线的事情了。理由在我这是站不住脚的,但是呢由于这初版不会正式投入使用,而且当时看这个测试情况应该问题不大,所以故没做过多计较。

其他因为需求经常变化导致后面开发返工这事情倒是基本没有,所以并不是需求层面的问题导致了开发工期不够,而问题剧增。更何况压缩的也测试的时间。

2. 开发层面

这里可就是我要重点吐槽的部分了。

问题这么多,归根结底还是因为开发的代码质量太烂

从提的bug问题来分析,这些烂代码的开发人员画像是这样的:

1. 需求理不清,就写功能
2. PRD、UE、UI相关文档不管画的如何(虽然有的错误一眼就看出来不通顺),照着实现就行
3. 开发完成了,联调仅发现可以展示数据了即可
4. 修改完bug,不自测
5. bug改一增二
6. 遇到不会的开发问题,不能及时抛出风险
...

所以就前 5 项来说,起码可以说明这个小伙责任心不强,或者说职业素养不够。

置于第六项嘛着实令人头疼。你经验欠缺个人能力不够倒也情有可原,你倒是问啊,一个问题自己吭哧搞1天都等着呢,最后告诉大家搞不定需要支援。。。

个人能力差+态度不认真这两个大头都占齐了,能写出好代码才怪了,后续估计会考虑换掉这批外包开发人员。

另外就是部分开发的接口、后台功能都有不同程度的延期,故导致原先计划好的接口测试也不能充分的进行。

3. 测试层面

吐槽完开发,说说自己这块吧。

我觉得首先要说的,可能是测试准入门槛放的低了,但是目前阶段也是不得已而为之。毕竟大家第一次合作,还不知道具体如何,项目还是要往下走,最重要的是这个项目1期不会正式使用,所以相对放宽了些。

接口测试部分测试的不充分,这主要原因还是因为开发提测延期,所以大多只测试了单接口的逻辑。考虑到最终还是会结合页面功能全量测试,所以这里问题也不大。

再有一点的话,可能还是我过于操心了一些事情,包括bug精准定位,沟通协调等。

四、问题解决方法

综上来看,其实这种还算是比较典型的问题了:提测质量差 + 测试工期压缩`,相信很多小伙伴之前多少也遇到过,下面来说说我的看法。

1. 对于提测质量差

当你知晓目前开发团队的整体提测质量很差时,那后续就可以适当的提高准入门槛。

因地制宜,比如提前进行接口测试、或者代码能力强的直接可以走查开发代码。小程序这种项目也可以提前申请项目代码权限,在本地运行起来,看看页面数据,UI样式等等。

本次由于使用在线Excel来记录跟踪处理问题,所以也一定程度的降低了效率。原因是jira要被替换,所以就准备后续直接在新系统里进行项目跟踪。那么这时候,你提的bug要确保对应的开发已经关注到了,阻塞类问题一定要尽快修复。

2. 对于测试工期压缩

其实对于压缩测试工期的情况,首先我们要进行合理的评估,到底能不能压缩,风险如何。

我之所以同意压缩,主要是考虑到一期项目简单也不会立即投入使用,而且大多数问题也是页面数据呈现,UI交互样式等。

可以把目前的问题核心、风险点都整理出来,与项目负责人确定好必须修复的问题,然后贴在大群里@所有人共同关注。

剩下的就是跟踪这些问题的修复进度,每天/几个小时(视情况而定)同步风险情况。保留好邮件\飞书等重要问题的沟通内容,以防止以后遇到扯皮的事情。

另外就不要更多的参与的bug细节中去了,更好的投入到进度和风险把控上去。

其他非核心问题也不能忘记了,要明确修复优化的时间。

五、小结

上述也只是我的一家之言,仅供参考。这些问题的类型、处理方法我觉得倒也不是什么难点。

我觉得最困难的是当我们处于项目质量这个角色上,如何能快速适应项目,把控风险点,并且运用各种方法解决或者降低风险对项目质量造成的影响,同时还要尽可能地最好对我们自身的保护。

对于此,你是怎么看的呢?欢迎大家留言讨论。

最后插播一条预告:接下来恢复pytest官方文档解读系列的更新。

这个系列有不少童鞋觉得不错,希望有更多甚至全量的解读。所以决定恢复这个系列的更新,是否会全量不一定,但是核心重要的知识点肯定不会少,有兴趣的小伙伴敬请关注。

标签:问题,项目,我要,开发,测试,提测,bug
来源: https://www.cnblogs.com/pingguo-softwaretesting/p/16637314.html