无聊的主管，怎么办！

素还真

我们公司的测试人员是一个人负责一个项目的，测试组也有10个人！
基本上都有评审需求，写测试用例，然后评审用例，然后修改用例，然后执行测试....
前天做了一个项目，到最后测试完了，开发说漏掉了一个重要的需求没有测试到，他们发现了BUG，发现就发现了呗，非得在什么公司高级领导面前炫耀自己然后批评我！
然后我们组的领导就一直跟我说什么漏测这个，什么多严重多严重的，然后别人怎么说怎么说的！
现在拿项目给我测试非得多说几句什么注意需求，什么上次你的漏测什么怎么样的，靠，真想一巴掌拍死他们！

1.我写测试用例没错，错是我在先，难道我没提交测试用例评审么？把全部责任全部给我？开发算什么？他们评审自己的毛么？如果我有责任他们没责任么？
2.你主管JJYY说个毛呀，一天到晚说，还次次说，你不烦我都烦了，主管要当到你这份了，靠，当初真瞎眼进这个公司！
3.我不是万能的，需求写得跟没写一样，本身用例就难写，写个什么操作员登记报告，NND,报告里面有啥？什么都没有详细描述，项目经理怎么不先批评你那垃圾需求！

真的累，不太想干了，又是12月了，又要考核了，一年一次，还得降薪，估计我上次漏测那个，估计得挨好几刀，没则，过年后考虑闪人，碰到一个垃圾主管窝气还火大！

whyleave

多从自己身上找原因，对自己要求严格点没坏处的。

liaoxj

楼主可以改行了！

tnt277

1.我写测试用例没错，错是我在先，难道我没提交测试用例评审么？把全部责任全部给我？开发算什么？他们评审自己的毛么？如果我有责任他们没责任么？
这种情况说下我的处理方式，首先说明下，测试用例不漏是不可能的
一） 首先我会承认失误，某些方面没考虑到，谢谢大家的提醒，以后的测试还需要大家的帮助
二） 如果是发现错误时，没有通知你，而直接通知高层，那么首先还是承认自己的失误，然后嘛就看自己的处理方式呢；你可以要求改善测试与开发之间的关系（从你说的这些方面来看，你们公司测试与开发关系很僵），不要互相去争吵什么，那只会将事情变得更糟，
三） 找些机会想开发和高层灌输测试方面的一些理论与技术，测试会有遗漏就和程序会有BUG一样 很多时候是没法避免的，人不是机器 不可能不犯错
四）对于测试用例漏执行的，如果不是用例管理出现问题，就要认真考虑下工作态度呢
2.你主管JJYY说个毛呀，一天到晚说，还次次说，你不烦我都烦了，主管要当到你这份了，靠，当初真瞎眼进这个公司！
一）没有任何公司是完美的
二）主管是否了解你的工作过程，工作程度，你是否了解主管的压力；如果可能的话，可以提出与主管进行一场非正式的面谈，
3.我不是万能的，需求写得跟没写一样，本身用例就难写，写个什么操作员登记报告，NND,报告里面有啥？什么都没有详细描述，项目经理怎么不先批评你那垃圾需求！
一）有问题可以提，但记住一点 事情没发生之前揭丑比事后揭丑要好很多

如果你尝试了你所能想到的方法，问题还不能解决，可以考虑换下环境。

水上飘

多方面的问题，但是你要去分析问题的根源，想想有没有什么比较好的解决办法，实在呆得郁闷就考虑换工作吧，不要让自己太压抑

fishsky

评审不仔细。还要评审干什么？不如不要算了。反正出了问题都是测试员担着。其实我觉得你主管呢，也意识到了自己的失误了。所以每次他提醒你，其实也是在提醒他自己。LZ，你觉得呢？环境决定做事方式。就像你说的，你们公司的需求做的不好。摆在你面前的就三条路：1.说服老总，引进CMM，直接强行开发规范--恐怕你现在做不到；2.适应你们公司的环境，调整好心态--这点比较容易，虽然自己不是特别愿意接受；3.管他娘的，走人。

nmtcolin

沟通万岁!

stjd139

消消火，这里抱怨不要紧，回公司时好好干，别人怎么样是别人的事，你怎么抱怨就是你的事了
测试很需要心态的，不管是工作上，还是对于测试职业发展上

zengyixun

我觉得大家的谈话都不太公正，自己也是做测试的还做这种评价，这就难怪测试没有地位了，平心而论如果真是按“都有评审需求，写测试用例，然后评审用例，然后修改用例，然后执行测试”这种流程在做事，那参与评审及开发领导与测试领导才是最大的责任者，不能让小兵当替死鬼，做领导要有担当，参与评审的每个人都要有担当，这样才能改善流程中的毛病，如果直接就把罪过给了小兵，也就是说这次过程回顾检视问题，得出的结论就是小兵有问题，那很明显没有发现过程中的根本问题，那么下一次这样的问题定然会再现，又去怪小兵，长此以往，到公司败亡那一天就止了！
我以前有一家公司，一出问题就开始回顾检视，结论就是测试部有问题，却不想想一家公司做一件事，那是所有部门都在参与的，问题一回顾到测试部，罪名放下去了，就完了吗？找问题，应该是在一个工作流程中的所有点上都要进行检视，要看这些点上都产生了什么问题才导致了最后的问题，通常问题的产生都不可能是一个点，只是说表象上看是在这个点上爆发而已，这就如同我们做测试，也要在全流程中参与测试，否则最后出问题的可能就相当大，否则最后的表现就是在验收测试或者系统测试上问题集中爆发！到我走的时候，测试部全部人都换了，但原来的测试部有什么问题，新的还是有什么问题，人都换光了，问题还是一样？都不想想为什么吗？

