敏捷测试 - 华为

在华为业务线上有近40天的时间了，参与了两个版本，华为的项目大多数走的都是敏捷迭代开发模式了，至于什么是敏捷，网上有很多的解释与资料，这里就不阐述了，就说说这期间华为的一个敏捷模式。

 

敏捷开发的最大特点是：积极响应用户的需求，快速高质量的交付软件。所以很多需求会按照用户需求程度以及模块之间的关联程度划分为多个迭代（什么是迭代式开发，下文会讲），这里的迭代你可以看做是一个小的完整的版本周期，每个迭代包含多个story，一个story相当于一个功能点，一个小的需求，而一个大的完整的发布版本一般由几个迭代版本组成。敏捷开发的周期一般都很短，一个月或者最多两个月时间，节奏非常快，所以大部分人都觉得有点累。

敏捷软件开发典型场景：

      1、PO（产品负责人）和开发团队对产品业务目标形成共识
　　2、PO建立和维护产品需求列表（需求会不断新增和改变），并进行优先级排序
　　3、PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发
　　4、开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成
　　5、开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明
　　6、PO对每轮迭代（2-4周）交付的可工作软件进行现场验收和反馈
　　7、回到第3步，开始下一轮迭代

 

下面说说整个敏捷迭代的过程：

一、迭代计划会议：
     每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程
     输入：产品Backlog   输出：迭代Backlog

    迭代计划会议内容：
    1）澄清需求、对“完成标准”达成一致
    2）工作量估计、根据团队能力确定本轮迭代将会内容
    3）细化、分配迭代任务和初始工作计划

    关键点：
    1）充分参与：Scrum Master确保PO和Team充分参考讨论，达成理解一致
    2）相互承诺：Team承诺完成迭代Backlog中的需求并达到“完成标准”
    3）PO承诺在短迭代周期不增加需求（2-4周）
    4）确定内部任务：Team和PO协商把一些内部任务放入迭代中，由PO考虑并与其他外部需求一起排序

 

二、每日站立会议：

     每日工作前，团队成员的例行沟通机制，由Scrum Master组织，Team成员全体站立参加

     聚焦主题：

     1）我昨天为本项目做了什么

     2）我计划今天为本项目做什么

     3）我需要什么帮助以便更高效的工作

    每日站立会议好处：

    1）增加团队凝聚力，产生积极的工作氛围

    2）及时暴露风险和问题

    3）促进团队内成员的沟通和协调

    关键要点：准时开始，高效会议，问题跟踪

 

三、可视化管理：
     将项目状态（进度、质量等）通过物理实体（拍板、屏幕）实时展示，让团队所有成员直观地获取当前项目进展信息

     关键点：
     1）物理实体：可视化一定要做到物理上的实体化，大家在公开场所都容易看到
     2）内容精简易懂：信息展示一目了然，切实对团队有帮助
     3）实时刷新：延迟的信息拖延问题暴露，降低运作效率

 

四、迭代验收：
     每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求
     由Scrum Master组织，PO和用户代表负责验收，Team负责演示可工作软件

     关键点：
     1）展示真实的产品
     2）收集反馈

 

五、迭代回顾会议：

     在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步

     关键点：

     1）会议气氛：Team全员参加，头脑风暴发现问题，共同分析根因

　  2）关注重点：Team共同讨论优先级，将精力放在最需要的地方

　  3）会议结论要跟踪闭环：可以放入迭代迭代Backlog中

 

敏捷工作件：

产品Backlog(需求清单)

     经过优先级排序的动态刷新的产品需求清单，用来制定发布计划和迭代计划

    关键点：

    1）清楚表述列表中每个需求任务对用户带来的价值，作为优先级排序的重要参考
    2）动态的需求管理而非“冻结”方式，PO持续地管理和及时刷新需求清单，在每轮迭代前，都要重新筛选出高优先级需求进入本轮迭代
    3）迭代的需求分析过程，而非一次性分析清楚所有需求（只对近期迭代要做的需求进行详细分析，其它需求停留在粗粒度）

 

