51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 8428|回复: 28
打印 上一主题 下一主题

[原创] 共享麻烦,有“难”众解决

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-2-11 09:24:47 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
各位测试主管、质量管理人员:
在这里启动一个帖子,所有测试管理版块的从事测试方面管理的人员大家共同“分享”在各自领域遇上的管理方面麻烦和困难,在这里可以尽情地吐吐苦水,把详细情况描述一番。
我们在这个帖子的互动过程中尽量避免过多的教程式解答、讨论,针对一个问题讨论一个问题,遇上一个问题从实际出发解答一个问题,启动所有测试管理人才的智慧解决个人的工作困难和管理瓶颈。
另一方面因为测试管理人员所面临的问题能更典型、更深层次地反映我们国内测试存在的普遍问题、现象,透过大家一起提供的这些现象或许我们能在这里总结出一二,以使大家“活”得更明白,或者实在不幸运的测试管理人才“死”也“死”得其所。

请大家在发帖提问或回复过程遵循以下规则:

1、提问者发帖请在内容前加注:   [提问1],其中“1”表示的帖子中发表的第几个问题,按顺序递增

2、回复解答者发帖请在内容前加注: [答复1],其中“1”表示的帖子中发表的第几个问题,解答的是该问题

斑竹将定时整理所有问题和回复,将同一个问题的提问和回复整理到一个主题中,以方便大家参阅