[ 本帖最后由 zengyixun 于 2008-12-8 14:59 编辑 ]

biscuit

我觉得这不是错与对的问题。
要是我是你，如果碰到有人总是旧事重提，不管是否善意，我会直接表达我的不满。
你工作的平台是很重要的，如果流程比较完善，责任会划的很清。
如果流程不规范，boss又比较专制，你又不去努力沟通，表达你自己的困难，这个就没办法了。
吃人嘴短，要么改善自己，要么走人。

dujun

他唠叨他的 不用太往心里去 摆正好自己的心疼 做出出色的成绩回击他

xiaoshi8

不开心就走了！
是人才还害怕找不到工作吗？
闪了。。。。。。。

gxlapple0701

在这个问题上，主管其实是要负一定的责任的，一些问题的处理和处理方式的确很不到位，开发和其他相关人员也应该对自己审核的case负责，但是，回过头来说作为直接负责人，你还是应该负直接责任，和主要责任吧，毕竟你才是这个项目的直接负责人，执行者。
看楼主的口气，是非常的气氛啊，但感觉更多的其实是对你的主管对你的态度的不信任，呵呵，这样的话就要像办法解决这个问题了， 楼主静下心来，重新整理一下工作，沟通，测试，各个方面的问题，换个角度去理解，理顺，沟通，达到解决问题的目的。
不管什么公司，都有自己的已经存在的工作方式，你要么接受，融合，合作，然后才能改善，提高，共赢！

testlc

同意楼上的，如果我是主管，遇到楼主如此心态的 怕也要多叮嘱了，呵呵。先摆正心态哦，不然换工作也

lithos

如果换工作，首先要改变自己。以楼主目前的心态，很难说。。。

雪儿

错了就是错了。
1、我以为成功就成功，状态显示成功。说明你没有理解软件，也没有去问。
2、评审是帮助你发现你的遗漏，但是你漏了就是你的责任。
3、如果需求书没有写好，有前面估计时就应该考虑到。要多提意见，多交流，多防范风险。

如果没有做到，那责任就是责任，不会因为你没有考虑这些，就没有责任了。

素还真

等你来了我这公司你就知道了，啥叫需求！就是讲一个大概功能
我当初理解需求的时候就是理解错了，导致用例漏掉了那个功能，比如一个功能成功了，成功就成功了呗，需求里面说道记录相应的成功信息，我以为成功就成功，状态显示成功，检查客户端是否成功状态不可修改这类的，并没有考虑过多，后来听说成功还需要提交什么数据在里面，哎
在我这公司里，测试人员感觉就比开发矮一截，什么事情好像都是他们是老大，非得跟他们怎么怎么套近乎，测试人员在这个公司根本没什么地位。而开发写的需求，只能说你去小公司看那种需求就大概是那种了，可能比那种还牛B，跟之前我在前一家公司里面看到的那种需求那简直是天狼之别

archonwang

看得出楼主怨气很大，我觉得问题很简单
1. 看楼主的叙述，说明没有很好的把规矩做好，缺乏有效的框架，所以，有很多事情可以乱来，比如需求遗漏。如果有良好的测试需求评审机制，相信是不会出现问题的。这方面，测试部门的主要领导要负起连带责任；
2. 漏测？为什么漏测？楼主只是说明了现象，并没有说明原因。这个原因才是症结。你的主管这样说你，也是说明的确有工作没有做到位，问题是不是说完了事，而是要想办法在下次不出现这样的问题。有问题必然有方法！
3. 至于为什么每次项目下来都要说几次需求的问题，那是因为这是项目开发之本。无论哪家公司都一样。至于上次的事情，过去了就过去了，没什么好说的。从楼主你的身上来看，重要的是怎么让你的主管放心的问题，而不是仅仅几句唠叨而已。
4. 如果需求写得跟没有一样，你当初为什么不提？如果当初提出了，开发团队没有理睬，那是他们的问题，后面出现了问题就很明白了，有前因才有后果。事务的先后次序要分析清楚。至于说公司的项目经理如何调和开发和测试的关系，一方面需要加深培训，另外要你的测试主管把开发的考核加入到考核体系里去，例如：需求的制定和后期的测试是存在必然关系的，需求做不好，测试在过程上，方法上和结果上都会存在问题，首要的问题是解决需求的对应问题，楼主需要考虑是否要求加入需求工作中去。

鹭岛

工作嘛，涂个开心，做得不开心，就走吧。。。

cleo

小同志怎么那么多怨言，哈哈