写一下自己的切身体会，与大家共勉吧。
独立承担测试任务已经有一段时间了，应该说前期的熟悉工作完成就独立撑起了这个组的测试，可是越做到后面越不舒服，好多问题想纠正起来不是那么容易解决的。
刚过来的时候还是按照以前的工作方法，只不过排计划、写用例、执行什么的都要亲自效劳而已。下面罗列几种测试过程中的现象，与各位切磋切磋。
现象一：早会的时候跟我说要我自己去build版本，老子当时就不淡定了。搞什么啊，不但你们需要build版本，而且你们应该冒完烟才能提交给我测试的。
现象二：研发内测试，不知道有没有同学听说过这个词语。不过对于我们这种不做单元测试（原因我不清楚）的开发团队来说，这个就算是尽早的发现问题，这个测试是典型的坑爹测试，也就是给他们擦屁股的测试，好多令人无语的问题我就不一一说了，只不过到后来坚决拒绝了。什么叫尽早发现问题？就是说这些问题根本没必要出现，现在有了测试人员的介入，开发变懒了而已。
现象三：这次测试怎么那么多严重的缺陷啊，你们之前有过冒烟么？有啊。可是这是基本路径上的问题啊。然后让我很不淡定的答案就来了：我在我自己环境上冒烟的。我还是觉得有问题，最后他们跟我要我的环境，我直接说你们自己不是有对应的环境么？没有？我勒个去，没有环境你们冒的哪门子烟啊？
现象四：我靠，这个实现怎么和需求说明书上差距那么大。坚决BUG之。然后开发直接找上门，跟我说这个是前一个补丁的修改，市场人员提的需求，需求说明书还没有更新。然后，然后，就没有然后了…………
简单的填写下解决方法，兄弟姐妹们有更好的可以共享哈：
现象一：扯皮了很久，他们认为应该测试人员自己去build版本测试，可是build过程中谁能保证没有问题？每个人的代码没有完全提交SVN怎么办？再说，你们需要冒烟的啊！反正吵吵嚷嚷了好久，最后决定实施持续集成，用了Hudson的工具来自动build。这个世界才算清净下来。
现象二：自从意识到这个测试的本质之后，坚决抵制之。好吧，我承认我的做法是直接让其归到版本测试里面，你们不怕缺陷列表中的缺陷几何级增加，就继续这样搞好了。版本测试，那好办，计划，用例，结果报告什么的一个不能少，如果你们觉得这个不影响你的绩效，那大家Happy。这个问题现在还在持续，什么时候是个头，还真不好说。
现象三：坚决不给环境，这个是我的测试环境，你们开发还是有自己的环境的嘛，如果开发环境下确实没有这个问题，那我可以提供环境给你们重现和调试，但不能再我的环境里面冒烟什么其他什么事情。还有同学，你们没冒烟就发布这是个神马意思呢？对自己做的东西超级自信，一定不会有严重缺陷？
现象四：这个是整个流程的问题，想解决起来真的不容易啊。作为测试人员，也只能敦促在有新需求的时候需求人员能够及时跟进文档。要根治，还得调整流程才行。
针对这些个问题，解决起来还都是头疼事，对于开发内部，应该是冒烟测试通过才可以提交测试，否则浪费大家的时间而且还耽误版本进度。事实证明这样一来，整个版本整整延迟了一个迭代的时间。还有，同学，你应该将程序完整的build出来放在冒烟环境下冒烟啊，你在你本地冒个什么劲？难道用户最终使用的是你的开发环境么？坚决抵制那种不冒烟就提交的版本，直接打回，没有什么商量的余地，有问题，找流程规范人员去。前提：流程本身规范。不规范，那只好先来规范流程了，工欲善其事必先利其器，磨刀不误砍柴工。
我不是很懂管理，网上有人提出制定对应的奖惩制度，这个不错，譬如上面的现象二，如果影响了他的绩效，他还能那么逍遥的不冒烟就提交测试么？
测试不是无所不能的补丁，测试也不是为了弥补别人工作的不足。产品质量不是测出来的，而是做出来的。测试只能告诉你目前这个产品有多少缺陷以及测试结果怎么样。如果兼职QA，那可以告诉你测试质量怎么样。这也是源于对结果的分析。想要提高产品质量，测试需要提高缺陷的发现率，开发也要规范自己的开发流程，不能养成依赖测试的习惯，做到一起提高才好。
欢迎童鞋留言讨论，现在有些问题还是没有得到很好的解决。有成熟的经验欢迎分享。
