最近的项目，测的有点脑阔疼。
一、项目背景
项目A偏服务器底层开发，开发人员没有相关经验，都处于摸索中。
开发人员的日常工作包含该系统的开发+运维工作。
开发人员3个，两个后端，一个前端。
测试人员两个。
本季度开发KPI已定（测试的KPI与之无关），六月底上线，否则扣钱。
前期定的方案是测试提前介入，先测接口，正式提测后，测试页面。
二、提测情况
一个小迭代，Bug数多达36个，本次的功能点不多，但是质量差。
测试提前一星期介入，进度几乎为0，天天配合开发联调。
正式提测之后，开发几乎只完成了70%的功能，很多是页面上可以设置，但是实际接口未生效的那种。
很多页面实现的与原型不一致，产品也没有及时修改文档，表示大致差不多就行。
三、最终上线方案
产品负责人拍板：只保证核心功能正常，其他功能大致看看，上线后可继续测试。
测试报告只写明已经测试的功能点，未测试的不写，并抛出风险点。
四、复盘下该过程
问题：时间紧+质量不达标+为了KPI必须上线，测试同学怎么做？后续怎么避免类似的问题?
结果：测试报告标注已测试点，并抛出风险点，邮件抄送给负责人，上线后继续测试。
后续如何避免该问题？
从测试人员的角度：
1、前期多介入，积极推动项目进展。
在介入接口测试的时候，基本情况是测试一个接口-->不通-->开发修复-->通了。
测试第二个接口-->不通-->开发修复-->通了。
测试第三个接口，需要调用第一个接口，发现第一个接口不通了，再让开发修复第一个接口。
就这样循环了一个星期，大致功能接口才通。
前期要是加把劲，催催开发，后续就不会压缩测试的时间。
2、规范流程。
理论上，每次提测之前，我们会有个冒烟测试演示，即开发，测试，产品约个会议室，由测试同学现场测试提测的主体功能。
如果太多Bug，是要被打回的。
但是这次，因为提前介入测试接口，打乱了这个流程。
其实，功能仅仅完成了70%就提测了，很多接口都没写完，都是边测边完善的。
从开发人员的角度：
1、合理评估时间，学会向上汇报。
此次的评估时间是在正常情况下，可以完成的任务。
但是中间停了2次电，每次停电，运维至少花3整天的时间，去处理各种环境问题。
但是处理完成之后，项目开发时间不够，开发组长也没有向领导汇报。
而是默默带着成员死加班，经常十一二点的那种。
理论上，这种情况向领导申请更多的时间，领导是可以理解的。
2、提测质量有待提高。
分析了下36个Bug的类型，很多并不是1级或2级Bug。
大多是比较简单的Bug，例如格式不对，翻页报错，功能未完成等等。
只要稍微用点心，这些Bug是完全可以避免的。
从产品人员的角度：
1、PRD需要及时更新。
在项目开发过程中，开发与产品决定砍掉了一些功能，但是产品原型未及时更新。
导致测试过程中，边测试边确认需求，极大地增加了沟通成本。
2、 学习做减法， 砍需求。
在前两期的项目中，都出现了规划很多需求，最后几乎只完成60%功能的情况。
在后面的项目中，未及时调整，应该砍掉非重要功能，保证核心功能。
ps：我是lc馨馨紫，全网名称统一，期待优秀的你关注我~
原创文章，转载请注明出处~
网友评论