项目软件测试经验交流

发表于:2009-05-05来源:作者:点击数: 标签:软件测试项目经验交流
下面是我3年前在公司做的一个项目测试经验的交流,主要介绍自己以前是如何在项目中做测试的。过了3年,有些东西可能不一定适用,贴出来仅供参考了。 在介绍我们之前项目测试工作之前,需要首先介绍一下之前我所在团队的组织架构及 测试人员 在项目中的工作。
下面是我3年前在公司做的一个项目测试经验的交流,主要介绍自己以前是如何在项目中做测试的。过了3年,有些东西可能不一定适用,贴出来仅供参考了。

        在介绍我们之前项目测试工作之前,需要首先介绍一下之前我所在团队的组织架构及测试人员在项目中的工作。

        我们的测试团队属于质量改进中心下的测试部,它和研发团队属于两个不同的中心。测试团队6个人,从这个组织架构图中可以看出来,一个人可以参与多个处于不同阶段的项目测试工作。

        参与项目的测试人员以测试组的形式进入项目,测试组和需求组、开发组并列。每个测试组有一个测试组长负责项目测试工作。项目经理不直接面对测试组成员,而是通过测试组长进行任务安排、协调、沟通。测试部经理知情测试人员的项目测试工作,项目测试组的工作汇报均需要抄送给测试部经理。

        上面说到的是旧的测试人员工作模式,在去年年底,为了有效利用公司测试人员资源,我们开始了测试外包的尝试。这里的测试外包模式是指,测试组不进入项目,而是由项目组将测试工作以一个项目的方式分包给测试部,由测试部根据项目组提供的信息,进行计划、执行测试,并按照项目要求提交测试成果给项目组。这个模式还在探索中。如图所示,测试部经理直接负责项目的测试工作,测试组的工作情况抄送给项目经理。这种模式需要进行独立核算,包括成本估算、预算、结算等。但是这种模式整体的思路还不是很成熟,从这个组织架构上大家也可以看出来,很多东西还没有理顺,所以一直都处于尝试过程中。后面我们交流的内容,如果没有特殊说明,都是在旧的模式下进行的。

        我想不可否认,大家都认为测试人员应该是测试技术上的专家,但是,测试人员是否需要熟悉并擅长一定的业务呢?不管答案是什么都没有关系,但是我认为一个好的测试人员不仅是测试专家,他同时也是业务专家。有着样的说法:“软件测试人员要两条腿走路,左腿是测试技术,右腿是业务知识。只有两条腿的健壮差不多,走路才稳当。”出于这种思想的考虑,在原来的测试团队,我们每个人都有两个学习、研究方向,一个是技术方向,一个是业务方向。但这在工作开展上有些困难。如果公司认为测试人员应该绝大部分时间用在项目测试工作上,那么测试团队既要研究测试技术,又要学习业务知识,是比较难的。在我们以前的测试团队的工作中,有一部分工作时间是用来进行部门建设的,公司允许部门建设工作占整个团队工作量的30%。部门建设工作中包括前面说到的技术研究、业务学习,还有就是部门搭建所需要进行的一些工作。将部门建设工作分开,主要是用于统计部门成本和测试成本用的。

        前面说到了测试人员是以测试组身份进入项目开展测试工作的,但不是每个成员上去都从事同样的工作。在进入项目组工作时,每个测试人员所充当的角色是不同的,项目的测试角色划分为以下四种。在实际工作中因为测试人员数量有限,所以经常是一个人担任多个角色。

        了解了原来测试团队的分工之后,下面介绍一下测试团队的工作内容。测试团队承接的工作中,测试技术研究,属于提高团队工作技能的工作,在整个部门范围内进行,这里属于部门建设工作;对于项目中的测试人员有可能需要进行,如果项目采用新的测试技术或者测试工具,那么就需要项目测试组成员研究测试技术了,这部分属于项目测试工作。培训指把内部研究的成果在团队内使用,在适当的时机在公司内传播。我们测试团队在2004年进行了21次内部培训,7次公司级培训。因为每个人各有研究重点,所以我们每个人都是团队内部培训的讲师。

        说到软件测试工程师的工作内容,那么就涉及到测试工程师该做的和不该做的。当然这和公司对测试人员定位有关,这里仅指以前的组织。要说该做的,那么我们需要先明确为什么我们要测试?这是因为存在“系统错误很多、系统不是客户想要的东西、系统实现没有遵照系统需求”等这样的背景。在这样的背景下,产生了测试,但是又因为开发人员自己测试自己的东西,难免测试不全面,所以产生了测试工程师这个角色。因此,测试人员他该做的,就是测试软件产品和用户需求不一致的地方,并尽可能多的发现缺陷,能够向PM汇报软件质量状态。但是在实际工作中,测试人员经常主动或被动的去做了一些不该做的事情。例如说,测试人员认为自己或者测试能够保证软件的质量,以及有意识或无意识的接受了决定软件是否发布的这个权利。

        为什么测试无法保证软件的质量,是因为项目的质量,需要项目组的所有成员共同努力,才能达到质量保证的目的。单纯靠测试工程师的力量,是无法实现软件质量保证的目的。

        为什么测试人员不适合承担决定软件是否发布的权利,是因为软件的发布,是需要项目组各个小组负责人等相关人一起对系统现在的缺陷、质量状况进行评估后,由PM(或者与会者)作出是否发布的决定。在这个过程中,测试工程师可以提供测试数据、系统当前质量状态报告给与会者参考。

        当然,我知道这两点会有很多人不认同,但是没有关系的。我接触的同行中对两点经常有争论。但是,有一些质量大师等权威人士还是全部或部分赞同这两个观点的,如:菲利普.克劳士比曾在他的书中提到软件质量的保证需要全员努力,需要过程的控制的,而不是某个英雄可以保证软件质量的等。(《质量免费》、《质量无惑》)


原文转自:http://www.ltesting.net