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

 

写下这行标题，其实我的内心是崩溃的，因为还在等待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细节中去了，更好的投入到进度和风险把控上去。

• 明确剩余问题的修复安排

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

五、小结

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

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

学习安排上

作为一位过来人也是希望大家少走一些弯路，在这里我给大家分享一些软件自动化测试的学习资源，希望能给你前进的路上带来帮助。【无套路免费白嫖】

视频文档获取方式：

这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。