51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 5345|回复: 19
打印 上一主题 下一主题

[原创] 无聊的主管,怎么办!

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-12-3 13:50:33 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
我们公司的测试人员是一个人负责一个项目的,测试组也有10个人!
基本上都有评审需求,写测试用例,然后评审用例,然后修改用例,然后执行测试....
前天做了一个项目,到最后测试完了,开发说漏掉了一个重要的需求没有测试到,他们发现了BUG,发现就发现了呗,非得在什么公司高级领导面前炫耀自己然后批评我!
然后我们组的领导就一直跟我说什么漏测这个,什么多严重多严重的,然后别人怎么说怎么说的!
现在拿项目给我测试非得多说几句什么注意需求,什么上次你的漏测什么怎么样的,靠,真想一巴掌拍死他们!

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

真的累,不太想干了,又是12月了,又要考核了,一年一次,还得降薪,估计我上次漏测那个,估计得挨好几刀,没则,过年后考虑闪人,碰到一个垃圾主管窝气还火大!
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2008-12-3 14:13:10 | 只看该作者
小同志怎么那么多怨言,哈哈
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2008-12-3 14:30:50 | 只看该作者
工作嘛,涂个开心,做得不开心,就走吧。。。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

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

    使用道具 举报

    该用户从未签到

    5#
     楼主| 发表于 2008-12-3 17:26:47 | 只看该作者

    回复 4# 的帖子

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

    使用道具 举报

    该用户从未签到

    6#
    发表于 2008-12-3 17:36:10 | 只看该作者
    错了就是错了。
    1、我以为成功就成功,状态显示成功。说明你没有理解软件,也没有去问。
    2、评审是帮助你发现你的遗漏,但是你漏了就是你的责任。
    3、如果需求书没有写好,有前面估计时就应该考虑到。要多提意见,多交流,多防范风险。

    如果没有做到,那责任就是责任,不会因为你没有考虑这些,就没有责任了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2008-12-4 11:09:37 | 只看该作者
    如果换工作,首先要改变自己。以楼主目前的心态,很难说。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2008-12-4 13:15:25 | 只看该作者
    同意楼上的,如果我是主管,遇到楼主如此心态的 怕也要多叮嘱了,呵呵。先摆正心态哦,不然换工作也
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    10#
    发表于 2008-12-5 10:29:38 | 只看该作者
    不开心就走了!
    是人才还害怕找不到工作吗?
    闪了。。。。。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2008-12-5 17:39:27 | 只看该作者
    他唠叨他的 不用太往心里去 摆正好自己的心疼 做出出色的成绩回击他
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2008-12-8 12:04:53 | 只看该作者
    我觉得这不是错与对的问题。
    要是我是你,如果碰到有人总是旧事重提,不管是否善意,我会直接表达我的不满。
    你工作的平台是很重要的,如果流程比较完善,责任会划的很清。
    如果流程不规范,boss又比较专制,你又不去努力沟通,表达你自己的困难,这个就没办法了。
    吃人嘴短,要么改善自己,要么走人。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    [ 本帖最后由 zengyixun 于 2008-12-8 14:59 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2008-12-24 12:03:05 | 只看该作者
    消消火,这里抱怨不要紧,回公司时好好干,别人怎么样是别人的事,你怎么抱怨就是你的事了
    测试很需要心态的,不管是工作上,还是对于测试职业发展上
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2008-12-24 15:03:24 | 只看该作者

    沟通万岁!

    沟通万岁!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    17#
    发表于 2008-12-31 11:51:39 | 只看该作者
    多方面的问题,但是你要去分析问题的根源,想想有没有什么比较好的解决办法,实在呆得郁闷就考虑换工作吧,不要让自己太压抑
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2009-1-8 00:11:19 | 只看该作者

    建议楼主把这些话,保存起来,一年或者二年以后再来看待这些事情,

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

    如果你尝试了你所能想到的方法,问题还不能解决,可以考虑换下环境。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2016-4-26 13:27
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    19#
    发表于 2009-1-8 14:10:25 | 只看该作者
    楼主可以改行了!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2009-1-8 23:40:33 | 只看该作者
    多从自己身上找原因,对自己要求严格点没坏处的。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-26 19:59 , Processed in 0.105607 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表