51Testing软件测试论坛

标题: 实在是怒了，混乱中的测试 [打印本页]

作者: tails82 时间: 2009-6-5 00:33
标题: 实在是怒了，混乱中的测试
今天实在是怒了，无法入睡，在床上用手机发贴。不知道有多少同行和我有相同的处境，还是这就是我公司的特色。
我目前负责测试的项目，是在一个现有系统的基础上进行功能扩展。测试需要检查功能扩展后，是否会影响原有的功能。但客户只是描述了需要扩展的功能，却没有提供原有功能的说明。于是我向PM反应了这个问题。你猜怎么着，PM说大家谁都不知道原来功能的逻辑，都是看代码研究的。还要求我们测试组要读代码，并和开发组探讨需求。
我一时无语，回过神来说，我们测试组不像开发组那么熟悉代码，让我们研究有点困难。PM认为这不是理由。我真是没想法了，谁都知道术业有专工的道理。而且谁来确保我们研究出来的就是正确的呢？我们花时间研究代码了，谁补偿我们用例写作的时间呢？PM不该负责和客户沟通，获取信息吗？
但人家是PM，我也没办法。先看数据库表结构，再看存储过程，有些眉目后，写了用例，并要求评审。结果一直没音讯，只好作罢。
等版本提交测试了，我们开始执行用例。结果发现用例中少检查了一张表。开发人员抱怨了，说怎么不检查。我说我并不知道这张表的逻辑，怎么检查。开发认为我们研究了代码了，应该知道。我回复说我们按照我们的研究情况，写了用例，要求评审了，你们为何不在那时提出。开发人员说看不懂我们的用例。我心想是你不好好看吧，我们都看代码了，你还看不懂用例呀。此时PM发话了，说我不该谴责他们不评审用例，因为一来没时间，二来也找不出问题。还做了个比喻，说如果叫测试组评审代码，能发现所有问题吗？
这叫什么事呀！难道做测试的要全才？即会开发，又会分析需求，更要会测试？
不光这个项目，我们公司所有项目都如出一辙，没有像样的需求。但这是可以通过沟通来弥补的。只是我那个团队的PM特别的狠，发明了这么新颖的理论。或者说这种理论早已问世，是我孤陋寡闻？

作者: wxm2004734 时间: 2009-6-5 09:34
这样的测试要求测试人员比开发人员还牛，目前这样小项目一般只有NB的项目经理和开发组长可以。

做为测试人员，比较难。如果我能做，可以给我PM的开发组长的工资吗？？？

作者: archonwang 时间: 2009-6-5 09:45
呵呵。达到这个水准的测试人员不是没有，不过测试已经不是他的主要工作了。
一个能够支撑开发团队，提供对需求、设计、代码逻辑等各方面达到一定水准的测试人员，很难找，也很贵。。。

另外，如果感觉有困难，还是请pm另觅高人吧。当然，还得在项目预算之内。

关于需求，不断沟通，不断确认，不断存档，不断跟踪，只能这样。如果在和客户及技术团队沟通之前，最好是提供原型，这样讨论起来比较实际。否则基本上都是纸上谈兵。没什么搞头，最后大家的认知很可能风马牛不相及。

作者: wangshuman 时间: 2009-6-5 09:54
我挺喜欢你们的工作内容的，我们现在的测试根本与代码及数据库沾不到边，感觉特没意思，做了一段时间都快把以前的编程知识及数据库知识给丢了，面对这种情况应该赶快加强自身的知识水平，没有压力就没有动力啊！

作者: mayslm601 时间: 2009-6-5 10:40
我觉得自动化测试蛮好一方面可以做测试执行方面的一方面还可以写代码不至于那么无聊一句话说的好自动化测试可以把注意力转移到测试用例的设计上而不是执行上

作者: ladyjanice 时间: 2009-6-5 11:40
有些问题需要别人的支持，而我们只能尽量做好自己的本份工作。

作者: tails82 时间: 2009-6-5 21:22
标题: 回复 5# 的帖子
自动化在需要重复执行的情况下确实好。但也有前提。整个项目必须要考虑到自动化测试的需求。而且自动化要求版本是稳定的，需求是明确的，预期结果和实际结果都是很明确的才行。以我目前的项目，算了吧。。。

作者: tails82 时间: 2009-6-5 21:29
标题: 回复 4# 的帖子
这位兄弟说的也有几分道理。如果不和代码打交道，不和数据库打交道，确实会在代码能力上不断退步。作为测试人员，学习这些知识是为了了解开发技术，从而提高测试用例的设计能力。
现在我的情况是，即使我会，也不敢让PM知道我还会写代码，不然以后再也得不到需求了，直接一堆代码扔过来。

