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