【测试经验向】提测质量差 + `测试工期压缩，我要怎么办？
作者：互联网
写下这行标题，其实我的内心是崩溃的，因为还在等待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