需求阶段测试可以做什么?

测试人员不是在开发人员代码实现后才开始介入一个项目的,而是在一个项目开始立项后就开始介入,这个已经是个不争的问题了。那么,测试在项目的早期可以做哪些工作呢?测试前移是个很大的话题,本文只讨论一下需求阶段测试人员如何介入?以下所讨论的测试可以做的具体事情,无论是在V模型下还是在敏捷模式下都适用,只不过在不同的上下文中,这些事情做的程度和方式有所不同。

首先,需求阶段如何定义?比较完整的需求阶段至少包括两个部分:一是初始包需求(OR-Offered Requirement)确定阶段,这个阶段的参与人员会直接和市场、用服、客户沟通交流、调研,确定产品开发的初始需求;二是初始需求交给研发团队,系统工程师进一步分析,结合产品原有基础、收集内外部需求,得出产品要实现的包需求,并采用系统分析的工程方法开展对包需求的深入分析,得出更细化的需求描述,输出可以被实现的设计需求,交给软件实现人员。如果按照CMM流程,前面一个阶段CMM貌似涉及 不多,对应Charter之前的工作;后面一个阶段对应TR2之前的工作。

一般而言测试的前期介入大多指介入后面一个阶段,其实前面一个阶段测试也应该参与,当然,参与前面一个更早的需求分析阶段,对测试人员的要求会更高一些,需要对系统层面有较好的把握。

 

(1)测试参与早期需求分析

这个阶段收集到的需求都是比较粗的,测试更多的可以从系统验证的角度考虑问题,即这些粗的需求如果实现后,后期交给客户时,是否可验收,有哪些验收场景、验收的思路是什么、具体的商用使用场景、需求验收是否需要特殊的验证平台、有哪些验收难点等等。可以输出《需求验收分析报告》。这样做的好处,一是测试人员通过早期参与,更清楚需求的来源和目的,有利于后期更好的从用户的角度开展测试活动;二是可以为后期设计验收测试用例提供很好的分析依据。

如果您在这个阶段的测试介入有很多实践经验的话,欢迎回复本文分享!

(2)测试参与TR2之前的需求分析

这个阶段的需求仍然比较粗,至少开发人员拿到这些OR直接去实现难度还是很大的。系统工程师会从全系统的层面开展稍微细一些的需求分析,得到具体的设计需求,其主要的思路主要是针对每个OR开展场景分析,测试介入的主要工作就是重点参与场景分析工作,因为开发的SE和测试的TSE分析问题的思路是不同的,可以做到很好的互补,所以理想的方式是SE和TSE一起完成场景分析工作:SE偏向从功能、实现的角度分析,TSE更多的考虑非功能属性方面,比如可靠性、可测试性等,还会考虑用户分类、异常场景、组网的不同等,这样二者合作的结果,使得设计需求更易于实现,也一定程度消弱了需求由于分析不充分导致后期的频繁变更的问题。在敏捷项目中,测试参与的结果经常以“验收条件(Acceptance Test Conditions)”的形式体现在需求文档中,每一条需求都对应其验收条件。

另外,这个阶段测试还应该发挥测试的优势,提出产品的可测试性需求,以便开发在实现阶段就考虑进去。

当然,除了上面提到的以外,测试在早期的任何时候都可以针对开发的各种分析输出件给予很好的评审检视,缺陷越早暴露成本越低。测试在需求阶段参与的更大的意义在于实施preventive testing,这与简单的文档review是不一样的,preventive testing强调的是测试人员用他的测试知识/领域知识去challenge需求和设计,去提前验证他的idea,去explore需求,可见,探索性测试的思想完全可以在需求阶段应用。

此外,Richard Bender所提的基于需求的测试(ReqBT)也是一套可行的方案,在需求写作初稿阶段,ReqBT人员与需求分析人员并行交错开展工作,一点点地完成需求的模糊度分析、需求的业务逻辑分析、需求的建模以及测试条件生成等工作。

测试在需求阶段还可以做哪些,欢迎各位补充!

 

