关于测试部门管理

firedot

目前下面有个测试部门 暂时由我负责,公司目前开发了一款新的软件,这个软件比较特别与硬件环境还有些关系.不同的电脑上跑出来的效果.差异比较大.而目前公司的测试环境有限测试效果不理想. 想要扩大测试的范围.不知道各位有什么好的办法.
还有这个部门刚成立,不知道该从那些地方着手,有点迷糊:)

千里

可以分发一些测试版本给测试用户，并付一定报酬。51testing最近有这种活动，测试完了根据BUG的量给予一定的奖励，这种方式既容易实现而且费用又不高。

warning

没有开发文档是个大问题，这只能靠与开发工程师多沟通了
测试资源很成问题阿，要与领导多沟通，让他们知道测试是需要资源的，资源不足不能很好的保证测试质量。

要招人可以去问问我们的bobli老大，让他推荐
呵呵

firedot

很高兴 !第一次来就这么多人帮着出主意. 很感谢大家
怎么说呢!这个软件没有完整的开发文档.在以前也没有很正式的测试过,更多的时候是大家在使用的过程中发现问题,就改了.
测试的很不系统.而前一个版本相对还算稳定.至少目前看来. 而新的版本程序的架构有了很大的变化.现在是问题多多,而上面却要
测试部门拿出一套有效的测试手段,不怕各位笑话,这个测试人员还是我临时调过来的,也不是专业的测试人员.而产品要很快的推广出去.
所以,现在测试部分的任务很重. 现在想想脑袋都大!

warning 兄 我也正有招两个专业的测试人员. 不知道有合适的能推荐两个吗 呵呵  
对了 我公司在沈阳.

bottle

1.LZ需要确定需要在那些硬件环境下测试该软件，如果机器不够，可以考虑用VMware Workstation在同一台机器上安装不同的操作系统，这比直接在一台机器上安装多个系统要方便得多。
2.同时需要做出测试计划，尤其是对有限人员和环境的配置。缺陷管理方面可能会比较繁杂。在不同系统上可能会存在同样的bug，最好测试人员能及时查阅相关的bug，可以在同样的bug中批注不同的系统，或者，也可以另外报，leader可以进行同类bug的合并。在流程和规范还都不成熟的情况下，建议lz还是先注重测试用例、测试环境、测试人员的安排、跟踪、执行、完成情况，这样至少能保证在哪些主流的环境下主要的case都是跑过的，慢慢再去加强其他方面的管理和补充。
3.赞同warning的意见，不适合让真实用户卷入到你的日常测试工作中，这是不可控的事情，你会更加头疼。

warning

如果lz要招人可以考虑下51testing的学员
哈哈

warning

原帖由 firedot 于 2006-5-31 14:58 发表
多谢楼上两位. 专门的测试机器肯定是有的 ,不过我想将测试范围扩大到100个测试个体. 如果通过增加人力 和设备成本过高,也不现实.
我想找一些用户通过网上下载测试版本.来扩大我们的测试范围. 不知道如何??:)

做好的方法还是增加测试资源，招聘合适的人选。
建立测试需求、测试计划、缺陷管理等。个人认为需求管理、配置管理和缺陷管理是非常重要的。

让用户来测试属于beta测试的范围，在没有经过测试组充分测试而直接进行beta测试是一个很不好的方法。
可能导致的结果有：
用户下载了，没有测试
用户测试了，没有反馈
反馈信息不明确
反馈信息质量不高，有很多不是缺陷，花费大量人力在筛选bug上
用户测试了，发现软件质量不高，对产品不信任转而使用竞争对手的产品
不仅自己不购买甚至告诉其他潜在客户产品不可信任

[ 本帖最后由 warning 于 2006-5-31 17:51 编辑 ]

firedot

多谢楼上两位. 专门的测试机器肯定是有的 ,不过我想将测试范围扩大到100个测试个体. 如果通过增加人力 和设备成本过高,也不现实.
我想找一些用户通过网上下载测试版本.来扩大我们的测试范围. 不知道如何??:)

millionaire

1\准备专门的测试机器,也就是搭建测试环境,让原始的测试数据能随时恢复,这样能保证每轮测试的背景是一样的;
2\刚开始组建的测试部门,需要制定相应的测试需求,测试计划等等的规范,以后大家可以遵从的

tjj006

刚成立的项目组肯定要培训的，熟悉系统的需求与功能。要扩大测试范围就要人力了，尽早开始培训测试人员，使他们尽快熟悉系统，对后期的测试是非常有帮助的。