大家平常调侃开发，又去写bug了，虽然是一句玩笑话，但是世界上真的存在没有bug的程序吗，不知道，最近看到一个段子写的特别的好，一天一个程序员在加班加点的写东西，然后佛看到了，对程序员说，看你很辛苦，天天加班加点的写东西，我可以满足你一个愿望，然后程序员就许愿了，说，希望在我有生之年可以写出一个没有bug的程序，然后这个程序员就得到了永生。这虽然是一个段子，但细细品味，难道真的开发和测试就是水火不能相融吗？
最近实在看不惯公司的开发流程了，因为刚上线了一个版本，线上暴露出来的问题比较多，不得不暂停这版本的上线，发回重测试，纠其原因，我觉得需要从以下几个方面分析
一，站在开发的角度来讲，开发一直有新的开发任务，还要去改测试提交的问题，可能有些开发任务不是很明白，还有测试提交的bug可能描述的也不是很清楚，还要找问题，然后改问题，一般找到问题后就把这个bug改掉，至于涉及到的其他模块是否有影响，不管了，可能也不是自己开发的，看不明白，再就是时间丢给测试去测吧，到时候测出来再改吧，先完成自己其他的开发任务
二，站在测试的角度来讲，提测后，要执行测试任务，发现bug,要不断的重试多次，确定是个bug,然后分析原因，和开发沟通，确认是bug,然后提交给开发，催着开发改，改完之后打包再次验证测试，而且每次发了以后，直接丢给测试，从来不会深入的多看几影响的其他模块功能，看是否有其他影响，每次测试去问影响范围，测试范围的时候，就一句话，全量测试，但是测试同一个东西天天测试，疲于重复繁琐的工作，而且由于开发的懒，只改了一处或者就每改好发包，让测试，这时候是很消耗时间的，而且效率低下，每发一次包，需要造好多数据再验证，而且有些问题还不好重现，再就是回归后，如果时间紧张，涉及其他的也懒得看，主要是因为也不知道涉及到哪些，影响到哪些，如果时间允许的话，当然可以去好好的测试一番，而且测试遇到最烦的不是这，而是发现一个问题，给开发，开发说这我不知道，别人传给我的，那谁传给你的，你有得去找，一个一个找，等把对应的开发找出来的时候，黄花菜都凉了，他们只关系局部，不关心整体，这也就是为什么公司测试是最懂业务的，这就导致了一个bug,页面把底层的异常给抛到页面了，每个人去调用底层方法，都懒得处理异常，遇到异常，一直往上抛，跑到最上面，没处理好，直接就爆发出来了
三，站在产品的角度来讲，因为客户现场，千奇百怪的需求一堆，而且要顶着上级领导的压力，不断的创新，迎合快速响应市场的变化，不断更改需求，所以需求是一个变动的过程但是这个下来后开发要改，要重构，修改之前的，测试也要重新去测试，修改对应的用例，所以整体来讲，源头还是产品这块，公司一定要加大产品投入，再设计产品的初期就把需求多想想，多思考，尽量变更较少，而不是一直再变，在产品开发的过程当中，如果再改需求，那带来一连锁的反应，造成后续的工作量是成倍增加的，
这是个矛盾体，怎么解决，开发和测试不是仇人，不是对立面，一切的源头都是产品这块，但是产品也很无奈，客户要求改如果开发强势，产品不敢提需求，测试不敢提bug,试问那么做出了的产品是一个什么样子
其实我一直思考，怎么提高工作效率，觉得其实产品不是测出来的，真的是管理起来的，如果一个公司现在开发完产品就丢给测试，觉得自己的工作完成了，觉得出了问题都是测试没有测出来，那么这个团队是有问题的，因为没有形成良好的闭环，大家没有质量意识，完全是靠别人，开发靠测试，产品也等着靠测试，那测试靠谁，只能不断的提交自己的能力，不断加班，上线担惊受怕，就怕出问题，这样是有问题的，整个项目流程是有问题的，不然的话，怎么会出现项目管理这门学科，专门去研究呢。