在华为业务线上有近40天的时间了，参与了两个版本，华为的项目大多数走的都是敏捷迭代开发模式了，至于什么是敏捷，网上有很多的解释与资料，这里就不阐述了，就说说这期间华为的一个敏捷模式。
敏捷开发的最大特点是：积极响应用户的需求，快速高质量的交付软件。所以很多需求会按照用户需求程度以及模块之间的关联程度划分为多个迭代，这里的迭代你可以看做是一个小的完整的版本周期，每个迭代包含多个story，一个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、测试报告，从发现问题多少、严重性以及聚焦的功能点等考虑对版本给出质量评价，并合理的给出建议，比如加强开自验、加强用例输出的标准等。