需求阶段测试可以做什么?》有 9 条评论

  1. 天堂旅人说:

    在我们平台部门,一般TR2前基本上是没有测试什么事情的,不过在一个产品迭代版本开始迭代之前,一般都会由TSE和PL输出测试需求分析和测试策略文档。但是,不知道是因为TSE能力有限还是我们这些TE忽略了测试需求分析文档,迭代中我们很少会拿测试分析测试策略中的东西去指导测试,而是自己再单独写测试方案,对于一些特性的使用场景会找开发人员或者产品人员确认,做到最后,感觉测试需求分析和策略并没有太大用处。
    今年下半年,我参与了一个特性支撑产品的测试,这个产品涉及到从硬件,OS到应用软件多个部门产品的集成,与我合作的开发人员是一个经验老道的程序员,他做项目的方式就是不断和产品交流,看产品的代码,一点点了解产品的真实需求,不断改变自己的设计,再编码,编码后只要有可能就马上把发布件交给产品跑,这样经过三轮迭代下来,交给产品使用几乎没有出现过下游问题,我也几乎测不出什么功能性的大问题。这个项目做下来,我几乎感觉不到IPD流程的存在,在所谓TR2之前,他就已经拿代码和产品联调了,在后续的迭代过程中,他实际上只是在联调的时候针对与产品联调出来的问题新增了一些特性,所谓迭代就是硬生生地将这些特性分阶段完成了。作为测试的我比这位开发人员介入这个项目晚了一个月,当时,我介入的时候他写的代码都已经在和产品联调了,介入后,我只能得到一堆很难看懂的产品的需求分析和设计文档,于是,我干脆直接找这位开发了解了产品的使用场景,再根据他设计的模块进行测试分析,测试需求分析主要是拿产品的场景和模块功能进行正交输出测试规格,最后将这些测试规格分成两个迭代落入。但是实际操作的时候,我觉得我的测试特别无力,首先,作为测试,我没办法得到第一手的用户的资料,而是通过一个开发口述来了解产品的特性,其次,我在测试的时候,只能通过模拟的方式构造场景(环境紧张,那位开发人员一直占用产品的环境和他们一起联调。)
    现在回过头来看看,我觉得测试在这个项目里的价值很有限,首先,测试不能拿到第一手的用户需求,只能通过开发人员的口去了解产品需求,那么,我们做的测试实际上只能是去验证开发设计与编码是否一致,而不是完全代表客户去验证,其次,开发人员与产品人员有紧密的配合,包括能在第一时间在产品的环境上验证,而测试只能在模拟的环境上去测试,使得测试的意义很小,实际上到最后测出来的都是些小问题。 测试在这个项目里只是做了给开发“擦屁股”的这个工作。我觉得,在需求分析阶段,测试和开发必须独立地去了解需求,并且测试最好要能看到用户的真实环境,否则的话,我们的意义就不是特别大了。

    回复

    • 邰晓梅说:

      “迭代中我们很少会拿测试分析测试策略中的东西去指导测试”
      –》这也比较正常,planned testing in advance如果没有辅以update in time的话,在后期迭代开始后,这测试策略以及分析很可能已经过时了,自然得不到应用。

      这个老道的程序员所做的事就是我们提倡每个测试人员,尤其是前期介入的测试人员应该做的事情:尽早测试、主动收集了解需求、及时收集风险并做相应的处理、频繁的沟通而不是只依赖文档。。。

      “测试不能拿到第一手的用户需求,只能通过开发人员的口去了解产品需求”
      –》真的没有任何途径可以了解第一手的用户需求吗?需求从用户那里走到研发,经历了层层路径,有很多文档可以参考、人员可以询问,尤其是需要参考charter之前的早期需求分析阶段的输出;测试从开发人员那里了解产品需求也是构成测试的输入的一部分,此外,测试还可以尽可能地从SE那里、从PM那里、从技术支持那里、从市场及用服那里等等去收集测试的输入,以便全方位多角度地了解被测需求。不是“只有需求具备了才可以开展好测试”,而是“需求缺失的现实情况下,更需要测试人员去测试,因为这时往往意味着风险更大”

      “开发人员与产品人员有紧密的配合,包括能在第一时间在产品的环境上验证,而测试只能在模拟的环境上去测试,使得测试的意义很小”
      –》测试为何无法做到这一点?有无改进的余地?如果实在没有办法,是否可以和开发一起第一时间在产品环境上结对验证?虽然环境不同,开发和测试验证的内容是否完全一致?测试验证的独特价值在哪里?有没有明显的IPD流程并不重要,尤其在敏捷迭代的背景下,在这个项目的当前上下文下,也许平台的开发和测试更密切的合作,与产品人员及时沟通,向着“完整团队、自组织运作、尽早测试、基于风险测试”的方向前进,不失为一个好办法。

      回复

    • 空谷足音说:

      文末最后说:“测试和开发必须独立地去了解需求”,表示不同意,测试和开发,都是围绕解决用户需求,没有用户就没有需求,没有需求就没有产品,没有产品就没有功能,没有功能就没有开发,没有测试,没有IT,额,啥都没有了。而开发和测试我觉得都是为了解决用户的需求,怎么能独立去了解需求呢?应该共同去了解,一块儿去了解,用户往往不能把需求说得那么明白,所以开发和测试,都是帮助用户把需求弄得清清楚楚,明明白白。只是开发和测试的角度不同。

      回复

      • 邰晓梅说:

        也许是原文表达不够清晰,我的意思也是测试和开发应该一起理解需求。

        回复

        • 空谷足音说:

          邰老师,客气。是我表达的不准确,我说的“文末”是指“天堂旅人”对你那篇文章所做的评论的“文末”,我和你的看法是一致的。

          回复

  2. 天堂旅人说:

    还有一点是我自己的想法,因为TR2之前从开发的角度来说,会有架构师对软件进行架构,那么,我们测试是不是也应该有架构呢?我从《完美测试》这本书里看到过测试架构一词,但是似乎还是不太理解。从我当前做的项目出发,我觉得应该是描述这个版本要测试些什么特性,每个特性有哪些规格(包括功能性和非功能性的),是否要自动化,如何自动化。总之,我觉得一个理想的测试过程应该是一个顺畅地将原始需求转化成完整的测试用例的过程,而良好的测试架构应该是流程正确执行的保证。
    我觉得当前我们项目最头痛的事情是我们的OR和用例对应不起来,甚至时间久了都不知道一个用例到底测试了哪个特性,一个特性是由哪些用例来测试的,以至于我们在做质量保证的时候,都无从下手。
    所以我觉得,一个产品在需求阶段就应该有一个良好的测试架构,能保证测试的有序。

    回复

    • 邰晓梅说:

      “架构”是个好词,很多人都喜欢用,测试当然也有自己的架构,不同组织内可能是不同的角色完成的,未必一定得有“测试架构师”这个职位。

      比如,我个人认为HW的测试架构的工作主要体现在两个角色里:版本测试经理(TM)以及测试系统工程师(TSE)。做好测试架构,既需要从技术层面考虑,也需要从管理层面考虑:What to test?How to test?

      “顺畅地将原始需求转化成完整的测试用例的过程”确实是个“理想”的测试过程,因为现实中的测试过程都不会这么顺利。所以,我们何苦去追求这些不可能成为现实的理想过程呢?像敏捷的思想一样,我们承认变化甚至拥抱变化,我们接受“需求会不完整、不清晰、会变化”,我们知道“测试用例不是一次性的过程、不是提前计划的事情、需要不断基于风险调整”,所以我们会相应地开展测试活动,那些更flexible、更explorable、更risk based的测试方式也许更适合我们,比如agile testing,exploratory testing,rapid software testing等。

      “良好的测试架构应该是流程正确执行的保证”
      –》良好的测试架构一定是循序演进的、及时调整的,是提高测试有效性的重要手段,它的目的不是“正确地执行流程”,因为流程未必适合我们。

      回复

      • 空谷足音说:

        架构,架构,也就是个计划,把计划拔高提升优化美其名曰就是“架构”。计划和实际,理想和现实总是有许许多多的“阴晴圆缺”,变化是普遍存在的,不止是测试,万事万物都是一样,世界上只有变化是一定的,山不一定高,还不一定深,花红不一定有心开,走不一定慢,跑不一定快,开发不一定能按计划,测试不一定能保质量,努力为之,而在努力为之的过程中,积极预防风险,扎实做好控制,总结规律,形成经验,使更多的不可控变得可控,这就是拥抱变化。“变则通,通则久”。

        回复

    • 邰晓梅说:

      “OR和用例对应不起来”,这个一般应该不难,因为OR都比较粗,每个OR总能找到用例与之对应。也许你想对应的需求是更具体一些的需求,比如设计需求。

      这个问题谈的是traceability的问题,我们做这个更多的是为了知晓测试覆盖。有很多团队花很大力气通过人工或工具的方式不断地维护需求与测试的traceability matrix,收效不一定那么理想。

      理解这个问题,首先得理解testing coverage,Cem Kaner曾经在《SOFTWARE NEGLIGENCE AND TESTING COVERAGE》文章中给出了101种看待software coverage的方面,每一个方面都是我们应该测试的,那么测试何时才能覆盖完整?
      所以谈到测试覆盖,首先得明白你希望覆盖的是什么,是否一定要按照原始的需求逐条覆盖?1.5日我介绍基于需求的测试的Webinar中会探讨ReqBT方法是如何选取覆盖基准的,欢迎参加。

Comment Box is loading comments...