|
5#
楼主 |
发表于 2005-6-17 21:13:03
|
只看该作者
2005-06-17 14:22:02 songfun(6975740)
to 小鱼:
你的项目这么多,而且还是一个在过CMM的公司,唯一的改善措施是增加人力资源。
这是你当前工作最大的瓶颈!
2005-06-17 14:23:43 songfun(6975740)
评审的七大误区,可以参考参考。
误区一:评审参与者不了解评审过程
误区二:评审人员评论开发人员,而不是产品
误区三:评审没有被安排进入项目计划
误区四:评审会议变成了问题解决方案讨论会
误区五:评审人员事先对评审材料没有足够了解
误区六:评审人员关注于非实质性问题
误区七:忽视细节
2005-06-17 14:24:46 ray(8085413)
这个不错,经典
2005-06-17 14:25:01 digman(6310930)
误区四:评审会议变成了问题解决方案讨论会,我们刚刚结束的评审,就是这种情况
2005-06-17 14:25:17 songfun(6975740)
看看吧,小鱼,这里的几个忌讳,你犯了几条?呵呵,对评审材料没有足够了解,你就参与这个评审,你说这样的评审怎么可能不流于形式呢?
2005-06-17 14:27:05 gladys(19785708)
评审的时候,经常是找不到技术方面的专家,来了一帮全是做管理的 我们公司的问题
2005-06-17 14:28:27 lemon(9042829)
to digman:指出问题就可以了,解决办法可以下次安排会议再讨论
不然很耽搁时间
2005-06-17 14:29:31 digman(6310930)
对啊,可是他们对于问题解决很有兴趣
2005-06-17 14:30:06 lemon(9042829)
to gladys:评审可以让开发人员参加
2005-06-17 14:30:50 songfun(6975740)
应该把我上传的这份软件评审的文档发给大家看看。
2005-06-17 14:31:06 lemon(9042829)
评审会,只需要让他明白这里有问题就可以了
2005-06-17 14:31:27 songfun(6975740)
大家开个会,先把评审的工作过程定下来再做评审,否则恶性循环,评审让人觉得在浪费时间
2005-06-17 14:34:52 gladys(19785708)
评审是会请开发人员参加的,但这个时候开发人员基本上是不会指出技术问题的,因为谁也不愿说自己做差。。如果说了,别人就会问,既然你知道这不对,为什么不事先改正呢?
2005-06-17 14:36:12 digman(6310930)
哈哈,大家说得是测试产品的评审,我刚才说的是需求评审,项目组的所有人员都参加了
2005-06-17 14:37:51 songfun(6975740)
to gladys:
你这样的评审本身存在问题,开发人员是进行交叉评审。比如一个项目组5个人的话,那么A的部分其实是BCDE在评审。
2005-06-17 14:38:43 songfun(6975740)
还有,评审有很多,比如测试用例的评审,那就是开发的在协助评审测试用例了,就不是“自己”的问题了。
2005-06-17 14:39:22 gladys(19785708)
我们的评审其实没有做那么细,只是在开发过程中的关键点上才做评审。这个时间评审不是针对ABCDE的。。而是针对整个项目组来说,但会请项目组的成员列席参加。
2005-06-17 14:44:03 小鱼(66944928)
今天下午公司开会,我想提出这个问题,跟大家讨论一下测试文档如果进行评审,因为我发现测试质量不高的原因,测试用例的设计不充分是很大原因
2005-06-17 14:45:14 遥远(38135388)
以你的人力资源,你有时间把测试用例写得充分,你有时间执行不?
我同意songfun,你们公司应该考虑招人
2005-06-17 14:45:42 T.E.(28707264)
从你们项目来看,需求在项目进行过程中,变动大么.
2005-06-17 14:45:57 lemon(9042829)
小鱼:你们是做产品还是项目?
2005-06-17 14:46:04 小鱼(66944928)
外包
2005-06-17 14:46:33 T.E.(28707264)
仅仅是测试外包,还是软件全外包
2005-06-17 14:46:41 小鱼(66944928)
变更是家常便饭,即使到了UAT阶段还会有需求变更
2005-06-17 14:46:58 lemon(9042829)
给你们的测试时间是否充裕?
2005-06-17 14:47:00 小鱼(66944928)
body shopping
不充分,但是开发时间同样不充分,到了时间我们就要交
2005-06-17 14:47:40 T.E.(28707264)
V模型试过么.
2005-06-17 14:48:19 小鱼(66944928)
我们用H模式
2005-06-17 14:48:28 小鱼(66944928)
测试驱动开发
2005-06-17 14:48:46 T.E.(28707264)
哦
2005-06-17 14:49:44 lemon(9042829)
在加班都不可能解决的情况下,只有向上级郑重提出:需要加人!
2005-06-17 14:50:01 T.E.(28707264)
对,把风险列出来
2005-06-17 14:50:50 lemon(9042829)
否则你只有权衡一下,列出重点
人的精力毕竟有限
或则你看看是否可以引入工具,提高效率
2005-06-17 14:53:48 阿芳(10294424)
资源不足都存在的。提出来是一个办法,但是不见得能立即解决。像不能解决的情况下,就挑重点做。并将测试范围与重点汇报给干系人。
2005-06-17 14:56:11 digman(6310930)
是不是可以这样,把各个项目的重点以及按照目前的资源能过做那些重点,那些不能做,报告上级,让他们裁决,毕竟我们是具体执行人,而不是决策人
2005-06-17 14:56:17 gladys(19785708)
大多数时候,我都这样做的,而且比较有效
2005-06-17 14:56:59 小鱼(66944928)
好办法
2005-06-17 14:59:19 songfun(6975740)
这里做web测试的有多少人?你们测试环境的搭建交给测试组、还是运维组,还是开发组来做?说说利弊。
2005-06-17 14:59:58 小鱼(66944928)
我们的系统测试环境是我自己搭建的,根据开发部门列出的配置清单
我们有个visual work
每个系统都有它自己独立的配置,独立的IP
2005-06-17 15:01:10 愫夕(41375549)
visual work是测试工具吗?
2005-06-17 15:01:27 小鱼(66944928)
虚拟的主机
2005-06-17 15:01:30 ray(8085413)
我们虽然不做web测试,但是我们用的环境是独立搭建的
2005-06-17 15:01:52 songfun(6975740)
举两个例子。测试环境代码的更新,交给开发组专人负责,还是测试组专人负责?利弊何在?
如果测试环境交由测试组自己搞定,那么像权限脚本的生成、代码编译等事情在提交到生成环境的时候将由另外的人去做,这样会不会存在问题?
你们认为应该 测试环境 和生产环境(实际运行环境) 的搭建是统一由一个人来做还是各自为政?
2005-06-17 15:02:31 ray(8085413)
首先测试环境和开发环境一定要分开
但是是否由一个人来搭建,没有这么绝对吧
2005-06-17 15:02:51 小鱼(66944928)
代码我们是这样做的,从单元测试服务器上通过vss获取代码,重新编译,拿到的安装包在我们自己的web服务器上安装,数据库也是分开的
2005-06-17 15:03:04 ray(8085413)
我们一般情况是开发人员协助测试人员搭建
2005-06-17 15:04:04 songfun(6975740)
问题在于,测试环境如果自己搭建,到时候 投入实际环境运行时,搭建环境的可能是:开发部、运维组、工程组、系统组等的其他人在做,这里存在一个问题,不知道大家有没有想到?
2005-06-17 15:04:21 gladys(19785708)
开发人员协助搭建,有的时候直接在用户现场澧
2005-06-17 15:04:56 小鱼(66944928)
我们比较简单就是程序员自己去给用户搭建,而且程序员比我们测试人员更懂,我们只是模拟用户实际安装配置时可能遇到的问题,事实证明,这样做很有必要
2005-06-17 15:05:21 阿芳(10294424)
小鱼,你那个叫安装测试
2005-06-17 15:05:47 小鱼(66944928)
哦,谢谢
2005-06-17 15:05:54 ray(8085413)
我觉得小鱼做的还是对的
2005-06-17 15:06:05 阿芳(10294424)
我没有说错。
2005-06-17 15:06:20 ray(8085413)
第一次,可能这个部门哪个部门去用户哪里安装
但是如果中间出现了问题,用户需要自己安装的时候,要么你们这边过去人,要么用户自己安装
用户安装的时候,大部分都是按照公司提供的说明来做,或者按照一般规律来做,所以还是有必要测试人员自己来搭建
2005-06-17 15:07:19 小鱼(66944928)
我们经常去做support的
2005-06-17 15:07:39 ray(8085413)
阿芳,我没说你说小鱼错了,我说我支持小鱼的做法
2005-06-17 15:08:47 小鱼(66944928)
呵呵,我们也是讲过了血的教训后最近才这么做的,不过测试人员的水平提不高,有个别项目程序员都不需要我们配合他,他嫌我们反而浪费了他的时间,结果他的项目issue特别多
2005-06-17 15:08:48 阿芳(10294424)
我感觉让测试员去做support,是对测试指责的亵渎。
2005-06-17 15:09:21 小鱼(66944928)
不是,是programmer去support
2005-06-17 15:09:36 阿芳(10294424)
小鱼,你自己也是用户,别这么说“用户”
2005-06-17 15:09:58 小鱼(66944928)
我真的有遇到这样的用户的
2005-06-17 15:10:54 阿芳(10294424)
他没错亚,花钱买服务,问几个问题还不行?
2005-06-17 15:11:34 小鱼(66944928)
行,反正support他们也要付钱,我们公司还乐意去呢,只是经常抱怨,我们的口碑就不太好了
2005-06-17 15:11:48 T.E.(28707264)
是啊,技术支持人员往往只是体现了一个传达信息的角色,解决问题还是得prger去
2005-06-17 15:13:04 小鱼(66944928)
我现在的瓶颈是,连我自己都觉得自己的业务水平不够,不能服众
2005-06-17 15:31:25 嘘~garfield~(93220283)
做黑盒测试的时候
不就是要站在用户的立场来想问题吗?
如果小鱼是这样想用户的.那么他的测试出来的结果..........
2005-06-17 15:32:31 songfun(6975740)
说说我的想法,我认为需要有这么一个“角色”,专门负责环境的搭建,无论是 开发环境、测试环境,还是用户环境。
不知道大家怎么看?
2005-06-17 15:33:16 嘘~garfield~(93220283)
有这样的需要吗?
就是说假如在人手不够的情况下
2005-06-17 15:33:31 songfun(6975740)
如果软件规模不大,技术难度不高,那么可以各自为政,但是一旦规模庞大或者环境搭建的技术难度很高,就可能出问题。
2005-06-17 15:34:03 嘘~garfield~(93220283)
那你觉得这个角色,可以把配置管理也负责在内吗?
2005-06-17 15:34:12 songfun(6975740)
分工应当明细化,各司其职,不应当什么人什么事都做。这就跟早期的 开发自己开发自己测试 一个样。
没有明细的分工,最后会发现,大家做的事都好像差不多,测试组 跟开发组 、工程组,有很多重叠的工作。
2005-06-17 15:36:12 songfun(6975740)
我觉得交给SCM可以作为一种考虑。
2005-06-17 15:36:13 嘘~garfield~(93220283)
有你的道理
不过有时侯一样工作由一个人专门来做
前提很大部分是看公司的发展程度
2005-06-17 15:37:01 songfun(6975740)
我提的是一个模糊的概念,给什么部门做暂时不提,就是是否划分出这么一个角色会对工作的效果、质量起到更好的帮助?
2005-06-17 15:38:17 森林狼(6877439)
开发环境应该和测试环境分开,否则互相干扰,问题难以定位。测试环境应该尽量和用户环境一致吧,但其实完全模拟用户环境也是比较困难的,尤其是大型的分布式系统。
2005-06-17 15:38:32 songfun(6975740)
to 嘘~garfield~:
呵呵,这个问题不大,其实可以兼职,但是要划分出来,有这么一个人在这么做,而不是A在做,B也在做,C也在做,最后到了user那里发现了问题,C搞不定,问B,你当初怎么搞的?B说:我不知道啊,问A吧………………
2005-06-17 15:39:07 gladys(19785708)
songfun, 我们公司以前做过这种尝试,但是失败啦。主要原因是项目太多而且行业也不一样,开发平台也不一样。这样对配置管理人员的要求就很高。。。但事实上配置管理人员的学习能力、技术水平,在公司中只能算一盘的。
2005-06-17 15:39:20 嘘~garfield~(93220283)
哈
我在想
也许在不同的项目安排一个人,比较灵活也达到你说的那种要求
2005-06-17 15:39:28 songfun(6975740)
开发环境肯定是和测试环境分开了的,问题在于不管开发环境还是测试环境还是用户环境, 这个环境搭建需要统一管理。
2005-06-17 15:40:37 songfun(6975740)
to gladys:
说到底还是一个技术自身限制的问题。在scmchina上常看到有人抱怨:scm不管是文档管理员,一点技术含量都没有。
而 tester也有类似的问题。
2005-06-17 15:41:22 gladys(19785708)
不是的,我们的配置管理人员。是从技术转过来的,技术不能算最好! 但肯定也不是最差的那种。
2005-06-17 15:41:51 嘘~garfield~(93220283)
我觉得不可以这样说
虽然我没有真正做过
但是这次的项目让我觉得其实要管理好文档也不是件容易的事
2005-06-17 15:45:56 digman(6310930)
各位,谁能帮忙给我说一下需求文档的作用和需求文档的变更管理的意义,
我现在需要整理些资料来给开发人员交流一下
2005-06-17 15:47:27 gladys(19785708)
谁对软件度量有研究?能不能讲下课?
2005-06-17 15:52:57 T.E.(28707264)
我们公司有这样的情况,需求没有统一管理,出现了N多版本,有时只有一个最初版本的需求,后面变更的话就是一大串咨询单来陈述变更的内容,你要想阅读完整的需求,得一个需求加一大串咨询但才行,很麻烦.而且,经常是更新不及时.
2005-06-17 15:53:29 digman(6310930)
看来都是如此啊,
2005-06-17 15:53:49 gladys(19785708)
配置管理加强点应该会有所改善吧。
2005-06-17 15:54:45 嘘~garfield~(93220283)
我想如果是你们这种情况
相信不止需求
其他文档也会出现类似的情况
2005-06-17 15:56:28 T.E.(28707264)
配置管理有,整了好几次,工具也用过几个,但是领导似乎不够重视,力度不够
2005-06-17 15:57:10 T.E.(28707264)
没有专门的配置管理员做这项事情
2005-06-17 15:58:25 T.E.(28707264)
我个人对工具的看法是,策略更重要,领导的意思是,先找个工具用起来再说,结果到后面就是不了了之了,唉
2005-06-17 15:58:47 嘘~garfield~(93220283)
领导都发了话了
就看你执行的人做得怎样吧?
2005-06-17 15:59:00 digman(6310930)
推行难度很大啊
2005-06-17 16:00:18 songfun(6975740)
gladys 对圈复杂度有没了解?
2005-06-17 16:00:26 T.E.(28707264)
没有专门的配置管理员做这项事情,买不起工具,策略就只能靠自己摸索,往往工作就非常忙,也没有把这件事当作一项工作来做,结果还是怎么速度快怎么来.
2005-06-17 16:00:53 gladys(19785708)
如果不能有配置管理专员的话,建议选择一位兼职来执行。工具可以用CVS免费的。。。
2005-06-17 16:02:31 gladys(19785708)
songfun,不了解,什么叫圈复杂度呀?扫个盲吧
2005-06-17 16:04:04 songfun(6975740)
呵呵,概念性的东西我不解释了。最简单的讲一下吧,越复杂的东西越容易出错,不知道你是否认同?
圈复杂度就是这么一个意思,复杂度越低越好。
2005-06-17 16:04:33 gladys(19785708)
绝对同意
我处理问题一般是先把问题简单化,再解决掉。
2005-06-17 16:06:33 T.E.(28707264)
赞同
2005-06-17 16:06:49 songfun(6975740)
人类最擅长的就是 分治法:分而治之,把复杂的问题分解成简单的问题。
2005-06-17 16:07:54 gladys(19785708)
我坦白,有时候这样处理问题是想绕过不懂的地方。。。举例说明就是某些技术问题的时候。
2005-06-17 16:08:25 T.E.(28707264)
用80/20原理
2005-06-17 16:09:00 T.E.(28707264)
80%的问题出在20%的人身上,解决重点问题 |
|