如何应对转测试以后的需求变更?

在Waterfall或V模型下的测试分层往往看起来很完美,但它是基于这样一个重要的假设:项目的需求变化不多或者说需求很稳定。产品由开发转测试后,当需求更改较多或者新需求不断涌现的时候,很多问题也随之而来,尤其对于大型的项目而言,问题较为突出,主要表现为:

1)         需求的变化,测试人员不知晓;

2)         测试人员知晓需求变化的时间滞后,例如在回归问题单时才知道;

3)         由于版本间歇期短,测试没有人力和时间投入对新增修改需求的测试分析和设计上,基本上很难像对待老需求一样,开展详细的测试分析设计;

4)         对变化需求与老特性的交互上分析不够或者根本没有展开继承性分析;

5)         新增修改需求打乱了原有的测试规划,甚至包括对测试特性的划分原则,相应的测试结果分析、测试需求跟踪等都不到位;

6)         测试策略的更新不及时;

7)         产品转测试后,开发一般时间也很紧张,单元测试等做不到位,结果会遗留很多本应该在UT/IT阶段发现的问题到系统测试阶段。

在您的项目中,需求变更对测试还有哪些影响?测试又是如何应对转测试以后的需求变更呢?欢迎补充。

如何应对转测试以后的需求变更?》有 9 条评论

  1. jievz说:

    需求变更的话,我认为测试角度应该知道变更的地方,对特性的影响,对继承的影响要做出分析,可以和开发进行讨论。
    然后测试策略的话可能要针对重点变更部分进行重新整理。
    吸取经验,下次变更的时候需要让测试也提前知道,好得到及时反馈和制定及时的测试策略。

    回复

  2. jievz说:

    后续的话就尽量避免重复测试。
    怎么去设计变更后的验证用例,而不用重复执行以前测试过的用例是个比较重要的地方。

    回复

  3. 刘强说:

    许多的时候只有测试人员拿到软件的时候发现软件功能变化了,不知道是软件缺陷还是功能的变更,弄的测试人员很不开心,只能在边测试边沟通,这样导致许多的时候测试人员无法全面的考虑到测试的场景,我们当时根据现状自己开发了一款工具,当有新需求的进来的时候会自动发邮件通知相关部门的相关人员,同时需求会标记为New的状态,当需求经过评审以后就自动标记为评审的状态,是评审通过还是没有通过,没有通过的原因是什么都会由相关人员记录进去,同时会发送所有的相关人员,同时每天都会在下班的时候对今天新增需求,没有处理的需求自动的进行分类,发送邮件给相关的人员,这样每个部门都会收到需求变化的通知;所有就不会存在1,2,6两点的问题都就相应的解决了;
    当时新需求源源不断的进入的时候很有可能打断我们测试人员的计划,这个我当时处理的办法就是要设立产品基线,什么时候的需求可以融入此时版本,同时加入该需求会有多少客户去买账,如果只是一个两个客户,那么我可以将下期版本更新或者不做应对处理,同时要拿出这样做会对现有的计划的影响和带来的后果,这样确保我现在的计划不会被打乱,因为有些市场反馈回来的信息很不准确,所有自己首先要对这个有把握,才可以不被这些外界因素打乱。
    关于7点,我的观点就是有多少个公司会做单元测试,包括微软这样的公司,他会对他所有的产品去做单元测试吗?肯定不会去做的,所有我们不一定要把所有的希望寄托到单元测试,而我们要利用现有的资源认真的去对待系统测试,同时还是多去规范开发和测试的规范,这样比依靠单元测试更有效;
    这个是我自己对以上的几点做出的意见和看法,希望可以能得到你对我的意见的评价,这样我就可以更好的去在实际过程中处理这些事情,谢谢!

    回复

    • 邰晓梅说:

      许多的时候只有测试人员拿到软件的时候发现软件功能变化了,不知道是软件缺陷还是功能的变更,弄的测试人员很不开心,只能在边测试边沟通,这样导致许多的时候测试人员无法全面的考虑到测试的场景,我们当时根据现状自己开发了一款工具,当有新需求的进来的时候会自动发邮件通知相关部门的相关人员,同时需求会标记为New的状态,当需求经过评审以后就自动标记为评审的状态,是评审通过还是没有通过,没有通过的原因是什么都会由相关人员记录进去,同时会发送所有的相关人员,同时每天都会在下班的时候对今天新增需求,没有处理的需求自动的进行分类,发送邮件给相关的人员,这样每个部门都会收到需求变化的通知;所有就不会存在1,2,6两点的问题都就相应的解决了;

        【txm】这种做法很好,可以实时地向相关人推送需求的变化,有点像敏捷项目里的可视化手段,比如持续集成(CI)的状态要实时地推送到每个人,推送的方式除了邮件外,更有效的方式比如用公共机器上的屏保、CCTray、声音等都是不错的选择。这种方式可能有几点需特别注意:通知源信息的完整性和及时性(像Scrum里的PO可以被认为是需求的统一接口,来自各方的需求都会汇集到PO这里,然后PO会维护所有原始需求的状态,初始、已分析、已计划、完成等等)、所通知的需求变更的粒度是否合适(有些是设计的变更,可能还反映不到需求的层面,但是对测试来说是很重要的风险信息)、如果有可能测试最好是参与到需求的评审和讨论中,而不是事后被通知一个结果而已。

        当时新需求源源不断的进入的时候很有可能打断我们测试人员的计划,这个我当时处理的办法就是要设立产品基线,什么时候的需求可以融入此时版本,同时加入该需求会有多少客户去买账,如果只是一个两个客户,那么我可以将下期版本更新或者不做应对处理,同时要拿出这样做会对现有的计划的影响和带来的后果,这样确保我现在的计划不会被打乱,因为有些市场反馈回来的信息很不准确,所有自己首先要对这个有把握,才可以不被这些外界因素打乱。

        【txm】在需求不断变更的时候,测试的管理一定也是迭代进行的。每一个change到来后,要进行风险分析(优先级、估计),并相应地更新测试计划,而不是确保现在的计划不会被打乱。市场反馈的信息不准确这种因素,体现在你的风险分析工作做得怎样,你可能需求全方位的从各种角色那里了解该风险的属性,甚至召开风险评估会,大家一起进行风险分析(PRA 或 FRA)。你所说的产品基线的概念有点类似PO对需求处理时的DONE的概念,也就是此时XX需求经过一系列的分析处理已经可以进入testing的状态了。可见,你正在实施的是Risk Based Testing Planning的内容。

        关于7点,我的观点就是有多少个公司会做单元测试,包括微软这样的公司,他会对他所有的产品去做单元测试吗?肯定不会去做的,所有我们不一定要把所有的希望寄托到单元测试,而我们要利用现有的资源认真的去对待系统测试,同时还是多去规范开发和测试的规范,这样比依靠单元测试更有效;

        【txm】这里不是强调单元测试,而是强调开发早期所做的各种测试活动。不管开发人员做的是单元测试,还是模块级的集成、模块级的系统测试、甚至可能是早期的review等等,这些早期的测试活动的质量还是很关键的,如果只是把力量关注于后端的系统测试,成本比较高,不是高效的做法。

        回复

    • 天堂旅人说:

      我们用的办法就是CCB,每个CCB都会由测试,开发人员,用户一起讨论,最后达成共识。不过我觉得如果有一个系统去跟踪这些变更,并且能准确的反馈这些变更带来的风险和进度的延迟,那么会更加完美,因为我总觉得领导们潜意识里总是要求很快地测试完突发的需求,以至于让人感觉这些变更的需求是被赶着完成的。

      回复

    • bob说:

      邰老师说几点,我基本都遇到过,也很疑惑。希望能给点意见 如何确保需求变更后测试不至于很狼狈。。

      回复

      • 邰晓梅说:

        首先要认同需求变更是个常态,与其花太多精力去想着如何避免需求变更(测试人员控制不了这个),不如“以动制动”,随时准备应对各种变更。
        这里“动”态的测试,指的是更flexible一点的测试策略,与传统的Waterfall Testing(拿到需求–开展分析–设计用例–测试执行)思想有所不同,不一定先知晓所有明确的需求才可以开展测试;不一定先制定完整的测试计划,才按照计划开展测试;不一定前期设计完成的测试用例没有执行完,就不运行其他的未事先设计的测试场景;不一定先开展脚本化测试,再开展探索性测试;不一定先写测试文档,再开展测试执行。。。
        可见,你的这艘测试小船的航线一直在动态修订中,当然不是漫无目的的修订,它的依据就是“风险”,每一次需求有变更,就是存在风险;每当测试中发现新的你没有事先预料到的问题,就是存在风险。。。
        没有人知道完整的risk list,你需要做的是尽可能早地、尽可能频繁地收集和知晓风险,尽可能用快速有效地测试方式(例如RST:rapid software testing)应对风险,以你为中心、而不是以测试文档或需求文档为中心,敏捷地开展测试。

        如果你习惯了传统的waterfall testing,可能会觉得上述这些“总体的”指导思想无所适从,推荐你看《黑天鹅》这本书,书中指出,人性有一个弱点:习惯于学习精确的东西,而不是总体的东西。人们不学习规律,而是学习事实,而且只学习事实。人们蔑视抽象的东西,这对于测试这种处于复杂环境的活儿来说是非常不切实际的。

        回复

        • bob说:

          一些主管老是强调:全集的场景库、全集的测试用例等等,其实就像邰老师所说“完整的risk list”是不可知的。测试所要做的就是尽量以最高效的方法覆盖尽量多的场景(按基本场景到特殊场景的优先级)。但是这样有会让人疑惑测试到底何时该结束(测试时间要求)~~
          有时间我要看看《黑天鹅》,感谢邰老师的推荐和分享~

          回复

    • angel说:

      這些問題都是目前測試過程中遇到的主要問題,很能一下解決

    Comment Box is loading comments...