作者: 千里 时间: 2009-6-9 11:41
我们测试组不像开发组那么熟悉代码，让我们研究有点困难。PM认为这不是理由。
开发人员说看不懂我们的用例。此时PM发话了，说我不该谴责他们不评审用例，因为一来没时间，二来也找不出问题。
唉。。。。。

[ 本帖最后由千里于 2009-6-9 11:45 编辑 ]

作者: archonwang 时间: 2009-6-9 13:22
那就更简单了，既然不评审，那么测试出来的结果必须接受。因为不评审，有很多需求导致的差异化认知就必须要由开发组承担最后的责任。我给你机会纠正我的错误，你不要。那么后面进度上的滞后必须由开发组承担后果。

评审粗看是加大了工作量和工作内容，但最主要的是，评审可以规避显而易见的错误和问题。不知道你们的开发组和TL是否意识到了这一点。

作者: longago 时间: 2009-6-10 15:23
标题: 无语
没有明确需求就不能开展测试，否则得出的结果也是不准确的。宁愿什么也不做，也不要基于假设去做什么，否则费力又不讨好。另外公司流程对测试的工作的开展来说是非常重要的，和客户确认好需求是PM的职责，和你们的老大好好沟通一下。

作者: 兆隆8032 时间: 2009-6-10 15:59
很多的PM都是拿工期啊，客户注重什么的来说事的，需要你的时候就说：“辛苦一下怎么怎么样的”，等项目完了就是没时间改了，放到以后吧，这个对客户不重要云云。
PM的不作为使我们很难啊……

作者: peterz 时间: 2009-6-10 23:19
碰上一个好的PM比碰上一个好单位都难。现在很多人都是在混。没办法。不正规的公司没发展。

作者: name135791 时间: 2009-6-19 01:24
你们pm完全是偏向开发那边，你们基本算是调试组，而不是测试组了

作者: zuojian26 时间: 2009-6-19 09:46
测试的目的就是为了验证需求.......

作者: tails82 时间: 2009-6-24 13:30
说的好，我们就是调试组，炮灰组。

作者: woza 时间: 2009-6-24 20:08
我觉得可以让测试人员和开发人员坐在一起工作。开发完成一点，就测试一点。这样沟通效率高，而且不会把测试压力全部留到项目后期。还可以让整个团队来承担质量责任，而不仅仅是测试人员。

更好的做法是进行测试驱动开发。在代码开始之前，由测试和开发人员一起确定每个功能的通过标准。这样的话，测试起来好坏一目了然。开发也不会有意见。

作者: nish 时间: 2009-6-25 09:47
遇到这样的项目其实开发人员也是很茫然的，所以我们要相互理解，多沟通。
可以像楼上说的可以和开发一起制定通过的标准，但是这个标准一定要得到客户的确认。
要不然就产生了一个误区：我们很可能被开发误导，认为开发的实现就是对的，从而不能很好的达到测试目的。

我现在的工作好多都是这种升级的项目，情况和楼主描述的差不多

作者: woza 时间: 2009-6-25 13:20
ls说的很对。通过标准应该是开发测试已即客户一起制定的。如果要修改，也要大家一起同意。

作者: 白杨树3344 时间: 2009-6-26 13:20
有压力会有成长的

作者: tails82 时间: 2009-6-26 13:56

原帖由 woza 于 2009-6-24 20:08 发表
我觉得可以让测试人员和开发人员坐在一起工作。开发完成一点，就测试一点。这样沟通效率高，而且不会把测试压力全部留到项目后期。还可以让整个团队来承担质量责任，而不仅仅是测试人员。

更好的做法是进行测试驱 ...

这个比较可行，我会在下个项目中试着这样做。只是客户的回复还是很缓慢的，这又是另一个障碍，只能再慢慢摸索了。谢谢！

[ 本帖最后由 tails82 于 2009-6-26 14:00 编辑 ]

作者: woza 时间: 2009-6-27 13:34
客户反馈的问题可以有几种解决方案。敏捷实践中，是通过快速发布，来获得用户反馈。
如果能够把用户直接拉过来，一起参与开发最好。不行的话，就把公司的产品经理，或者业务分析人员，拉过来一起开发。
如果你不确定客户需要什么，就尽可能少开发新功能，不要去猜想客户可能会有的需求。尽快把产品推向客户。只要用户有反馈，哪怕是负面的，也比自己闭门造车要好。

