你是否也通过这样的灵魂拷问：「开发的功用不都是通过上线测验的吗？为什么上线后还会那么多 Bug ？」。
咱们分明都很尽力，为什么「输出」的作用没有更进一步？今日咱们就水一水这个「狗血」论题，究竟是谁个锅？
本篇只是毫无意义的「故事」，内容纯属「虚构」，如有雷同，自己「反思」。
关于这个论题，我想用一个「虚构」的故事来介绍下，这个故事里我有一个「朋友」，他在某电商项目组，当时恰逢经历了公司内部的「双十一需求立项」：
立项时
老板：“这次的需求很简单，首要便是参阅上一年 TB 的预热活动来走，中心便是进步客单量和活泼，详细细节你们和产品交流就行”
产品：“TB 上一年的活动预热咱们应该都了解吧，咱们这次首要便是复刻一个类似的活动，时刻一个月，详细有***，总的来说，双十一活动一定要按时上线，这次运营那儿投入很多经费，需求方面我会把控好，中心围绕老板的思路，细节咱们能够看文档，底子便是这些内容，一个月应该够的，咱们没问题吧？”
开发：“没问题，保证完结任务”
3 天后：
老板：“我刚看了 JD 如同推出了一个不错的小游戏，我觉得这个能够导入到这边活动里，这样能够进步用户的活泼，用户活泼了，消费天然就起来了”
开会
产品：“鉴于老板的定见，我觉得 JD 的这个游戏活动作用能够提高咱们的复购，所以我计划在本来需求基础上添加一个支线活动。
产品：“咱们不要紧张，支线会和当前主线同步开发，支线活动比较灵敏，不对账号级别做约束，别的「规划」那儿看下进口放哪里比较适宜。”
开发：“上线时刻仍是没变吗？”
产品：“双十一日期会变吗？老板说了咱们抓紧点，功用不多，时刻仍是够的”
10 天后：
老板：“我刚和x总交流了下，他觉得咱们的活动少了互动，不利于留存，你看下怎样处理”
开会
产品：“通过这几天和老板的讨论，咱们发现这次活动少了一些互动性，必须添加一些交互游戏，这样才干提高日活和用户体会。
产品：“这样吧，这部分功用也是比较迫切，我知道任务比较重，可是为了这次能取到较好作用，咱们加把劲，接下来周末幸苦下咱们，先不休假，后面调休补回来，详细需求咱们能够看文档，有一些调整，不多，时刻仍是够的”
开发：“。。。。”
14 天后：
老板：“我看咱们工作的热情仍是能够的，刚运营提了能够添加一些视频支持，我觉得这是一个很好的定见”
开会
产品：“现在看起来咱们的开发进度还比较达观，运营的同学说了他们录制了一些活动视频，我看了还不错，就在主会场添加一些视频播映的功用吧，细节你们直接和规划讨论下”
产品：“这个应该不难吧，把分享和下载加上，视频播映这么基础的东西，应该不耽误事，我看网上开源服务就挺多的。”
开发：“。。。。”
20 天后：
老板：“我刚去开发那里看了下作用，感觉分会场的作用挺好的，做支线太惋惜了，给他加回主流程里”
开会
产品：“老板那儿觉得分会场的作用更好，让咱们把分会场的作用做到主会场里的中心交互里，分会场部分的逻辑就不要了，进口也取消。
产品：“咱们不要激动，都是现成的东西，改一改很快的，不过项目进度现在看来的确起有点拉垮，接下来咱们晚上多幸苦点，咱们晚上11点后再下班，我申请给咱们报销打车的费用”
开发：“。。。。”
23 天后：
老板：“整体作用我觉得能够，便是如同有一些糙，你们再过一过，别的咱们开个会统一下方针，看看能不能有新的补充”
产品：“能够的，曩昔咱们也一向在开会对齐，底子每两天都会对齐一次”
开会
产品：“我和规划对了下，发现有一些细节能够优化，比如一些模块的颜色能够细调一下，还有这些按键的动画作用也加上，我知道工期紧张，所以我从「近邻」项目组借了几个开发资源，未来一周他们能够协助咱们缓解下压力”
开发：“。。。。”
28 天后：
开会
产品：“好了，项目能够提测了，信任之前测验也陆续介入跟进了需求，应该问题不大，现在看起来「燃尽图」还能够，测验完了赶快上线，老板那儿也在催了”
测验：“不可啊，今日走了用例，一堆问题，并且提测版别怎样和用例还有需求文档不一致，这个提测的版别开发是不是自己没做过测验啊，一大堆问题，底子测不下去，这样咱们很难做”
产品：“这个我来交流，开发接下来这几天咱们就不要回家了，马上活动上线，一起攻克难关”
产品：“我也了解咱们很尽力了，可是这次提测的质量的确不可，你们仍是要自己多把把关，不能什么问题都比及 QA 阶段才暴露，这样不利于项目进度，需求一向都很明确，咱们把 Bug 尽可能修一修，有什么问题咱们及时交流，赶快处理，敏捷开发”
开发：“。。。。”
上线前一天晚上 10 点：
开会
测验：“不可，还有 20 几个问题没有承认，这种状况我不能签字，上线了有问题谁负责。”
产品：“一些问题其实并不影响正常运用，现在主流程应该没问题，让开发把 P0 的两个问题修了之后先上线，剩余的在运营过程中逐渐更新就好了，有问题让运营先收集和安抚”
开发：“上线了脏数据不好弄，会有一些账号同步的问题，并且用户等级可能还有坑”
产品：“没什么不好弄的，到时候有问题的用户让运营做个标志，接下来小步快跑修复就好了，时刻不等人，明日便是上线时刻， 活动上不去对老板和运营都没办法交代”
项目上线：
老板：“运营和我反应了好多问题，你们版别上线是怎样测验的，要反思一下xxxx”
开会
产品：“我说过用户要集齐碎片和好友砍价之后才干给优惠券，等级不行的不让他们砍价成功，为什么只完结砍价的新人拿到大额优惠券？”
产品：“什么？由于账号数据绑定有 Bug ，不同途径用户兼并账号就能够满足？为什么会有这个 Bug ，测验那儿没覆盖到吗？”
测验：“我不知道啊，需求文档没有说还能账号兼并，并且这个功用之前没说过要约束用户等级吧？”
产品：“我出的需求必定有，文档里必定有，别的开发你已然知道问题，为什么不提前交流，现在用户都消费了，这个事端你和测验 55 责，后面复盘的时候要避免这样的问题再次发生”
开发：“。。。。。”
最终
所以咱们觉得是谁应该背锅？是开发的能力不行，仍是测验用例的覆盖缺失？说起来，其实在此之前，我在掘金也遇到了一个 “Bug” ，比如：
文章 Markdown 里图片链接的
content-type字段如果不符合image/***规格，那么发布出来的时候链接就不会被掘金转码，所以不会有图片水印，同时直接指向了我自己的图床地址。
那么你觉得这个是 Bug 吗？分明是用户不遵循标准。可是这样不就留下缝隙了吗？
如果在文章审阅通过之后，我修改图床上的图片内容，这样不就能够绕过审阅在掘金展示一些「违规」内容了吗？
所以有时候一些功用的初衷是好的，可是引发的问题却又很隐蔽，那么这能怪「测验用例覆盖不到位吗」？
那么，你觉得「通过测验，为什么上线后还会那么多 Bug 」更多可能是谁的问题？