迭代Backlog

     迭代Backlog是团队在一轮迭代中的“任务”(Task)清单，是团队的详细迭代开发计划，当团队接收从产品Backlog挑选出要在本轮迭代实现的需求时，召开团队迭代计划会议将需求转化为具体的“任务”，每项任务信息包括当前剩余工作量和责任人

     关键点：

     1）任务要落实到具体的责任人
     2）任务粒度要小，工作量大于两天的任务要进一步分解

 

完成标准

     基于“随时可向用户发布”的目标制定衡量团队工作是否已完成的标准，由团队和PO形成共识

     关键点：

     1）团队自协商：团队根据项目实际情况来定义完成标准，并严格遵守
     2）有层次：一般分为三个层次，Story级别，迭代级和发布级，每个级别都有各自的完成标准

-------------------------------------------------------------------------------------------------------------------------------------

接下来说说测试是从什么时候介入以及有哪些工作的：

1、story澄清会议（即需求澄清），参与人员：开发人员、资料开发人员、测试人员、TSE、需求接口人等。

     目的：1）理解需求背景和价值

              2）保证SE、开发、测试人员对需求场景、处理流程、依赖与限制、交付件理解一致

              3）明确接口

              4）明确测试场景、关键测试点

     内容：1）SE介绍需求背景和价值

             2）开发人员按场景和业务流程讲解自己负责的模块输入、处理和输出

　　　　  3）其他人员针对需求提出问题，保证对需求的理解一致

             4）测试明确测试范围和关键测试点

     关键点：1）需求澄清要正式面对面交流，结论要发纪要，会后相关人员确认结论

                2）SE在澄清过程中，就一些关键点（容易遗漏、犯错的地方）提问，确认开发与SE的理解一致

                3）对于复杂的功能模块，开发人员可以准备demo演示，这样也有利于测试人员测试用例的输出

2、测试人员根据需求澄清会了解的需求，设计编写测试方案，完成测试用例的输出，测试用例完成后给开发人员、TSE、BA对用例进行评审，评审后根据评审意见对用例进行修改，直到大家都认可，最后导入用例管理工具中。

3、迭代story转测试前，测试人员需对程序进行冒烟测试，冒烟测试通过后才能转测试。

     转测试附带的文档：代码检视确认报告、测试组提供用例的执行结果报告、开发自测用例样例参考等。

4、测试执行，测试人员执行测试用例>>提交Bug>>回归问题>>关闭问题

5、迭代结束，回归会议，开发、测试、PM、SE 一起对此次迭代版本的进行质量分析

6、问题单分析，分析每个问题单产生的原因，是测试用例遗漏、老版本遗留的问题还是修改引入的问题？如果是用例设计遗漏还需要补充用例的，如果是开发的修改引入比较多，那开发的麻烦就大了，是需要通报批评的。

7、测试报告，从发现问题多少、严重性以及聚焦的功能点等考虑对版本给出质量评价，并合理的给出建议，比如加强开自验、加强用例输出的标准等。

 

------------------------------------------------------------------------------------------------------------------------

简单说说迭代式开发

迭代式开发：将整个软件生命周期分成多个小的迭代（一般2至4周），每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。

迭代开发优点：

　　1）通过将高技术风险的需求在早期迭代里实现，有助于尽早的暴露问题和及时消除风险

　　2）通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的需求

　　3）通过不批量减少排队，提供更灵活，快速的交付能力

　　4）平滑人力资源的使用，避免出现瓶颈

迭代开发的关键点：

　　1）每一次迭代都建立在稳定的质量基础之上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完美

　　2）每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈

　　3）迭代采取固定的周期（2-4周），迭代内工作不能完成，应当缩减交付范围而不是延长周期