[ 本帖最后由 billrub 于 2007-4-3 12:23 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2007-2-11 10:19:49 | 只看该作者
呵呵,不错不错,支持一下
回复 支持 反对

使用道具 举报

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

    连续签到: 1 天

    [LV.5]测试团长

    3#
    发表于 2007-2-12 23:34:10 | 只看该作者
    纯支持。大家一起努力啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2007-2-25 09:33:54 | 只看该作者

    提问1

    合同所表述的需求不明确,之后又无需求调研,需求不明确,合同期限又短,前期赶工要死,后期维护测试反反复复,导致测试效果和软件质量差。

    [ 本帖最后由 billrub 于 2007-3-6 13:07 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2007-3-1 16:19:49 | 只看该作者
    同意4楼的观点。深有同感。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2007-3-4 14:30:12 | 只看该作者

    你愿意帮我测试一下这个软件吗?

      我写了一个企业文档管理软件(递易),已出Beta版,这个软件主要应用于软件企业,由于本人测试条件的限制,希望有人对进行更严格的测试,这个软件中的BUG管理或许还对你的工作有用。

      软件下载地址:download.csdn.net 用“递易”做关键字进行搜索,即可下载该软件的三个部分;

      测试类型:系统测试、功能测试;

      测试方法:黑盒测试或自动测试;

      测试依据:软件自带的Help;

      谢谢。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
     楼主| 发表于 2007-3-6 13:06:31 | 只看该作者
    [答复1]
         aramis001,针对你的情况应该说公司的需求管理过程控制不够好,公司项目的整个开发流程也是处于随意性较大,规范性和严肃性较弱的状态下。那么我建议你可以有以下几种方式可以尝试:
         1、如果你作为测试主管在公司有足够的影响力,可以提出明确的需求管理规范和流程,采取棍棒政策从上往下强力执行,当然需要注意2个问题:(1)推行的过程是成熟的有成功案例的过程;(2)是适合公司的流程的,这点非常重要,提一下关于这点你可以思考一个问题“开发团队中的各个角色他们都在想些什么,期望些什么?”,作为过程改进的开端工作;
         2、如果你在公司如同大多数测试主管在公司未能足够强悍,那么你可以尝试去规范你的测试需求,让过程以下推上;如:冒烟测试 >> 测试需求 >> 程序 >> 项目需求,以你测试的标准和过程规范去推进开发过程前端规程的规范,当然这个做法往往需要持之以恒,周期性较长;
         3、测试团队在公司中影响力确实比较低下,第2种做法自然也就显得苍白而不可行。那么剩下一步:你无法改变它,那你就顺着它,“诱导”它。你可以“消极”地去思考:我怎么样能取到测试任务开始时需要的必备内容?通过你能想象的和可以执行的所有方式去达到这个目的(口头?即时通讯?电话?临时会议?),过程没有固定的规范和稳定的周期,但你必须保证可以在随意性较大的情况下得到你想要的必须内容(比如:你无法规范程序员和项目经理做些什么,但你作为测试主管你可以规范你测试成员的行为;而程序员此时只能接受口头的方式,那么测试任务开始之前测试组长需要做一步额外的工作:从项目经理和程序员嘴下进行需求调研)

    [ 本帖最后由 billrub 于 2007-4-3 12:23 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2007-3-30 20:28:18 | 只看该作者

    提问2 ,在分配测试任务的时候,使用什么样的标准模量清晰准确无争议?

    我刚刚接手管理测试组,公司里的很多管理不规范.有很多规范文档和制度都在制定当中。由于公司的定位问题,导到很多测试任务有个最大的特色就是短、频、快。每个需求一般不会超过5天,基本上都是在一两天内能完成的事情。但最近发生了些事情,让我时常想起在下达任务的时候,要包括那些因素才可以使测试任务显示清晰、准确、无争议。
    先说我一下我自己做的 (我们是通过邮件下达任务),邮件标题是任务名称,邮件内容包括以下几点:
    1。任务名称或需求名称,该任务对应的需求文档存放地址,或将需求直接附在邮件中。
    2。开发人员姓名及分工,开发结束时间。在涉及多个开发人员时,会附上每个开发人员负责的具体任务。
    3。测试人员姓名,如是多人合作则注明那个人负责该项目的总体进度控制和测试结果确认。
    4。测试结束后需要提交的文档及各类文档提交的时间限制。
    5。任务其他补充说明。
    我以为这样的任务下达已经很清楚了,但今天有人问我说下达有任务看不懂。我想了半天还是没想到还有那里遗漏了的,请各位都讨论一下。

    [ 本帖最后由 njalic 于 2007-3-30 20:31 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2007-3-30 20:41:49 | 只看该作者

    问题3,如何对测试人员的学习能力进行个有效的评价?

    相信大多数公司都会考虑这个问题,一个新员工从进入公司,到转正到成长。是有个时间段的。那么在这段时间里,采用那几个方面的标准可以有效的考核员工的学习能力?
    先说一下我自己的做法。
    1。在平时考查测试人员提交的测试文档,检查文档质量是否在比上期有所提升。
    2。通过平时的聊天获得一些员工的想法,指导他们实施测试。当再次分配任务时,通过会对能够用到该技术的地方特别注意,看一下他是否将学习到的东西应用到工作当中去。

    这些毕竟是一些主观上的想法,没有一个具体的标准。比如衡量学习到的东西有没有应用到工作中,估计有时候也很难段定。那么有没有可能制定一种可以像工作质量考核一样的指标来量化学习的知识在工作当中的应用?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
     楼主| 发表于 2007-4-3 12:22:37 | 只看该作者
    呵呵,我想我带个头,大家对问题有不同见解的都可以自由畅谈啊。尤其是各位版主多多发挥余热
    sdlkfj2
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2007-4-15 11:26:11 | 只看该作者
    想我带个头,
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2007-4-18 08:08:02 | 只看该作者

    支持

    支持,支持,良好的规范最重要
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2007-4-18 10:04:31 | 只看该作者
    关注中
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2007-4-25 16:34:06 | 只看该作者
    捞分加支持。sdlkfj2
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2007-4-29 14:44:28 | 只看该作者

    答复3

    可以看他提交的bug 的数量和质量
    查看一下他的工作的态度
    与同事的沟通的能力
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2007-4-30 16:31:40 | 只看该作者
    【答复2】
    我觉的你列的已经很具体了,没什么好在说明了;
    可以直接从他们那了解在需要补充什么,
    很多时候可能是没仔细看清楚吧,所以重点部分要强调下;


    【答复3】
    对测试人员总的考核有:
    提交bug的数量以及bug的本身价值
    测试文档的质量
    测试技能水平(测试用例设计水平,测试工具使用水平,测试结果分析判断水平)
    测试技能以外的综合能力(工作态度,沟通,团队合作,钻研)

    学习能力方面就对这些看进步程度如何了

    我觉得主观评价不代表评价效果就不客观了,
    用具体的标准或具体指标来量化来比较主观的东西能说明就是有效的评价?

    [ 本帖最后由 huangcm 于 2007-4-30 16:43 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2007-5-5 09:50:27 | 只看该作者
    规范的测试非常重要
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2007-5-9 17:13:05 | 只看该作者
    [提问4]当项目较多时,如何进行分配执行工作?

    如项目:A,B,C,D, 人员:甲,乙

    甲乙对项目A,B,C,D,都进行测试,还是分配甲测试项目A,B;乙测试项目C,D好,
    或者其他分配方式?<br>


    补充说明下,项目A,B,C,D不一定全部同时提交测试,可能这段时间只有A,B,C,那段时间只有B,D等,
    怎么分呢?最好具体说下各情况下的分配。

    [ 本帖最后由 huangcm 于 2007-7-17 09:28 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2007-5-10 13:12:11 | 只看该作者

    答复4

    我个人比较倾向于后者,也就是甲测项目A,B; 乙测C,D .
    一个人的精力是有限的,同时负责过多的项目会造成测试的不深入,可能会只测试一些表面层次的功能.而且每个项目的测试重点测试方法都不一样.同时测试很多项目会给测试工作带来混乱.如果能专注的只测其中的一到两上项目,在时间和精力允许的情况下,会比同时测4个项目效果更好些.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2007-5-30 14:59:07 | 只看该作者

    [提问5]测试部门成立后需要建立哪些规范、流程?

    [提问5]测试部门成立后需要建立哪些规范、流程?
    假如公司刚刚成立测试部门,所有都是0起点,那需要建立哪些规范、流程呢?
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-8 16:37 , Processed in 0.098221 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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