实在是怒了，混乱中的测试

tails82

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

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

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

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

woza

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

petrel100

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

jlsv

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

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

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

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

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

black_tulip

“要求评审。结果一直没音讯，只好作罢。”

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

《说不清，写下来》。

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

houzeal

混乱中痛苦，痛苦中挣扎，挣扎中进步！！

wendy811110

建议投诉这个PM。这个PM严重不合格～～

liujinkui

体会。

goole

组织在考验你呢。。。你快升官了。兄弟顶住！

41832990

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

koala114

不知现在怎么样了呀~

zwd183335

管理有问题，主管不能有所偏见，但做为测试人员多学是没有错的，特别是代码部分，还有就是与开发人员的沟通很重要，不要跟开发人员有仇似的。

bingyan5225

无奈总是难免的，学呀学呀使劲地学。。。

lona_mn

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

binlaw

我认为楼主面临的问题不是一个测试的问题，而是一个项目管理的问题。而且这个项目管理，不是从PM那里可以得到解决，必须从组织上去解决。