品质管理 测试报告在发版前还是发版后写

dongfanger · 2021年01月13日 · 最后由 THB 回复于 2021年01月15日 · 2189 次阅读

以前都是发版后写的,来了新公司开发提出要在发版前出个测试报告?
现状是每次发版都有大量任务没完成和 Bug 没修复。

共收到 19 条回复 时间 点赞

😂 😂 我们是每天发报告

测试报告一般是上线前发,就是保证 bug 都已关闭,已达到上线标准,然后提示一下版本的风险等;测试总结一般是上线后做,如果有生产问题,会重点分析这些生产问题,没有的话就着重总结一下这次项目的整个过程中的一些优缺点。

Jerry li 回复

这么夸张 好累

kisom 回复

每次发版三十个 Bug 没改,十几个 UserStory 没有彻底开发完,你们应该不是这个情况吧
测试报告 测试总结 这是要写 2 份文档😂

dongfanger 回复

你们是发版到生产还有 30 个 bug 没改?这样的质量上生产,这么虎的吗?还有每次这么多 bug 没改,是不是评项目的时间有问题

一般在大版本更新时才会出具测试报告(比如从 V1.0 升级到 V2.0 这种必须要有对应的测试报告,从 V1.0.0 升级到 V1.1.0,这种最好也要提供测试报告,像 V1.0.0 升级到 V1.0.1 就没必要了)。 测试报告应该是在发版前邮件发送项目经理,产品经理,开发经理及相关责任人,告知测试结果及已知风险,证明版本内容已经过测试验证,符合发布上线标准。说句难听点的,就是发布上线后出现问题,测试要担负一定责任。 测试发版后有必要的话,需要做测试分析总结,针对当前版本的测试密度、缺陷密度做数据统计,查漏补缺,为后续测试工作做提升改善。

kisom 回复

是的,初创团队,问题一堆。

Gavin 回复

现在开发想法是测试出报告,线上有问题,报告没写就是测试担责,测试写了就是开发担责。这个做法很慌

前后发都有道理,发版前发相当于是发版决策的参考依据,发版后发是整个项目包括线上质量的总结。

估计你们开发想要发版前发,期望是达到发版决策参考依据的目的,那就发版前发呗。

陈恒捷 回复

小孩子才要做选择,领导说:发版前后的报告我都要

dongfanger 回复

这事建议你和你领导好好聊聊,就算是为了抢占风口拼进度,你们这个做法也太粗糙了。应该要好好地做一下项目规划,你们可以设立一些大的时间节点,例如几月几号要正式上线对外公开这种,然后根据时间节点好好地规划一下你们的项目,而不是像你现在这样埋头瞎做,把这种质量不太过关的产品发到生产上去。

dongfanger 回复

做成模板就可以了,把 story 和 defect 新建对应的图表,每天只要把最新的图表截图放上去,然后加上当天的重点,比如有什么阻碍,有什么风险,大概就是几分钟的事情

测试通过封包后

发布前叫测试报告,发布后叫测试总结。另外任务没完发布毛线。

前:发 “测试报告”,代表测试完成,同步风险; 后:发 “上线成功报告”,代表 上线完成了,验证没问题,不用回滚 。

就测试报告而言肯定是发版前发,因为是否发版是要参考最终的测试报告内的测试结果来进行评估的,如果直接发版了还测了干啥。

Jerry li 回复

初创团队领导应该更善于做减法,而不是加法吧。不会取舍容易浪费资源。

感谢各位大佬指点。已经和几个负责人沟通了,先解决项目估时问题,把 Story 和 Bug 收敛起来,严格控制发版代码质量,借助 Jira 统计评估是否发版,当收敛到个位数,主流程回归 ok 情况下,出测试报告,澄清测试内容和遗留问题。

测试报告一般是个泛指,包括:
1、测试日报。反应每日测试执行进度以及质量风险,过程信息透明之用。
2、版本/迭代测试报告。上线前一般给出准出标准,以及质量数据即可,完整版可以上线后补充。质量数据有提测通过率、需求覆盖率、bug 修复情况、bug 趋势、测试执行完成率、bug 分布、reopen 率,还有一些上线前的 checklist(配置项审核、sql 变更申请、上线方案、回滚方案等)
3、产品质量报告。周期性与研发、产品一同复盘后输出,反应周期内版本质量情况、以及趋势;建议固定以月周期

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册