部门经理的话让我很郁闷

ffwithvv

和部门经理谈到了今后的部门测试规划，有2点让我比较郁闷
1：测试用例不需要由测试人员编写，让开发的写就可以了。原因：做过项目的都清楚，现在测试很少是在需求阶段就介入的，基本上是等系统开发差不多以后才介入。那么这个时候测试人员如果要写用例的话，那他还需要一段时间来了解业务，了解流程，了解系统。这样势必造成时间的浪费。由开发人员来写的话，第一他们对系统最了解，第二，节省时间。
2：执行测试的时候，如果人手不够，就直接让新来的员工上，让实习生上也可以。原因：测试不就是按照用例一个一个点嘛，谁不会。

我知道他说的比较片面了，但当时却一时语塞，想不出反驳的话，特来求助大家，如果是你，你怎么回应部门经理提到的以上2点，谢谢

千里

不要急，慢慢来。如果让你写测试用例，你能不能写好？如果得到了肯定的回复，你就可以跟部门经理讲开发写测试用例会有局限性。就算你不说，你也可以附加更多的用例去执行。在最原始的测试过程中确实是这样的，其实我公司所在的情况就是这样子的。

peterz

通过楼主的说法，我发现部门经理对于测试的态度不是特别重视啊。解决办法：在需求调研期间，测试人员就要介入。在开发人员开发时，测试人员就进行测试用例的设计。同时制定测试计划。
通过自己的努力，让部门经理来认识到测试的重要性。

月上百合

和部门经理谈到了今后的部门测试规划，有2点让我比较郁闷
1：测试用例不需要由测试人员编写，让开发的写就可以了。原因：做过项目的都清楚，现在测试很少是在需求阶段就介入的，基本上是等系统开发差不多以后才介入。那么这个时候测试人员如果要写用例的话，那他还需要一段时间来了解业务，了解流程，了解系统。这样势必造成时间的浪费。由开发人员来写的话，第一他们对系统最了解，第二，节省时间。
-----就算测试不一开始介入，但是却有足够的时间了解业务需求吧，没必要等于最后再去看业务吧？如果由开发自己写了还要测试干吗？为了执行吗？说实话很多测试用例开发都没有想到，这样太片面了，而且我觉得他严重不负责任。你可以提前了解业务，提前介入，把问题记下来，就算不影响进度自己也要先知道哪里有问题目，千万不要等最后，因为会忙的顾不得想太多，慢慢的把用例补充起来或者修改。就算开发写用例，你也得参与补充和修改。
2：执行测试的时候，如果人手不够，就直接让新来的员工上，让实习生上也可以。原因：测试不就是按照用例一个一个点嘛，谁不会。
---让新人或实习生来测，我觉得是好事儿啊。但是他的原因却不对，决对不是为了按照用例点，因为简单才让他们测，而是为了从多个出发点，为了更好的更多的找到bug才让多人参与。
我知道他说的比较片面了，但当时却一时语塞，想不出反驳的话，特来求助大家，如果是你，你怎么回应部门经理提到的以上2点，谢谢
----你语塞是因为你还不自信哦，不坚定自己的立场，有可能也是新人的原因吧。下次就提出来吧。

heavy200t

很多人对测试工作都不了解，不重视测试。
但反过来这个测试人员自身的能力也有关系。
我也有过和LZ类似的情况，经历过了才知道，只有改变自己才能改变环境。

从LZ部门经理的说法可以分析出，他的想法就是：
  1、测试人员介入需求只能是被动地学习
  2、测试人员了不了解需求一个样；
  3、测试人员跟实习生的水平差不多；

我想问一下LZ，现实情况是不是这样的？
如果不是这样的，那么就拿事实说话，要让部门经理了解真实情况。事实还是很有说服力的。
如果是这样，那么先接受现实吧，韬光养晦好好学习，把自己的水平提高再说。

black_tulip

砍掉测试部门，让开发测试，节省人力资源，业务也清楚，省时省力，什么都不浪费。

alps

同意这个。
一个公司在测试刚刚起步的时候，尤其是让新员工开展推广测试工作的时候，鉴于新员工的水平不够高和对业务的不够熟悉，会让开发人员设计用例，测试人员去执行并添加用例。在这个过程中，测试人员会慢慢的成长起来，终有一天能自己编写测试计划、用例。从最初的执行用例到后来的设计用例，是测试人员一个成长的过程。

alps

久仰“月上百合”大名！
1.在实际中，我认为，很多公司的测试和开发人员的比例是严重的失调，所以，在开发人员做一个项目的时间里，测试人员可能会做多个项目的测试，这样他的时间就会被压缩，用来熟悉业务的时间确实不是很多了，这是现状，也是测试的无奈，还需要测试的现状有所改变提高。
在当前状况下，对于楼主的情况，我认为，如果你能说服领导支持（前提一定是你先定位一下自己能否把设计用例的活干好），那最好，你可以大显身手了。如果领导不支持的话，那就只能是开发设计用例，你再在执行中去补充，在执行和补充用例的过程中一方面做了工作，一方面提高自己的测试能力，补充用例做得好了还会让领导意识到，下一个项目的测试可以让你来设计用例了。

