测试如何应付领导

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

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


提问:

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


回答:

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

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

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


阅读更多

没有更多推荐了,返回首页