怎么hold住版本质量

毕业前选择从事哪条技术路线纠结了很久，想了想自己不是读计算机的，估计成不了编程最厉害的人，然后看到了有个职位叫做测试，按当时我对测试的理解是，测试就是发现bug的人，测试的价值就是发现所有的bug，拯救世界，想想都有点激动和自豪，于是决定走上测试这条道路。实习面试，面试官问我对哪方面感兴趣，我说测试，而且要白盒的，然后就被华丽丽的分配到开发组，每天就是看协议看代码，然后进行测试，有一天老大对我们说，代码质量不是测出来的，我听了有点不服气，等哥把级练上去了把那些bug都测出来。
进了公司以后，初来乍到就测了某大神的几个版本，感觉java层层包装代码看得好痛苦，其次大神的代码质量的却很靠谱，基本上挑不出问题，就算有了问题还能hold住，每天的工作就是我问，这个特性怎么测，大神说，你只要跑下xxx就好了，其他的我已经测过没问题，还加了开关，有啥不对劲的就关了。开发完全hold住了版本质量，测试人员很轻松，虽然这对我这样一腔热血的测试来说很无聊啊
如果遇到版本质量不是很高，或者开发都不靠谱，那么就需要花时间精心设计用例，经常能找到很多bug，有些是很低级的书写问题，就算找出来了也懒得提bug单，有种不是我太强而是对手太弱的惆怅;有些是隐藏的很深的bug，花费了几个小时或是几天去定位，这样的bug虽然只是很少一部分bug，但是真的很有成就感，感觉这样的bug都被我找到了，那还有什么bug能被我漏过呢
所以，如果代码质量足够好或者测试的足够充分，那么版本的质量是可控的，实际情况是：为什么代码质量像一坨翔，而测试流程匆忙而草率呢？

一.代码质量
能进公司的开发人员怎么说也是各中翘楚，你能说他们写不出像样的代码，加上详尽的注释么，我不止一次阴暗的揣测，产品汪急功近利地把东西扔上线向主上邀功，留给后人无尽的填坑和重构，或者项目经理疯狂排需求，开发人员写完代码都没空自测。就算测试人员认真测试了，打满补丁的代码和精心构筑的代码肯定不能比，而且要知道与做对的事情相比，把事情做对有多么艰难啊
二,测试时间
如果开发提交测试的时间延期了，为了赶上发布时间，怎么办：A.压缩测试的时间 B.测试加班, 嗯，正确答案就是A+B了。现在移动互联网时代，需要的就是适应需求的快速变化，需要从以前游刃有余充分测试，逐渐转向快速迭代下非充分测试了，但是谁都不能保证急匆匆的测试是否会有一些东西遗漏，谁也不能保证所谓的不重要的地方是不是真的不重要

在这样的形势下，如果不能获取更多的资源，那么测试人员该如何保证版本的质量，相对应的有2点：1.从验证开发是否实现了功能转向是否graceful实现方式，开发写代码的时候也许没有进行思考，那么测试人员需要代替其进行思考； 2.测试人员能够足够敏捷的响应需求的变化，那就需要测试足够快，从自动化的全覆盖到通过代码阅读波及分析进行用例精简对立而又统一，等想定定了再细说