目前的很多公司为了快速的迭代，短时间开发出产品；测试、产品、开发在同一个办公地点工作；导致测试、产品、开发的职责出现混合交叉，从一定的程度上说可以节约开发时间，但是也会产生很多的问题；
首先，测试的职责不够明确，立场不够坚定；在测试的角度来看，首先是应该是对产品负责；那么如何确保产品的质量是高效的呢 ？
1、产品的设计标准；
从产品立项开始，测试、开发、产品应该一同指定出一个合理的产品设计标准，明确产品的设计流程，应该实现的功能，具体的实现流程，具体的性能标准，针对的使用人群等等，当测试得到设计标准后应该针对设计标准制定对应的测试用例，并且严格针对测试用例来执行。
2、开发的设计流程
开发应该针对具体的功能产出开发设计流程，该流程应该具体明确某个功能的实现方式，涉及到哪些影响点等；
3、开发转测试的流程
开发实现功能后，如何转测试，应该实现什么样的标准后才能转入测试？如果转入测试的标准太低，将导致测试回归次数太多并且最终的产品质量将不能得到确保；如果转入测试的标准太高，将在开发自测的时候花费太多的时间，最终也会使得产品的开发成本增加，因此，我们应该合理的控制开发转测试的标准；此时，可以由开发、产品、测试共同制定出一套提测标准，最终实现开发转入测试的流程
4、测试流程
测试的回归次数，在我看来超过3次的测试回归，就不应该算是一次成功的提测；过多的回归一是浪费过多的时间，另外会导致测试无力去做更多的稳定性、性能测试；从而只覆盖到功能测试；更甚至是到了产品发布的前一刻开发还在更改bug，这里也就导致了测试没有更多的时间去回归以前的功能，这样的产品也是极具风险的，另外测试时间的计算是一件很有艺术的事情，首先我不建议测试时间估的太紧凑，慢工出细活这句话我是很认同的；我认为测试的流程应该是这样的
一、需求熟悉，这是基础，只有熟悉自己的产品才能覆盖全面自己的测试点；测试应该比产品更熟悉需求，标准等
二、熟悉功能实现的方式，只有只其所以然才能更好的完成测试，而不是简单的黑盒或者从功能上去体验
三、测试环境的搭建；目前很多公司，尤其是互联网公司，测试环境的搭建更多的依赖开发或者运维人员，也就导致了测试公司的地位比较低，我们必须将测试的所有资源维护在自己手中，才能具有一定的独立性；在我看来某些特定的测试环境，测试应该比开发更专业，而现在很多公司，测试的很多测试方法都是从开发那边来取经 ；
四、测试角度覆盖全面；坚决不能只做功能测试，首先，需求拿到的时候，其实测试的任务就开始了，我们可以从需求上去否定掉一部分不合理的需求，其次，开发的设计方式说明书拿到的时候我们可以针对开发的文档，或者源码来进行部分的测试；从设计上是否合理；再次接口测试是绝对不能少的，这部分的测试能从逻辑上或者代码上来检查开发的质量，对于后端的测试时及其重要的；最后才是我们的功能测试；从前端界面上来体验产品；而到这一步时我觉得产品的问题应该只限于前端的问题，后端的问题应该就比较少了才是合理的；然后还有我们的体验交互测试和性能测试；
五、测试能力的培养；我们应该针对公司的具体业务，指定一些提升计划，比如；针对不同的人员分配不同的研究任务，比如性能测试、压力测试、自动化测试等；每月进行一次汇报，查看一下一定时间段内个人能力的提升，任何的工作，我觉得一是能赚钱二是能学到东西，起码不用担心自己在公司呆的久了反而不好换工作。
