写下这行标题，其实我的内心是崩溃的，因为还在等待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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。