51Testing软件测试论坛

标题: 部门经理的话让我很郁闷 [打印本页]

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

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

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

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

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

作者: heavy200t 时间: 2009-8-21 17:52
标题: 只有改变自己才能改变环境
很多人对测试工作都不了解，不重视测试。
但反过来这个测试人员自身的能力也有关系。
我也有过和LZ类似的情况，经历过了才知道，只有改变自己才能改变环境。

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

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

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

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

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

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

作者: peterz 时间: 2009-8-22 10:35

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

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

作者: alps 时间: 2009-8-22 10:51
标题: 回复 11# 的帖子
bug一大堆证明bug确实是大量存在的。
如果是开发自己测试发现的，呵呵，自己往下咽吧，这样有助于提高开发的水平，而且是主动去提高哦。
如果是用户发现的，唉，恭喜了~~~，这时候想想如果有测试部门测试过~~~

作者: black_tulip 时间: 2009-8-22 11:13

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

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

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

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

作者: black_tulip 时间: 2009-8-22 11:15

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

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

作者: shanxi 时间: 2009-8-22 19:51
楼主的这两个问题，做过开发的都会回答测试的重要性之所在。

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

作者: alps 时间: 2009-8-22 23:10
标题: 回复 15# 的帖子
对，这就是说想法是好的，但是实际情况并不一定允许这么做

作者: 桂冠英雄 时间: 2009-8-23 00:24
行业浮躁之风不是几个人能解决的

作者: key4 时间: 2009-8-23 14:08
让开发的自己测自己，那真的就不用测试人员了。。

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

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

作者: 月上百合 时间: 2009-8-24 09:49
为何楼主一直没有出现哦

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

作者: 月上百合 时间: 2009-8-24 12:35
都说了让你把测试搞起来，你就发挥能力吧，不用听部门经理的啦，哈哈。按自己的想法走

作者: 清风随雨 时间: 2009-8-24 16:20
标题: 我倒是部分同意你们部门经理的观点
其实你们部门经理的观点还挺不错的，只不过你后边需要加上一点点的补充。
1、开发人员来编写测试用例。
完全没有问题啊，毕竟人家那么熟悉系统了。但是测试用例编制标准应该由测试人员提出。如：某模块使用什么测试方法，要求考虑什么前提条件，详细描述操作步骤，各种流程限制，准备哪种非法数据等等。
2、让新来的员工执行测试。
这点和我的观点完全一致。我在公司一直强调，测试人员主要精力应该集中在如何测试，而不是测试执行。测试用例是如何测试的最佳体现途径，也就是说：只要测试用例完善了，测试质量还是有保障的。在这种情况下，测试人员把精力完全投入到测试用例的编制和完善上有何不可呢？
估计这两点提出之后，你们经理就不会主张他现有的观点了，但这个时候你应该坚持你们经理现有观点，因为毕竟人家现在是多么的关心测试工作，多么的体谅测试人员啊。你们经理真的很不错哦。

作者: 千里 时间: 2009-8-24 16:42
明天要和开发人员一起实施一个系统，压力挺大的，但同时也是一个机遇。因为那个系统开发了两年时间一直没能交付，我是前段时间才介入测试的，如果这次能够成功交付。领导肯定会明显看到测试的作用，因为有了测试的介入，系统能够交付了，测试以后说话也就有了地位；如果没有，我拿什么跟领导说话？没有测试不能交付系统，有了测试同样不能交付系统，测试的价值在哪里？

作者: qinchun1984 时间: 2009-8-24 18:54

原帖由 月上百合 于 2009-8-21 17:45 发表
和部门经理谈到了今后的部门测试规划，有2点让我比较郁闷
1：测试用例不需要由测试人员编写，让开发的写就可以了。原因：做过项目的都清楚，现在测试很少是在需求阶段就介入的，基本上是等系统开发差不多以后才介入 ...

说的好，语塞是不自信的表现，我看了你的情况，我马上就发现，我就有很多话要和那个PM交流交流。

作者: fengyun_wang 时间: 2009-8-24 22:57
3个月了，总是做功能测试，很烦...

作者: ffwithvv 时间: 2009-8-25 10:48
慢慢来，先积累经验吧

作者: 月上百合 时间: 2009-8-25 12:05

原帖由千里于 2009-8-24 16:42 发表
明天要和开发人员一起实施一个系统，压力挺大的，但同时也是一个机遇。因为那个系统开发了两年时间一直没能交付，我是前段时间才介入测试的，如果这次能够成功交付。领导肯定会明显看到测试的作用，因为有了测试的介 ...

今天己经开始行动哦

作者: dennyqiang 时间: 2009-8-25 12:23
哎，要让人们真正重视软件测试，任重道远啊。

作者: tyah 时间: 2009-9-1 19:43
那个经理到底懂不懂什么叫测试啊，郁闷。。。。。

作者: zangxue84645515 时间: 2009-9-2 14:19
标题: 回复 1# 的帖子
你又出头之日了管他呢你就按他说的办

作者: guoxiaoqi_1985 时间: 2009-9-8 17:21
标题: 回复 1# 的帖子
首先：开发人员写用例，这一看就是个外行人说的话，而且很不重视测试，你可以根据开发人员写出的用例跑一遍，然后按自己的用例再跑一遍，多跑出的bug给报告给领导让领导知道，开发人员写用例是不专业的，虽然开发人员了解系统，但最起码的不能让他自己测试自己写的东西吧，这样如果按开发人员写的用例怎么可能测试出bug呢。
再者：让新人测试，也许领导出发点是不对的，测试中，每个人的测试重点是不一样的，比如：一个界面，你注重的是页面布局，而他注重的是功能的实现，所以说，测试中增加新人，添加新的思想，这样可以减少测试中的遗漏，更好的为公司产品保驾护航。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)