Sprint 过程中,如何扩展团队并与质量做整合

      在和某个想采用敏捷研发管理的客户交流过程中,发现客户存有一种认识,即团队的研发管理模式从传统的管理方式迈入新的敏捷研发管理模型时,只是研发模型的变更,团队还是同一个团队。但是角色定义要变化么?很多时候,客户会觉得没有必要,因为还是原来的开发团队,还是继续做开发项目,只不过快速响应需求,然后开daily standup meeting。这里其实存有误区。

  一个Agile 开发团队,常常可由开发人员、外派测试人员、用户体验设计师等组成

     用户体验设计师的加入,还是比较容易理解的。通过更早的将用户的体验意见向开发团队进行反馈,能促进开发团队在实现产品时,更好的理解产品设计文档。同时,加入的用户体验设计师,在Sprint过程中,还可以对开发团队每日交付的daily release进行必要的客户模拟测试,以持续改进需求。这里提到了用户体验设计师的测试,那Sprint过程中,是否需要其他测试人员的加入呢?加入的人员,又如何管理开发过程中的质量管理呢?

     首先,我们说Sprint过程中,需要测试人员加入开发团队。加入的测试人员,来源于测试大本营团队,这些人员我们称之为“流动的QA”。下面是关于“流动的QA”的定义及重要工作。

     流动的QA:推荐1-2名测试人员加入开发团队,加入的测试成员主导测试工作,测试结果直接影响剩余工作时间。流动的QA,通常会有2个办公室,一个在QA大本营,一个在开发部门。流动的QA,与Sprint过程有关的重要测试工作包括:

     在Sprint中,需求以Story的形式分配到Sprint中,Story通常包含一组已分类的开发任务。TechExcel 的DevSuite工具为我们展现了Sprint、Story和开发任务的层次结构。

    image002.gif

   通过Story,我们可以很容易的找到基于需求,创建生成的具体测试用例。然后我们来看,测试人员如何将设计好的测试用例,紧密地与开发任务相关联,从而指导具体的测试过程呢?通过下面这张图,我们可以直观的看到相互间的关联。

  image004.jpg

 在TechExcel的DevSuite产品中,通过QA Test Co-owner Event ,很好的表达了这样的关系。

     QA Test Co-owner Event是一种QA测试协同子任务,它作为开发任务的一部分而存在,是一种具体的测试任务单。每个QA Test Co-owner Event可以将测试用例与开发任务相链接,它的描述信息里包含了具体的测试步骤,并且每个QA Test Event有自己的负责人和状态。通过QA Test Co-owner Event,我们可以让敏捷团队遵循需求的质量标准,指导开发过程中的具体产品测试。QA Test Event的测试结果,直接影响开发任务的剩余时间。

       image006.gif

继续来看“开发和测试合作,完善并创造测试用例,达成有质量保证的开发结果”。如何来理解“Sprint过程中……完善并创造测试用例……”?

敏捷开发中,质量的管理常常遇到以下的情况:

    Product Owner常常问:“测试用例在Sprint开始前,能基于需求定义完整的测试用例么?”

    QA Leader:主要根据需求的颗粒度,需求表达的越完整,细致,在Sprint前定义完整测试用例的可能性越高,从而将测试用例更好的用于开发任务的具体测试指导。在开发完成后,达成有质量保证的开发结果。

    Product Owner再问:但往往需求总是在变化,而且很多时候,需求无法一次性完整表达,需要随着开发的进展,让敏捷过程的所有参与者,来不断理解需求的表达。那这种情况下,是否意味着开发任务的测试指导是不够全面的,因为确实很难在Sprint开始的时候,就完整定义表达所有的测试用例?

   QA Leader:关于这个问题,我们会尽量在测试部门增加测试每日例会,随着需求原型开发的进度,不断让测试部门在测试空间创建维护新的测试用例,并重新将测试用例通过QA Test Event关联到开发任务。

    Product Owner继续问:开发团队如果在实际开发过程中有新的测试点发现,我们如何管理这部分“过程智慧”,完善测试用例?

   QA Leader:一般让开发团队告诉测试人员,再由测试人员到“测试空间”进行维护操作,再关联到开发任务。

   Product Owner:虽然可行,但总觉得很繁琐,也不够完善,很容易习惯性的丢失这部分过程智慧。

   QA Leader:…… ……

      如果您的团队也遭遇了相同的场景,该如何改进原有的过程呢?而现实的敏捷开发项目中,确实存在开发过程中,开发和测试一起执行测试的时候,除了引用定义好的测试用例以外,还存在不断完善并创造新的测试用例的过程;e.g. 当发现了一个BUG的时候,应该立即为这个BUG增加一个测试用例。


    image008.jpg

TechExcel的DevSuite9.2系列,很好的回答了这个疑惑。

通过QA 测试协同子任务,可以帮助您做到:

    • 为开发任务,关联已存在的测试用例;
    • 完善并创造新的测试用例

   image010.gif

    通过以上介绍,我们对一个敏捷开发团队的人员组成有了新的认识。同时Sprint过程,介绍了开发、需求与质量如何进行整合,并通过具体管理工具的场景落地,加深了效果。

     那么在敏捷开发团队中,包含了流动的QA角色,是否就完成了敏捷开发与质量管理的完全整合呢?在文章的最后,我们留一个小小的疑问,是否需要对Sprint进行质量管理的扩展呢?以下哪些观点是正确的:

   • 好的Sprint开发过程应当保证产品完全没有缺陷;
   • 缺陷在Sprint开发过程中应当被发现;
   • 缺陷在Sprint开发过程结束后被发现;
   • 缺陷应只分配到以后的Sprint中加以修复;
   • 缺陷应当在当前Sprint中全部被修复;
   • 缺陷应该尽快被修复。

 欢迎大家提出新的想法。