箭在行动

这种现在不是只出现在你们公司，中国整个行业都是这样。
作为一个刚走出校门的学生，他们就能让我负责一个研发部门的测试（这个部门就我一个测试，公司测试部的人还是蛮多的，好几十个），包括硬件、应用软件、Linux和Windows下的驱动、硬件固件程序，可见大家对测试的“重视”。不过这是一个很不错的机会，能够锻炼自己。现在顺手多了，主要是黑盒测试，我会慢慢介入白盒测试。Linux的一点知识全是在测试驱动的时候学的。这么好的学习锻炼的机会到哪里去找啊？
我也在一次部门开会的时候，当场提出部门对测试部够重视，但是又有什么用呢。最好的就是，努力提高自身的知识水平，当你有相当的能力后，你才能有机会慢慢改变他。

peterz

原帖由 black_tulip 于 2009-8-21 22:35 发表
砍掉测试部门，让开发测试，节省人力资源，业务也清楚，省时省力，什么都不浪费。

怎么跟我们单位一样啊。这样的结果就是程序bug一大堆，开发人员天天疲于奔命的修改bug。

alps

bug一大堆证明bug确实是大量存在的。
如果是开发自己测试发现的，呵呵，自己往下咽吧，这样有助于提高开发的水平，而且是主动去提高哦。
如果是用户发现的，唉，恭喜了~~~，这时候想想如果有测试部门测试过~~~

black_tulip

原帖由 peterz 于 2009-8-22 10:35 发表

怎么跟我们单位一样啊。这样的结果就是程序bug一大堆，开发人员天天疲于奔命的修改bug。

有没有一大堆bug和有没有测试部门没有什么关系。有测试部门开发人员也会产生一大堆bug，也会天天疲于奔命的修改bug。

楼主说的情况，测试人员不了解业务，写不出测试用例，自然也不能够很好地执行测试。业务都不了解，怎么做测试。还不得开发人员自己写用例，自己测。

black_tulip

原帖由 peterz 于 2009-8-21 17:32 发表
通过楼主的说法，我发现部门经理对于测试的态度不是特别重视啊。解决办法：在需求调研期间，测试人员就要介入。在开发人员开发时，测试人员就进行测试用例的设计。同时制定测试计划。
通过自己的努力，让部门经理来 ...

总是说“要”是没有用的。他不让你介入，你要介入也没用。不让你设计，你也没法设计。这不是解决办法。

shanxi

楼主的这两个问题，做过开发的都会回答测试的重要性之所在。

但关键并不在于你的回答，而是你所在公司。

alps

对，这就是说想法是好的，但是实际情况并不一定允许这么做

桂冠英雄

行业浮躁之风不是几个人能解决的

key4

让开发的自己测自己，那真的就不用测试人员了。。

最好的测试人员就是客户，但最坏的测试结果也来自客户。

bluesky1986007

这测试经理貌似对测试是有点不重视…………你要让他知道测试的重要性……不是所有的人都有测试人员的职业素质的……并不是所有的人都可以都适合做测试…………测试人员有洞察力、有耐心、有一颗细致的心、有………你要让你经理知道测试不是随便拉一个人来就可以做的…………同样一个事物……不同性格、不一样的人所发现的问题和角度是不一样的……测试人员应该是能够更多、更深、更广的去发现问题的…………你们公司对测试也太不重视了吧…………

月上百合

为何楼主一直没有出现哦

ffwithvv

哈哈，来了来了，不好意思，这个周末一直都没时间上网。看了大家的回复，感触颇深。
这里先解释一下几个问题：
第一：我所说的经理不是测试经理也不是开发经理，是部门的经理，他会提出那样的观点，我想也是对测试不是很了解吧。
第二：说来惭愧，我其实并不是一个测试新人，我做测试也有4年左右的时间了吧。只是以前一直是一个小兵，现在调到了新的 部门，由于有测试的经验，所以部门经理让我带头把测试搞起来。正因为以前一直小兵，只知道埋头测，所以对测试的管理，规划发展都没有主动的去了解。也许不自信也是一部分原因吧。
我总结了一下大家的观点：
1 主动提前介入项目，了解需求
2 不断提升自己的能力
3 重视，重视，再重视。大家说的最多的就是重视，我也知道重视很重要，也很需要。我想让经理重视的最好办法，就是尽可能的，在项目周期内，发现更多的bug，用事实来说话。当然bug多，也不是什么好事，呵呵。
最后还是非常感谢大家的热情回复，我们一起加油吧