我的软件测试之旅:(10)贡献——开发项流程

  1. 云栖社区>
  2. seven的测试人生>
  3. 博客>
  4. 正文

我的软件测试之旅:(10)贡献——开发项流程

玄学酱 2017-07-10 16:01:00 浏览689
展开阅读全文

开发项流程(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环境下进行开发的同时,我们需要总结经验,有针对性地记录所需要掌握的各方面知识,并且做成培训材料,提供给加入团队、项目的新手。我也参与其中有少量的贡献。








====================================分割线================================



最新内容请见作者的GitHub页:http://qaseven.github.io/

网友评论

登录后评论
0/500
评论
玄学酱
+ 关注
所属云栖号: seven的测试人生