51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3638|回复: 5
打印 上一主题 下一主题

[原创] 产品开发初期测试人员参与的重要性

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-10-19 12:56:51 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
前段时间,看到一篇刘俐的文章,写的是产品开发初期测试人员应该做什么?

读后,感想颇多,写了点读后感,和大家一起讨论一下。

                            产品开发初期测试参与的重要性
                           -读《产品开发初期测试人员应该做什么》有感
   
    读了《产品开发初期测试人员应该做什么?》后,感触颇多。确实,在我们实际的产品、项目测试过程中,测试人员很少或几乎从来没有参与过产品开发初期的过程。只是充当为用户需求买单的角色。不是测试人员没有能力或者不想参与,而是项目、开发人员根本就不重视测试人员的参与,认为用户的需求只要开发人员充分理解,完全按照用户需求进行开发,测试人员只需要对开发出的产品进行测试,没有问题就算产品、项目成功了。
    其实不是这样的。测试人员参与产品开发初期不仅是需要的,而且是非常重要的。在产品开发初期,用户需求的理解、功能的优先级等的确定,对于后续产品开发的成功与否至关重要。而测试人员拥有的产品知识,以及对于产品测试、维护的理解和经验,能够判断被细分的客户需求是否完整、准确,以及哪些是合理的,哪些是不合理的,反馈给项目经理,以供参考。
同时,测试人员通过参与产品开发初期的过程,能够充分理解用户的需求,并根据产品的整体计划,给出产品的测试计划。这时给出的产品计划足够准确、完整,完全能够有效的指导后续整个产品的测试,并根据需求的变化做出相应调整。使得被动的测试变为主动的测试,使得整个测试过程不但提前,而且后续测试变得更加有效、有针对性。
    另外一个目的就是,测试人员通过参与产品开发初期,能够充分的理解用户需求,为后续的测试做好铺垫。通过产品开发初期的参与,测试人员已经完全对产品、项目的需求实现情况、功能实现情况、需求以及功能的优先级了如指掌。这样,测试人员能够提前做好测试准备,做好测试用例的设计,这时做出的测试用例能够尽量细化操作步骤,为测试实施提供便利,同时测试用例能够划分是否重点用例,以及用例的优先级,使测试实施变得更有针对性。同时,可以根据情况提前搭建测试环境,为测试实施的开展做好充分准备。
还有一个目的,就是能够提前做好测试工具的开发的决定。由于测试工具的开发周期较长,见效较晚,因此测试工具的开发能够越早越好,避免测试时本来有自动化测试也因为工具没有完成而无法实现。
    总之,产品开发初期,测试人员参与是非常必要且非常重要的。在开发初期测试工程师需要:充分了解用户需求,确定产品的可测性,制定产品的整体测试计划,提前确定需要引入何种测试工具或平台。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2007-10-19 12:58:53 | 只看该作者

附刘俐的原文。

