51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 11556|回复: 23
打印 上一主题 下一主题

[讨论] 开发人员自测不充分就提交测试,影响效率

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-12-17 15:58:45 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
我们部门开发人员提交测试前,都是要求自测通过才提交给我们测试的,但是有些开发人员因为开发时间延迟,老是不自测或是随便自测一下就提交给测试,到了我们测试就有很多明显的问题出现,浪费大家时间,大家有什么好的方法处理啊
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-12-17 16:07:25 | 只看该作者
在系统测试前先进行一轮冒烟测试
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-12-20 16:44:43 | 只看该作者
需要加强管理,比如转测试不通过率指标来卡
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2009-12-21 15:50:52 | 只看该作者
管理    王道
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    5#
    发表于 2009-12-22 18:00:49 | 只看该作者
    可以在测试报告中总结描述一下这些问题,让领导们知道这样的后果

    例如说,由于自测不充分多了多少BUG,多少测试时间之类的,有数据好说话

    [ 本帖最后由 msnshow 于 2009-12-22 18:02 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2009-12-28 17:29:18 | 只看该作者
    管理才是王道~~~

    当然也要看程序员能力了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2010-1-5 15:39:36 | 只看该作者
    最好能有一个比例,测试项目提交20条,BUG报了15个  这样就没有必要在测试下去了,发个邮件,让他们重新开发。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2010-1-6 20:10:43 | 只看该作者
    在冒烟前,测试给开发提供一个冒烟主功能清单(可以挑选冒烟主流程),让开发自测,并发邮件通知相关人员(包括老大)他们的自测结果,哪个pass,哪个failed。等冒烟测试时,测试人员再对照冒烟功能测试一遍,如果还是有很多问题没解决,那么同样的发邮件给相关人员。两次邮件对比,老大们都会知道,问题出在哪里,怎么出对策,让老大们从上而下的管制当然来得要快哦!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2010-1-11 10:47:51 | 只看该作者
    这个问题的根本是项目管理未到位,导致测试人员在给开发人员“擦屁股”,最终导致项目进度不可控,项目质量不可预估等问题。
    1、如果你们公司管理比较严格,则建议制定流程规范,使用流程规范开发人员提交到测试团队的代码质量。如:流程中规定:开发人员提交到测试团队的版本必须经过单元测试、集成测试(单元测试、集成测试可由测试人员提供,开发人员、测试人员、项目管理人员共同审核提取),这样就会在一定程度上保证了测试人员拿到的测试版本的可测试性,避免了一些不必要的时间花费和扯皮。
    2、如果你们公司对于项目管理还未如此严格,那只能说服项目负责人督促开发人员做好这一切。说服项目负责人要说清楚以下几个问题:
    1)开发人员提交的版本如何不具有可测试性(一定要提出有效的证据)
    2)由于提交的测试版本质量不高,浪费了多少人力资源成本,导致了项目延迟多久
    3)你认为如何保证开发人员提交到测试团队的代码质量(一定要提出一套可行的方法)
    4)根据你的方法粗估下测试效率会提高多少,对项目保质保量的完成会做出多大贡献
    5)建议可根据你的方法在某个项目上试行,进行数据统计,实际跟踪用统计数据来说明如此改进会带来的好处
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2010-1-22 09:12:41 | 只看该作者
    难道没有对开发人员的bug数进行考核吗?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2010-1-23 14:54:56 | 只看该作者
    打回去阿,如果不可测。而且可以统计不同版本上的开发导致的bug数
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2010-1-29 22:02:56 | 只看该作者
    原帖由 msnshow 于 2009-12-22 18:00 发表
    可以在测试报告中总结描述一下这些问题,让领导们知道这样的后果

    例如说,由于自测不充分多了多少BUG,多少测试时间之类的,有数据好说话

    恩 说的很对 数据才是王道
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2010-2-2 14:10:12 | 只看该作者
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2010-2-2 14:10:36 | 只看该作者
    顶。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
     楼主| 发表于 2010-2-8 17:40:15 | 只看该作者
    原帖由 jiou99 于 2010-1-11 10:47 发表
    这个问题的根本是项目管理未到位,导致测试人员在给开发人员“擦屁股”,最终导致项目进度不可控,项目质量不可预估等问题。
    1、如果你们公司管理比较严格,则建议制定流程规范,使用流程规范开发人员提交到测试团队 ...


    3)你认为如何保证开发人员提交到测试团队的代码质量(一定要提出一套可行的方法)
    关于这条能不能给个具体的建议啊,我也不知道根据什么评定代码质量?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2010-2-8 17:50:07 | 只看该作者
    额哪,是呀,我们公司也是,这方面管理也向上级部门提出过了,开会也说了,文档上也写了,可是到现在也不管用,还是那样,开发出来了,直接扔给我们测试,他们从不自测。。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2010-4-1 11:31:06 | 只看该作者
    O(∩_∩)O哈哈~
    如果这样的测试情况是在管理层领导安排下来的呢?
    他们随时可以说“有个紧急任务”,今天测试完成,哈哈,什么都没有哦,怎么办呢?领导说,开发和测试一起测试,呵呵,在开发的电脑上测试,开发一会儿编译一下(他自己还在改缺陷),测试人员根本不能测试。
    会议上定的,文档上写的,谁管呢?倒霉的是我们( ⊙ o ⊙ )啊!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2010-4-1 11:31:29 | 只看该作者
    这样的情况,赶紧闪人
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2010-4-1 19:06:27 | 只看该作者
    都是一个公司的,和谐才是主导。开发人员没有经过很好的自测就提交给测试人员,说明这个开发人员经验不足,我们也曾经走过这样的路子。所以这个首先不应该生气,而是协商。
    经过一次测试后,可以找这个开发人员谈谈,都是一公司的,就是缘分,就能做朋友。我想他也能理解你的苦衷。如果他不给你面子,那到时候再另说哦
    在年轻时候,不要为了那一点点考核的绩效钱去破坏自己为人的原则以及交友的机会,我想这样是得不偿失的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2010-10-26 14:43:44 | 只看该作者
    呵呵,我们公司就是考虑到这种情况,所以才把以前的一般测试形式,进行过程改进,形成现在的“放行测试”形式的。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-23 15:05 , Processed in 0.086249 second(s), 32 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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