作者: petrel100 时间: 2009-6-28 11:15
看来我是幸运的一个
我们的需求和设计文档都很全面
但是项目经理和项目经理还是不同的
偶尔看到设计里没有实现一些需求,或设计不合理,在一个项目经理那里提,会有很好的对待,会表扬你,会修改
在另一个项目经理那里提,他会让你认真写好你的用例...所以,做测试也要懂得察言观色

作者: jlsv 时间: 2009-6-30 14:57
如果需求都不清楚的话，然后有人要你去研究需求，上面的朋友已经说了，和开发坐在一起研究，发挥各自的优点（开发注重技术实现，业务方面可能差点，测试人员往往可以在业务方面发挥作用），这样得到的需求也可以快速达成共识。当然了，这个阶段还需要和客户沟通，证实和完善你们的研究成果。

题外话，测试人员我觉得应该先从整体理解整个软件的功能实现了什么，中间那些环节可能容易出问题等等，顶多研究一下内部实现架构，不需要一下子就扑在细节的实现上（比如数据库表都是储存什么数据啊，有些什么类啊，界面用了什么技术啊）。这些是开发人员的工作，也是他们的强项，有时你从他们那里获得你想知道的东西就行了。

等需求出来了，编写用例，发现疑问和bug，都和开发组的同事或者PM提出，然后提出你自己的建议和分析，让他们明白这些改进能够提高软件质量，对大家都有利，他们就会去改了。如果碰到说没时间或者不管的，你只能尽人事了，毕竟质量的保证是参加项目的全部人员的共同责任，只有测试热心是没有用的。

楼主面对的情况，往往是PM不清楚测试人员的工作方法。前面的朋友说得很贴切，把测试组当成调试组了。如果让PM发觉测试人员能够从另外一个角度对项目组做贡献而不是依附开发人员做开发，自然他就会重视和理解你的工作了。

[ 本帖最后由 jlsv 于 2009-6-30 15:03 编辑 ]

作者: black_tulip 时间: 2009-8-13 18:48
“要求评审。结果一直没音讯，只好作罢。”

// 这一步没有做，就不应该做下一步。要评审，并且在PM通过后请他签字。最不济也是发出email，附件用例，请他回复邮件确认同意通过。email是cc到所有相关人和领导的。

《说不清，写下来》。

其实，看上去，你说的这个PM，应该只是研发部主管之类，而不是这个项目的总负责。

作者: houzeal 时间: 2009-8-14 11:34
混乱中痛苦，痛苦中挣扎，挣扎中进步！！

作者: wendy811110 时间: 2009-8-15 18:48
建议投诉这个PM。这个PM严重不合格～～

作者: liujinkui 时间: 2009-8-15 19:27
体会。

作者: goole 时间: 2009-8-18 13:37
组织在考验你呢。。。你快升官了。兄弟顶住！

作者: 41832990 时间: 2009-8-18 13:44
就我的了解来看
现在的测试技术性不并不是那么的强
首先作为一个测试人员心态要放的高傲一点
因为一个好的测试人员如果是从开发走过来的话那绝对是个好的人才
对软件的各个需求或者其他方面都能有个比较透彻的了解
如果不是就像PM说的测试怎么能不会点代码呢某些基本的东西还是要自己去摸索去了解的
能够克服这样那样的困难应该成为一个好的tester

作者: koala114 时间: 2010-10-25 12:28
不知现在怎么样了呀~

作者: zwd183335 时间: 2010-10-25 17:20
管理有问题，主管不能有所偏见，但做为测试人员多学是没有错的，特别是代码部分，还有就是与开发人员的沟通很重要，不要跟开发人员有仇似的。

作者: bingyan5225 时间: 2010-10-25 17:46
无奈总是难免的，学呀学呀使劲地学。。。

作者: lona_mn 时间: 2010-10-25 21:53
这位老兄还是挺强的，测试驱动敏捷开发都懂，那么看看代码应该不是问题。我们做测试的，需要全才是肯定的，需求、开发、测试，加上一般的数据库操作系统调优之类的。只是看代码不太现实，代码中如何看出业务逻辑，客户需求。就是白盒测试也不能看代码测，更何况其他测试。最好的办法就是自己摸索整理出一份需求概要，然后找个客户确认一下，明白客户的需要才是真。

作者: binlaw 时间: 2010-10-26 09:14
我认为楼主面临的问题不是一个测试的问题，而是一个项目管理的问题。而且这个项目管理，不是从PM那里可以得到解决，必须从组织上去解决。

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