足球场上22个球员比拼，20个人只准用脚，两个门将则可以手脚并用，真爽！但踢过一段时间以后，才知道门将苦矣！特别是当你的10名队友水平比较、甚或相当“菜鸟”的时候。整场比赛高接低挡外加提心吊胆，身累心更累！更惨的事儿是在输球以后，那些锋无力、守无能、中场不会抢截的家伙，竟然还把矛头齐刷刷地对准了你——天理何在啊！
同理，测试的窘境在于作为上线前的最后一环，那些分工不合理、管理混乱所造成的时间风险、版本质量问题最终总会压到你头上，如果你默默承担了下来，耗费时间解决了，那么大家对你交口称赞，然后重复着以前混沌的模式，如果你不幸扛不住了，那么大家又会指责你为什么bug都测不出来。这种境遇很多时候要怪测试自己，虽然很多要求并不合理，但还是本着不要同归于尽的想法去挽救，但是救得了一次，能救得了所有么，扑除了一个点球，后卫再送几个，还能这么幸运扑出来么。我有几次也很懊恼，每次想着就这样测一下同归于尽吧，最后还是心软了，所以测试同学内心都很善良啊。
颠覆下三观，对目前传统的测试方式和思想，采取反其道而行之是不是更好呢：
1.避免出现线上问题——有时候出点小问题也蛮好
以前刚工作的时候，怕漏测怕的要死，结果first boold以后，内心就淡然了，就像从小没挂过科，大学挂了马哲，以为天要塌下来了结果也就那样了。不要害怕出问题，该暴露的问题就应该暴露。一些项目晃晃悠悠的应该出点什么事，然而就是没发生点啥，让大家误把运气当作了实力，盲目自信，还不如出点啥事让大家醒悟一下。该出的事故不如早点出，勉强是没有幸福的。最强的开发模式一定是ADD(ACCIDENT DRIVER DEVELOP) 事故驱动开发。一个事故的影响胜过千言万语，以前苦口婆心劝说大家要遵守的规范和流程，结果一出事故大家都听进去了。出几次小事故总比一下子出一次大事故好，唯一对测试人员的要求是怎么控制每次出的事故是小事故~~事故的责任方面，开发默认要承担7成责任，如果一个bug可以从代码review或者单测中发现，开发无疑要负主要责任
2.给项目追加测试资源——减少测试资源投入
开发不重视测试的根本原因还是测试这项服务太过于便宜了，招之则来挥之则去。大家都说能用钱解决的问题不是问题，所以能堆人解决的问题就不是问题。开发不进行单测和自测显然是因为测试人员太多了，让他们自测一下总是说太忙了，而测试人员似乎不忙？ 如果测试人员跟熊猫一样少，那么为了保证上线质量开发和测试都会去改进效率减少测试成本，或者测试人员再少一点，开发写出来的代码都没有测试人员来测，那么为了上线了，最后还是会由开发去测，这样开发的测试技能也get到了。
3.测试人员肩负多职——让团队角色各司其职
大家都说弱队出好门将，然而弱队还是弱队。一个团队中测试比较强而开发比较渣（渣其实并不是指技术，而是指意识，技术能够培养，但意识很难扭转）是一件很悲惨的事情，，测试人员懂技术、有产品理念、有管理能力自然是好事，然而尘归尘、土归土，该由项目、产品、开发来做的事情还是应该由他们去做，我更希望，各守其位，各司其职，而不是看到测试人员能做而自己不做，"你会搞，不如你搞下", 我最讨厌的就是这句话。从推动流程的角度上看，测试直接去推动的效果并不好，因为虽然我是从项目整体出发去推动正确的事情，但从测试的口中说出往往会被认为是为自己谋利，开发采纳是一种"配合"工作而不是真正的需求，而从PM和产品方推动就容易的多，如果有专门的流程管理QA也是蛮好的。