测试如何应付领导

这个帖子，有人问了一些问题，回复了一下，都是从实际工作中来的，也许不适合很多公司，但是测试人员工作中还是有可能会遇到，就说了些自己的看法和意见。

http://bbs.51testing.com/viewthread.php?tid=475716

提问：

我问的这3个问题还是归于一个项目的测试引发的，测试了四五轮，问题数虽有递减的趋势，但总有新问题出现，领导说我们测试不仔细，有些问题是可以在第一、二轮就可以发现的，现在发现的晚，还影响项目进度。
   还问我们怎么判断一轮测试可以结束的？我们现在做的项目比较多，测试人员比较少，一般一轮测试就是修复问题的验证，再加相关联问题的随机测试

回答：

有新问题是正常的，咱们先不提修复问题引起的新缺陷，只说因为随着测试的进行，测试人员对系统更多的了解，才能发现更深层次的问题。
还是前面说的，是否测试可以做前期的工作，比如存在需求、设计文档，测试人员可以预期做测试计划、测试需求分析、测试用例编写；或者进一步的测试是否从需求阶段就可以接触到项目，不奢望需求阶段测试方面参与评审，测试至少应该对项目的进度、内容等进行了解。
没有上面的那些，软件直接提交到测试，测试只能在测试过程中不停的进行摸索，了解需求、了解软件，当然会花费更多的时间，因为前期的时间集中到最后了。这是任何一个人都无法解决的问题，只能等待随着测试人员对业务的了解，对下一个项目才能更快的进行测试。
通常情况下，没有上面说的前期阶段直接测试的条件下，第一轮就发现发现表明的问题，让软件能跑下去而已。第二轮才能了解程序整体的走向，比如数据的流转。第三轮测试才能真正的了解软件，明白软件到底需要达到什么样的目的，到底内在需要什么样的功能。没有5轮以上的测试过程，系统测试很难结束的，所以你说的问题根本不称为问题，这是大环境决定的，测试方面无能为力。
测试是良心活，开发至少要拿出能用的东西，测试测没测过只有自己知道。测试用例其实就是保证测试人员的工作进程的；没有测试用例，测试完毕后发现问题顶多说自己马虎了，一些地方没有测到。开发有进度压力，可能开发出很糟糕应急的软件；测试也一样，没有时间只能马虎的测试一下，没有大概的问题也就那样。

嗯，上面的是测试方面的理由，自己知道就行了，和领导没有必要这么说，上面一般不会接受这些东西的，因为这么说责任和压力就在项目经理和领导头上了。只能潜移默化的影响领导，比如知道要测试什么东西，随时和项目经理要需求设计文档，没有的话，在不经意间和上面说说，说因为没有这些文档，测试不好开展。不要直说，因为直说如果真的让上面让项目经理补这些文档，项目经理一定会抓狂的，对测试也会有看法，说这些仅仅说明测试工作不好做而已。有时间写写测试用例，给上面领导看看，说明除了测试，我们还开展的正规的工作，能让项目经理评审一下就更好了，这个是推脱责任的利器，以后客户方面发现问题，只要说测试用例中忘记了，下次补充上，就能推卸不少的责任，至少态度在那里不是。
测试进度忙，多加加班，至少样子在那里，领导说测试不仔细，就回答时间实在太急，测试的项目太多，每个都详细测试没有时间，嗯，随便拿两个自己测试发现的缺陷说一下，说开发那边的进度也一样，太急了，很多东西都没做太好就拿过来了，当然了，只说问题，千万别提具体的项目或具体的人。
领导问如何判断一轮测试结束，告诉他，明天来一个新项目，无论如何，测试这边今天必须结束，否则测试项目就堆积了。工作找借口是件最容易不过的事情了，很多时候，领导也只是找个借口，说明他在起作用，确实在管理而已，并不在乎你的回复是什么。

嗯，大概就是这些了，不是很理论化，但是我想实际工作应该理解和用得到，也许和你们公司的实际情况有差别，但是我想大多数的测试人员都无法避免这些事情的。