谈项目管理和软件测试过程(2)

发表于:2015-11-13来源:uml.org.cn作者:不详点击数: 标签:项目管理
从实践经验看,一年前首先成立测试部,把属于开发部门的测试工程师归口到独立的测试部门管理,其次建立规范的测试流程,与开发部门交流,要求每周

  从实践经验看,一年前首先成立测试部,把属于开发部门的测试工程师归口到独立的测试部门管理,其次建立规范的测试流程,与开发部门交流,要求每周提出测试需求,再根据现有的资源制订每周测试计划,同时向人力资源部门提出招聘计划,随着测试工作的成绩不断被开发部门和上级领导认可,再推广实施软件开发过程规范化的管理,通过测试实践的优良成绩来确立测试部门在公司的地位和作用,经过一年的奋斗测试部门从无到有,从最初两人到现在十人,软件配置管理和缺陷跟踪系统已经被60%的开发人员自愿使用和接收。 总结本人在华友一年多测试工作经验,深深体会到在国内从事软件项目开发难、从事软件测试和质量保证工作更难,需要具备扎实的技术功底同时,不断提高测试项目管理能力,寻找工作的突破口。世上无难事,只怕有心人,但是只要你努力献身于软件测试工作,打出一片天地是有可能的。

  2.配置管理系统是项目经理的"眼睛",是软件测试有效实施的前提

  在软件质量体系的诸多支持活动中,配置管理系统处在支持活动的中心位置,它有机地把其它支持活动结合起来,形成一个整体, 相互促 进,相互影响,有力地保证了质量体系的实施。建立公司配置管理系统很容易得到公司领导层的支持,几乎没人反对。更重要的是建立配置管理系统后测试人员的工作有了系统保证,测试工作的"矿藏资源"有了明确的位置,可以主动积极开展测试工作。

  2.1 项目管理存在的主要问题

  华友公司测试部门去年刚成立时,以建立、规范和推广使用配置管理系统CVS为突破口,同时建立缺陷跟踪系统Bugzilla提高测试流程的管理水平。我做为测试负责人首先分析华友公司几个软件项目在开发管理上的现状,。

  存在问题一、公司几个核心项目仍然过分分依赖少数个人的作用,没有建立起协同作战的氛围,没有科学的软件配置管理流程; 技术上只重视系统和数据库、开发工具的选择,而忽视配置管理工具的选择,导致即使有些项目有配置管理的规程,也由于可操作性差而搁浅。以上种种原因导致开发过程中普遍存在如下一些问题: 调查说明华友研发成员的变动的比率达到30%,几乎每周都有新加入的员工或者辞职人员, 一个新成员熟悉项目的最佳途径就是通过配置管理系统阅读项目文档,甚至阅读同行代码,达到快速学习、共同提高的目的。一个辞职人员可以利用配置管理系统保留部分一段时间工作,最大程度减少对项目开发造成的损失。

  存在问题二、开发管理松散。领导了解工作完成情况重视口头交流,忽视书面文档。有些部门主管无法确切得知项目的进展情况, 项目经理也不知道各开发人员的具体工作,项目进展随意性很大,可"左"可"右"。"左"时按领导下达的"期限"进行,到期时,似乎一切已顺利完成,大家一阵胡弄,交差完成,反正领导看的是界面,至于里面是什么,留到施工时再说。施工时的工作因此变成了无法汇报、无法理清的无休止的维护。"右"时则项目工期无休止地延期。对我们软件工程来说,总的特点是先"左"后"右"。在领导面前表现"左",在用户面前表现"右"。有个测试人员经常利用上班时间学习英语,过了一个多月,看她依然如此,我做为项目领导进行批评教育,这名员工并不认为自己错了,她争辩,公司采取弹性工作时间,考核员工是分配的任务是否完成等理由。同时、我对她批评结果遭到她的恶意报复,她给有关领导报告新来的经理如何不懂公司业务,采取不适合公司的管理方式等,由于领导无法了解真相,使得我的工作在一段时间开展很困难,直到过去半年,这名员工辞职出国学习领导才明白发生了什么。

  存在问题三、项目之间沟通不够。各个开发人员各自为政,每个项目经理都像个"地主",编写的代码不仅风格各异,而且编码和设计脱节。每个项目组的人力资源和硬件资源成了"私有财产",自己人员即使暂时空闲,让他从事所谓的新技术研究,也不考虑友邻项目需要他们帮助的现状。本来开发中错误在所难免, 进展早一点的项目组或者人力资源强的项目组已经积累类似问题的解决经验,也不愿意分享给其它项目组。 开发大量重复, 留下大量难维护的代码。典型案例是有个短信项目D两年来在这个开发人员Y 的研发支持下运转效益很好,但是三个月之前,开发人员 Y因为待遇问题和公司领导谈判失败,提出辞职。项目D仍然在运行,但是最近移动公司规范修改、系统升级,需要修改程序,没人能看到及时更新的文档,尽管有一堆代码库,但是后来的程序员都没办法分析明白程序结构。公司领导出面请开发人员Y来协助,因为没有文档记录,Y忙于新公司的工作也不能解决修改。

原文转自:http://www.uml.org.cn/Test/200609065.htm