产品开发初期测试人员应该做什么?
          发布时间: 2007-9-13 14:20    作者: 刘 俐    来源: 刘 俐 的 专 栏  www.51Testing.com

    产品开发初期需要测试人员吗?如果需要,他们要作哪些工作?这些问题曾经被很多朋友问起。据我个人了解,很多国内中小型公司是不注重产品开发初期乃至整个开发过程中的测试工作的。例证一:有些公司认为在设计初期投入测试人员是代价高昂且无意义的,所以他们会要求产品开发的第一个周期结束后,开始设计测试用例。例证二:认为测试工程师不需要参与到制定需求中,他们只要接受就可以了。于是乎,就出现了市场部门和开发部门直接沟通项目需求,测试经理直接参考需求设计文档的状况。例证三:测试经理确实在产品开发初期参与项目需求的制定,并写出测试计划。但产品质量却是现场部署的工程师说了算。到了现场,发现这里不合用户的意,那里运行不过。为了赶时间,只好坐在用户现场直接调试。改代码的改代码,调试的调试,哪里还管着产品是否需要全面的测试,只要能运行起来,用户能用,就是胜利……

    权且不说这些管理行为是否更加浪费工钱,我们应该很容易得到关于“产品开发初期测试人员该做些什么”的一致答复:测试计划在开发初期能写挺好,不写也没什么问题。测试一定要做的。但把怎样的产品交给用户是不确定的。目标就有一个,让用户用上再说——无论是对一个已经经营多年的产品,还是一个刚起步的公司……

    其实,对测试的理解不是点头说,测试很重要就够了; 对测试的理解不是去声称,我们有一柜子完整的测试文档;对测试的理解也不是只关心“做与不做”,而全然不理测试的有效性。

    软件测试该如何理解如何执行,是一个很大的题目。在这里,我更关心的是在项目设计初期,我们该不该忽略测试人员,而测试人员又该做些什么样的工作。

    微软最新的软件开发周期(product life cycle)分为产品定义(Product Definition),产品开发(Product Development),产品服务(Product Servicing)三个阶段。为了使资源得到最有效的使用,测试人员主要参与产品开发和后期服务这两个阶段。而在产品的定义阶段,则会有选择的要求一些资深测试工程师和测试经理一起参与。他们主要负责:通过验证产品核心功能或用户使用场景,确定产品各功能的优先级;参加产品使用场景定义的评审;参加用户体验文档的评审等。

    当然每个公司应该定义适合自己的开发模式。但是是否让测试工程师参与这些工作的主要目标应该是没有区别的:首先是熟悉客户需求;再来测试工程师应凭借自身经验,从测试和维护的角度来判断被细分的客户需求中,哪些是合理的,哪些是不合理的,并反馈给项目经理或市场部门,以供他们参考;最后,则要根据这些项目需求以及软件架构的文档,给出测试计划。

    上面这番描述是不是看上去并不很复杂,也不重要呢?非要在项目初期做吗?最终不都是根据需求文档来写测试计划嘛……

    这当然是很重要的环节。理由如下:

    1. 产品的可测性严重影响了后期测试团队的工作效率以及测试的有效性。越早提出此类相关问题,越可能进入开发工程师设计范围。同时,该项指标可为项目经理提供一个与“开发难度”并列的“测试难度”——这将会影响到项目负责人对开发周期的设计。

    2. 除项目经理外,测试工程师是最需要了解用户需求以及用户使用体验的角色。参与这些由产品经理,项目经理编写的文档评审,会让测试工程师们得到除了列在文档上的核心需求外更多的信息——我们必须承认,因为人的因素,文档是不可能涵盖所有信息——这将会帮助工程师们以更快的速度对产品需求有更深层次的理解。

    3. 使得测试经理能够更早做出“是否需要提前编写测试工具或搭建测试平台”的决定。而这是很重要的一点。测试在开发流程中,因其所处位置,很容易因为开发团队中的突发事件导致周期被压缩。而自动化测试工具虽然可以节省人力,但相比于手工测试,开发周期较长,见效较晚。通常一个工具从开发到可以用于测试需要一周到数月不等——完全取决于工具的规模。因此,尽快确定“是否需要编写测试工具”是必要的。它可以帮助测试团队“抢回”更多的时间用于设计和调试测试工具,从而达到更好的测试效果。甚至可以避免掉因为时间不够,而拒绝采用自动化工具转为手工测试的被动局面。

    理由其实还可以列出很多。但是,我觉得这几点应是最为主要的。它们能足够说明为什么测试人员需要参与产品开发初期的工作以及他们需要做些什么的问题。这里再重复一下,在开发初期测试工程师需要:确定产品的可测性,了解用户需求,确定需要引入何种测试工具或平台。

    所以,在开发初期做好测试计划并不是可有可无的;用户需求不是只要工程师“买单”就可以的;不理会测试团队而埋头开发的产品,将会是一场“噩梦”,特别是当产品发布/部署的时候。

    但每个公司每个项目组不需要套用一样的模式。针对不同的需求,我们应该量体裁衣,做不同的剪裁。只是核心不该有变化,目标不该有变化。就如同国内一些公司对CMM的追宠——光有形,没有神,是实在不可取的。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2007-10-19 14:00:03 | 只看该作者
自己顶一下!
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2007-10-19 14:09:48 | 只看该作者
如果按规程,前期光写文档就得要几个月,但又有几个公司能有这个能力实现它呢?
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2007-10-19 15:36:09 | 只看该作者
我也认为测试人员参与是非常重要的,但就是不让我们参加,真没办法,上面的解释是任务太多,没有时间。哎。。。。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2007-10-19 16:06:45 | 只看该作者
在开发前期,测试的一般工作都是学习和熟悉需求、该领域的业务知识等,然后编写测试计划书等测试文档,为下一步的实施测试作准备!
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-8 07:29 , Processed in 0.073861 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表