【转】从软件测试角度上看项目流程管理

上一篇 / 下一篇  2012-03-07 11:27:33 / 个人分类:测试理论

发布时间: 2012-2-22 10:48   作者: toymaker   来源: 51Testing软件测试网采编

 

字体:    |上一篇下一篇|打印 |我要投稿 |推荐标签:软件测试管理项目

管理缘起:

  说实话,我知道题目说大了,但是我不准备改。因为我想总结一下近些年,近些公司中看到的一些片面的内容,从而从中提炼出来我想要表述的东西:项目流程管理。

 

  其实从一个公司到另外一个公司的过程,个人要完成的转型,概况来说无非是3点:

 

  ●企业文化的适应

 

  ●工作流程的适应

 

  ●项目内容的适应

 

  而从我们测试人员的角度来看,这三种适应,其实就是QA要做好的三个方面,怎么能将自己再以往公司积累的经验转移过来,并融合到目前这个公司的工作环境中去,是每个高级工程师在这个阶段都想做,但是实际上却不知如何下手。

 

  我写此文,无法表述出来一个正统思路,仅以自己的思想做一个方式性质的总结,聊以自慰而已!

 

  QA vs QC

  我想,应该首先说一下对于QAQC的自我看法。QC本身来说是质量控制,要保证的是产品质量,项目的产出。QA从字面理解是质量保证,要保证的是项目质量,产品过程优化。因此,QA从最贴近的角度上来说,就要比QC多一个“过程质量改进”的作用。这个作用在越是小的公司,就越是迫切。

 

  小公司的矛盾

  小公司人少,以一抵百,最经常使用的开发模式就是“大棒模式”,即,想做什么就上了,文档规范有时间再上;培训,招人,要以直接能干活为首要目的;产品的维护和客户维护上以开发新客户为主,老客户只在前期做一些维护,如果客户懂的多了,尽量就让客户自己做事情,我们能不做就不做。

  这样的模式下,导致的产品质量一直无法上去,客户抱怨多,新产品开发进度一拖再拖,跟客户的许诺也是愈来愈没有谱,接下来怎么办

 

  过程质量改进

  从测试上来说,我们要做的事情,就是在做好测试工作的同时,培训开发和产品们去要求他们

按照我们测试的流程做事情,发布产品。强势的测试介入,有益于整个产品过程的正规化。我们可以从以下几点入手

 

写测试计划,写测试用例文档,拉开发、产品review。慢慢要求他们的文档也必须全面规范

 

  ●建立合适的bug系统,使用它报bug并督促开发严格按照bug生命周期去管理流程,规范版本迭代过程

 

  ●建立总结制度,从内部做起,邀请开发、产品加入,总结项目一个阶段遇到的问题,使得产品、开发也意识到自己某个阶段的工作不足引入的一些测试上的麻烦

 

  ●建立内部培训,一开始以测试主题为主,逐渐邀请开发人员做一些简单的产品框架培训,最后完成整个团队的培训提高的风气改变。

 

  从上面列举的四个方面做循序渐进的改变,这样各个产品流程改进都能较好的完成,也不至于由于变化激烈而产生的团队内部抵触心理。

 

  项目流程改进:

  测试,应该从自己的角度来规范开发流程。同理,我们测试也应该从自己的角度来帮助项目完成项目流程的规范管理。

 

  流程的制定:

  不过这个流程改进,不是从内部做起影响外部,而是应该从高层到底层推进的过程。所以,这个事情应该是在测试融入到团队里面,成为不可或缺的一部分之后完成的事情。之所以项目流程改进不能从下至上,是因为产品流程在中小公司中,往往是没有规范可循的,没有制度可依的,我们是在建立一个团队协作的制度,制度的实施,不从上至下,无法保证最终的结果。

 

  如何从上至下的推行呢?

  首先要用自己的测试遇到的问题影响你的老板,让他或者他们知道问题来了~,然后在合适的时机提出自己的解决问题的方案,供老板参考,并愿意和老板一起完成对项目流程改进以及团队协作制度的制定工作。最后,可能大部分的意见还是你提出来,靠老板拍板决定的,所以你有机会提出自己的解决方案,增加测试团队的声音。

 

  上面只是写了大略,其中宗旨是,不应以测试为中心,应以项目流程优化为重,辅以对重要产品以及团队中重要人物的共同参与讨论为基准。完成整个项目流程的推进。

 

  流程的推行

  说实话制定流程容易,推行难~ 所以,在推行过程中,又要求测试必须督促各个方面的人员,帮助他们将制度变成习惯~。这个时间可能会很长,要求我们要耐得住这个过程。

 


TAG:

 

评分:0

我来说两句

Open Toolbar