开发项流程(Development Item Process)

当时的这个Scrum试点项目身负重任,其中之一就是要探索出在新型的敏捷模式下该使用何种的开 发流程,负责人就是当时的Linux部门经理,而我则捞到了负责测试部分流程的机会。整个试点项目的人员扩张速度不错,4个人的团队维持了好几个迭代,陆续有人加入,新的测试人员在大概是第四个迭代的时候才补充进来,而后逐渐扩张到两三个团队。这样的扩张速度对测试流程的确定来说非常好,一开始我可以只考虑自己的想法,不断地尝试摸索,可以很快地得到反馈然后改进;等到想法大致成形的时候,又可以专注于帮助其他成员理解流程和使用,验证流程的易用性;等到人员更多的时候,就可以着重验证流程的推广复用性。

试点项目并非是全权负责新产品的开发,它其实是归属一个更大的项目、产品的,产品经理在芬兰,芬兰也还有一些团队,两地之间的团队必须要合作,虽然杭州的项目享有流程等各方面的自由,但也必须考虑和芬兰团队现有模式流程协作的问题。流程中也要把这些细节都考虑进去。

我讨厌浪费,讨厌重复的信息,也不喜欢把不同特点的信息混淆在一起,而且流程要为人服务,它需要根据人在工作中的行为、活动特点来制定,而不是凭空想象,这是我在流程总结中所秉持的重要原则。因此,在流程中测试活动开展所需要的信息,每一份信息只应该存在于一个位置,其他地方全部应该通过链接或者引用使用这些信息,而且测试和开发都会用到的信息也适用此原则。信息应该分为长期存在和短期存在两种,可以看做是从读、写的角度进行区分:同一份信息和被测对象相关,且在可预见的未来还会继续被读写的话,看做是长期的类型;同一份信息主要是阶段性的,和特定的版本、时间点相关的,且在可预见的未来只会被读取但不会被更新(写)的,看做是短期的类型。两类信息或者以不同的文档进行维护,或者以不同的方式进行维护。

如下简单表述一下当时所设计出来的流程,这个流程因为种种原因在试点项目结束后没有被延续使用,但是大概是三四年后我已经成为敏捷教练的时候,意外得知它居然一直在别的产品线沿用至今(当时),其生命力可见一斑。我将侧重描述其变化、改进之处,和以往流程相同的地方则不做介绍。

  • 新流程的目标包括:推动开发和测试专家们的密切合作以提高软件的质量;合理化以及简化相关文档;减少文档数量,加强维护,以提高文档的质量;促进开发和测试人员之间的互相学习,以增加项目资源的灵活性;等等。
  • 开发项是新提出的概念,将软件的规格说明书撰写、设计、实现和测试封装在一起,作为最小的原子化产品组件(Component)。原子化的意思是保持开发项之间的互相依赖在可以做到的最低水平;移除或重排任何开发项的时候,对其他开发项不产生(或产生最小的)影响。
  • 在迭代开始前,先有技术报告或者需求文档,由此而产生出开发项;然后是和以往的项目过程一样的入口阶段,确定项目日程并且生成相关的高阶(High Level)文档。包括集成计划文档、项目计划文档、模块(Module)测试策略以及开发项测试计划文档都在此时创建。
  • 所有和开发项相关的测试活动都在Sprint内完成,这些测试被称之为DIT(开发项测试),测试用例本身还是属于以往的功能测试级别。但是开发项的测试计划、测试执行、报告等一系列过程全部都要在一个Sprint中完成,测试用例的自动化比例并未做硬性规定,但当时我们的成果是100%自动化。
  • 项目成员主要分为开发和测试两类工程师,但是角色的定义并不是拿来当做不可逾越的红线使用,必要的情况下,开发工程师也会承担部分测试任务甚至整个人投入测试,或者测试工程师也会和开发工程师一起,结对开发代码。
  • 开发人员的工作安排会受到测试工作的影响,每日站会或者平时工作中,可能会发现软件不容易测试,就需要开发人员协助检查以及修改代码提高软件的可测性。或者是在开始写测试脚本之前,就去跟开发人员约定程序输出的内容和格式。
  • 测试文档根据信息的长期性、短期性进行了区分。
    1. 测试计划与报告:将这两个单独的文档合并到一起,在单独的章节里展示各自的信息,每个软件发布使用一份测试计划和报告。总共四个章节:被测功能描述以及模块列表(持续更新)、持续集成测试状态(每个迭代的测试报告)、总结(质量评估、经验反馈、推荐和建议)、现存问题(尚未解决或仍不明晰的问题)。目的是在单个软件发布周期内持续记录测试的状态,缩减不必要的文档量。
    2. 测试用例与缺陷:每一个模块或技术领域使用一份测试用例及缺陷文档。文档内容包括:该模块或技术领域的整体描述,测试用例列表及状态,缺陷列表,测试辅助程序,操作命令。目的是提供一份可以全面了解被测模块或技术领域的文档,包括当前的所有功能、曾有的和现存的缺陷,以及如何使用操作命令和测试辅助程序进行测试。
    3. 测试用例清单:用Excel记录所有的测试用例即可,信息来自于现有的测试管理系统,包括测试用例的编号、已测过的最新软件发布、已测过的最新版本信息、测试用例的版本、测试用例名称、自动化的状态。
    4. 缺陷清单:用Excel记录所有的缺陷即可,信息来自于现有的缺陷追踪系统,包括缺陷的编号、标题、严重程度、缺陷单状态、相关的测试用例以及版本。目的是提供一目了然的缺陷清单,可以知晓其历史及现状。
    5. Sprint缺陷清单:记录在Sprint开发过程中发现的软件缺陷,相当于轻量级的缺陷追踪系统,无法当天修复的问题才会被记录下来,而无法在当前Sprint中解决的问题则会被录入缺陷追踪系统,并且录入前一个缺陷清单。

Linux编程培训

为了帮助新人快速地融入项目,我们还承担着开发一套培训课程的任务。在Linux环境下进行开发的同时,我们需要总结经验,有针对性地记录所需要掌握的各方面知识,并且做成培训材料,提供给加入团队、项目的新手。我也参与其中有少量的贡献。

查看更多“我的测试之旅”文章
1. 起点——作为软件开发人员
2. 转变——作为专职测试人员
3. 同期——加入测试自动化小组
4. 并行——自动化回归测试
5. 难点——功能改进的测试
6. 跳转——追逐新鲜事物的探险者
7. 启程——Scrum中的测试工作者
8. 困难——没有现成的测试工具
9. 行动——简化测试文档和流程
10. 贡献——开发项流程(Development Item Process)
11. 尝试——Scrum Master
12. 机遇——测试自动化培训师和教练
13. 转型——敏捷教练

敬请关注 《大测大悟——测试的敏捷之道》开放出版过程

联系方式:
- 新浪微博
- 谷歌邮箱 kaverjody @gmail.com
- LinkedIn