开发与测试的关系似乎总是那么的微妙。“强势”的开发，“弱势”的测试，这种状态似乎一直没有转变过，也一直成为测试行业内最想扭转的一个目标。如何有效的摆脱开发的控制?
在讨论这个问题之前，我们首先来谈谈一个公司的发展。一个公司的起家模式基本都是先有开发，后有测试这么一个过程，总之一句话，就是测试不可能在开发之前成立(专门的测试公司除外)。公司的发展模式决定了开发的优越感，也因为公司发展的初期依赖的是开发，加之公司发展初期为了自身发展，“效率优先”的原则在很大程度上影响了“一代人”(一代人：指公司创业初期的元老，这代人通常都是设计领域或者开发领域的“强人”，这代人里通常不会有测试领域的“强人”)，这一代人在公司初期项目中的习惯影响到了后续的项目，进而形成一个非常牢固的“外壳”，要想打破这个“外壳”，所需要花费的时间和精力是很难评估的。这就像我们从小形成的习惯，明知这个习惯相当不好，可是就是改不过来一样的道理。
公司需求发展，发展需要可靠的质量保证……，这个过程是公司向正规化方向迈进的关键一步，而测试也是在这个过程中诞生的。测试的存在，总是让一些人感觉非常的不舒服，因为开发在观念上会不由的认为测试是在为难开发(这些开发可能不是很成熟)，虽然测试也一再强调我们是在协助开发完成项目，而不是为了为难开发。开发与测试是不可分离的，只是在项目中承担各自不同的职责而已。
公司的发展有一个过程，测试部的发展同样需要过程。测试部发展的初期，需要依赖开发的各种支持，但依赖开发的支持不能代表测试就应该丧失自己的原则。这个过程中，妥协的可能往往是测试，但妥协不代表就丧失了测试的原则。我常常对我们的测试人员说，做到心中有数，在适当的情况下，我们需要妥协，妥协的目的是为了把项目继续下去。
测试成立的初期，首先介入的是系统测试。这个阶段的测试主要是属于功能性测试，也就是在外人开来“这里点点，那里点点”的这么一个过程。这个过程往往被外界所轻视，但在我的眼里，这是一个测试部自我能力提升，以及完善最为关键的阶段。这个阶段直接影响到后续的发展。这个阶段测试部需要解决3个问题。第一个问题是学会整理“文档”，这个过程非常重要，文档是依据，这个阶段需要的就是不耻下问，进而形成测试的依据。第二个问题是测试环境必须独立于开发，而且必须是测试自己维护自己的测试环境。第三个问题，整理测试部的工作流程。 这个阶段是测试部最困难的阶段，因为这个过程实际在一定程度上触及到了开发的一些底线，这在任何一个人来看，都是所不能容忍的。这里我最想强调的一个就是测试环境由测试部进行维护的原则。这个是作为测试人的一个底线，如果测试连自己的环境都不能维护的话，这在我看来，测试就不能完全保证测试的质量一样的道理，举一个简单例子，测试的环境由别人在维护，作为测试，你能说我真的完成了某个版本的测试吗?如果测试无法把握自己的在测试版本，测试何以保证质量?随着测试能力的提升，集成测试就会成为测试部的发展趋势。这个过程中，测试部会逐步接触性能测试，接口测试等等这方面的测试，这个过程也是测试真正开始摆脱开发控制的一个关键。记得我们有一个项目，先前开发总认为性能上绝对不会存在任何问题，甚至在测试部提交的测试方案中，开发也是非常强硬的用“时间允许的前提下，可以考虑做一下”。这次项目测试的前期开发是主导，后期测试介入了，测试用非常有力的证据证明了开发先前的错误后，测试顺利的拿下了性能测试的权力。
测试需要逐步摆脱开发的控制，而不是一次成功。测试在自己的翅膀还不是很强硬的时候，需要“伪装”自己，需要低调，在不失原则的过程中逐步壮大自己，在悄无声息中成为基石。这其实何尝不是适合自己的发展呢?
文章来源于领测软件测试网 https://www.ltesting.net/
