开发人员奋斗了很多个夜晚，终于把版本提交测试了。他们可以松一口气了。但是噩耗很快传来，软件没有通过测试团队的预测试（为了保证测试进程，对开发人员提交的代码进行基本功能或业务流程的验证）。开发经理老王，迅速找到负责预测试的测试经理老张。
老王说：老张啊，怎么回事？出什么问题了？我们好不容易开发完成了，你们怎么不测试还把版本打回来了？
老张说：你们提交的版本质量太差，没有我们的预测试，需要重新修改后，符合我们的要求，我们才能测试。你看看我们发现的这两个问题。
老王并没有看这两个问题，而是直接质疑老张：听说你们最近测试环境搭建的有问题，是不是想借版本打回的时间再折腾一下你们的测试环境啊？可不能为了让我们开发的给你们打掩护啊！
测试团队经常会受到提交的版本质量太低的困扰。一旦开发团队提交的版本质量太低，测试过程中就会发现一些非常严重的问题而导致大量的测试用例被阻塞。而非常不幸的是，在项目发布时间不好更改的情况下，这样就会导致测试团队真正能够执行的测试时间被压缩，导致测试的任务无法及时保质的完成。打回版本在对测试团队造成影响的同时，也打乱了开发团队的进度。
于是有些团队就采用了预测试（有时候也称为冒烟测试）的方法，只有通过预测试的版本，测试团队才会开展正式的测试执行。上面的这个场景就是在开展预测试的时候，由于预测试失败而导致的冲突。
测试人员不仅仅是守门员，还应该在需要的时候主动出击。虽然设置预测试是一种提高测试接收的版本质量的一种方法，但是采用预测试的目的不是为了把版本打回去，毕竟回去了，还是要再回来的。测试人员除了被动的在等待开发团队提交版本过来以外，更应该积极的帮助开发人员，尽可能的是的他们能够通过预测试。有些项目中，测试团队积极主动的在测试执行之前帮助开发人员进行代码评审，也会帮助开发人员做部分的测试工作，这样就避免了被动等待。开发团队和测试团队良好互动，共同把项目做好。前期质量提高后，开发人员在测试人员执行测试期间，也可以有少量的开发人力来帮助测试团队。
入口准则在考虑开发因素的同时也应该考虑测试自身的因素。通常都是测试人员去检查开发人员的工作，但是测试人员自己的工作却常常没有得到充分的监督和检查。在制定入口准则的时候，除了对开发人员前阶段的活动的质量提出要求以外，对测试团队应该准备的条件也要进行约束，例如：测试环境的到位，测试用例的评审，自动化测试脚本的编写，测试数据的准备等。