敏捷测试理论以及实践(5)

简介:

以前在《结合工具来实现敏捷开发》这篇文章中,我已经谈到了我们公司目前的开发情况,在这里也不再重复介绍了,反正主要就是用 TechExcel的 DevSuite 系统来进行管理整个流程。至于很多人可能会问,既然敏捷了为啥还要用工具,其实我是这么想的,敏捷开发/测试,如果对于简单的项目而言,用工具反而会效率下降,因为就这么几行代码,这么几个功能,一下子就可以弄好了,弄个工具反而浪费时间。

  但是对于稍微大的项目而言,可能不用工具就没法很好地管理项目了,比如说好了,一个团队在一个迭代周期中做了10个功能,测试人员一天发现了40个Bug,但是修的人(由于部分人还在做功能)每天最多只能修20个,那剩下的20个Bug怎么办,当然是延迟到下一天修了,一个迭代周期往往是一周到二周,假设两周好了,如果每天都能多余20个Bug的话,就累积了200个未修的Bug,假设没有缺陷管理工具的话,我这些Bug可能只用Excel文档管理一下,Excel对于单个用户而言,保存信息其实做得很不错,报表也很Ok,但是想想这么多开发和测试需要打开同一个Excel文件,做查看,做更新,我相信Excel数据会被搞乱,而且Excel没法做跟踪,没法设置流程,也就是比如说我想知道这个Bug经历过几个状态,经历过几个人的处理,我应该是没法找到的。

  所以工具有用么,我觉得还是有用,对于大中型项目,既然想用敏捷,我还是建议用工具,不然的话,这个敏捷最后肯定会变成不敏捷的。 就像乘坐公交车一样,如果就是100米的路,我劝你还是走路(敏捷)算了,因为公交车还要起步、停车和等红绿灯了,也许你走得都比它快;如果是10公里的路,您当然会选择公交车(工具)。对于敏捷而言,因为是有很多迭代周期组成,每个迭代周期其实相当于一个100米,但是很多迭代周期组合在一起就变成了10公里了。真正的敏捷,它只是一种指导思想,没规定你必须怎么做(也就出现各式各样的实现方式),所以,在正常的工作中,我们需要根据每个公司的实际情况来搭配符合你们实际情况的敏捷模式。

  大家在百度上,只要搜索“敏捷测试”,我相信可以找到一大堆的内容,有概要的,有详细的,仔细看看,大家会发现很多人认为敏捷肯定是这样子的,那样子是不对的,当然大家对于“这样子“的描述又都不是太相同,分析一下,无非就是两种原因,一种纯粹是自己瞎想的,可能稍微有点底子,但是没实际用过,就按自己的想法,乱分析一番;另外一种就是真正在用的,所以就用自己公司的情况来解释一下敏捷。当然,我其实也是结合自己公司的情况在说敏捷,所以我不会苛求大家一定要采用我的理论,只是希望大家能从我的文章里发现一点对你们来说有用的知识,那我就很开心了。

  好了,闲话少说了,不管您有没有理解为什么要用工具,我还是继续下去了(有问题可以私聊)。

  对于TechExcel的DevSuite,以前也介绍过,也一直用到现在,感觉挺好用,不过在这里也不多介绍了,就给个图和然后把我们会用到的产品做个交代,不然之后万一提到某个产品,大家可能不知道是啥了。

  其中对于敏捷测试而言,需要用到的主要是以下三个产品:

  1、DevSpec:需求管理,用于测试人员(设计测试人员)检查功能的设计

3、DevTest:测试管理工具,用于管理测试用例,以及用测试用例来生成测试计划并且实施测试(包括自动化测试)

  这三个产品可以集成在一起用,也可以分开单独用,当然我们是集成起来用的。

  接下来我就按照测试的实际流程来介绍一下敏捷测试在我们公司的具体实现情况。

  1、需求设计阶段:

  我们公司也是开发产品的,主要是开发CRM方面的产品,和其他软件企业也一样,我们每个版本的发布首先是需要先收集客户需求开发相应功能、自己研发出新功能以及查看研究并超越竞争对手的功能。

  这部分的工作主要是在DevSpec进行,DevSpec是主要用来管理需求和分配需求让开发去开始做的,它会对每个功能(不管是客户的,自己的,或者研究竞争对手得出的)新建一个条目项,每个条目都会有自己的属性,包括标题,负责人,状态等,反正你想加什么属性都可以自定义的。然后负责人登录系统就可以看到分配给他的条目,他处理完了就必须把状态改到下一个状态,并且分配到适当的其他负责人。对于测试而言,我们设置有一个状态叫做“测试审核”状态,一般一个需求点到了这个状态,咱们设计测试人员就会去处理这个需求,处理的方式,一般就是从原始的文档入手,去看看现在的设计是不是符合原始的文档,如果有出入的话,他就会去和设计人员交流一下,然后把这个条目打回“需要重新设计”状态,设计人员弄完就会重新更改状态,最后测试人员审核通过后,就可以进入“待开发“状态了。

  这里强调一点,在这个阶段,所谓的设计测试人员,并不一定必须是专职的,他可能是项目经理或者是其他人,但是他一定是一个有能力来判断设计思路是否符合要求并且有权力让设计人员重新去设计的人。

  这就是需求设计阶段,测试人员要做的事情。下面贴个DevSpec的图作为今天文章的结尾。(未完待续)

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

目录
相关文章
|
4天前
|
敏捷开发 数据可视化 Devops
敏捷测试价值观、方法和实践读书笔记(4)
本章节探讨了敏捷测试执行的关键概念与实践。首先介绍了用户故事及其重要性,强调其在敏捷开发中的角色,并阐述了用户故事的 INVEST 原则。接着分析了用户故事生命周期中的测试关注点,包括定义、处理、完成及验收阶段的测试活动。此外,还对比了不同测试术语的差异,并提供了敏捷测试计划的策略与过程。通过看板等工具实现任务管理与跟踪,确保测试活动高效进行。最后,介绍了敏捷测试中的度量指标,帮助团队评估测试效果。
16 5
敏捷测试价值观、方法和实践读书笔记(4)
|
4天前
|
监控 架构师 Devops
敏捷测试价值观、方法和实践读书笔记(3)
本章节介绍敏捷测试转型框架,涵盖模型概览、实施难度与顺序、文化转变、角色技能需求及测试流程。敏捷测试转型模型包括文化、组织、流程与实践等关键要素,并针对各层面提出具体实施建议与障碍解决方案。此外,详细阐述了不同敏捷测试角色的技能需求与职责,以及从Sprint内至跨Sprint的测试流程与交付物。
15 5
敏捷测试价值观、方法和实践读书笔记(3)
|
4天前
|
开发框架 数据可视化 项目管理
敏捷测试价值观、方法和实践读书笔记(1)
敏捷软件开发宣言在身体力行的同时也帮助我们一直在实践中探寻更好的软件开发方法。由此,我们建立了如下价值观:个体和互动 高于 流程和工具工作的软件,高于 详尽的文档客户合作, 高于 合同谈判响应变化,高于 遵循计划。也就是说,尽管右项有其价值,但我们更重视左项的价值。
17 4
敏捷测试价值观、方法和实践读书笔记(1)
|
4天前
|
JavaScript 前端开发 Java
敏捷测试价值观、方法和实践读书笔记(5)
本章节介绍了敏捷功能测试的原则与实践,包括单元测试的概念及其编写步骤,测试驱动开发(TDD)的流程,以及如何通过模拟对象进行测试。详细讲解了单元测试的编写方法,如初始化对象、执行操作及验证结果,并探讨了 TDD 的五个步骤。通过具体案例展示了如何逐步完善储蓄账户的功能测试,包括存款、取款及异常处理。此外,还讨论了代码覆盖率的重要性及其局限性,强调了测试充分性比单纯追求代码覆盖率更为关键。
11 3
敏捷测试价值观、方法和实践读书笔记(5)
|
1天前
|
Ubuntu jenkins 测试技术
软件测试中的自动化与持续集成实践
【9月更文挑战第15天】在软件开发的快节奏世界中,自动化测试和持续集成(CI)已成为确保质量和效率的关键策略。本文旨在揭示如何通过实施自动化测试框架和CI流程来优化开发周期,减少人为错误,并加快产品上市时间。我们将探讨一些实用的工具和技术,以及它们如何帮助团队实现更流畅、更可靠的软件发布。
|
8天前
|
Web App开发 Java 测试技术
自动化测试的利器:Selenium WebDriver入门与实践
【9月更文挑战第8天】在软件开发的海洋中,测试是确保我们不会溺水的那根救生索。Selenium WebDriver,作为自动化测试的明星工具,让这根救生索更加结实可靠。本文将带你快速上手Selenium WebDriver,从基础设置到实际操作,再到实战演练,让你的开发之旅更加平稳顺畅。
|
5天前
|
JavaScript 前端开发 数据库
数据库测试场景实践总结
本文介绍了数据库超时和应用锁表SSDB测试场景的验证方法,通过锁定数据表模拟写入失败情况,并利用SSDB进行重试。测试需开发人员配合验证功能。同时,提供了SSDB服务器登录、查询队列数量及重启服务等常用命令。适用于验证和解决数据库写入问题。
17 7
|
4天前
|
机器人 测试技术
敏捷测试价值观、方法和实践读书笔记(6)
验收测试驱动开发(ATDD)强调在开发前定义验收标准,并通过自动化测试确保用户价值得到满足。验收测试关注用户需求是否实现,而非代码细节。ATDD涉及用户、产品负责人、开发人员及测试人员,通过讨论、开发和交付三个阶段,确保产品符合预期。此方法有助于团队更好地理解和实现用户需求。
17 5
|
2天前
|
监控 jenkins 测试技术
软件测试中的自动化测试策略与实践
本文将深入探讨自动化测试在软件开发中的重要性及其实施策略。我们将从自动化测试的基本概念入手,分析其在提高软件质量、缩短开发周期和降低维护成本方面的优势。通过具体案例,展示如何有效地规划和执行自动化测试,以及如何评估其效果。
11 1
|
4天前
|
敏捷开发 测试技术
敏捷测试价值观、方法和实践读书笔记(2)
本章节介绍敏捷测试在快速变化的软件开发环境中的重要性。传统测试方法在敏捷环境中面临时间紧迫、文档不足、频繁变更及资源短缺等挑战。敏捷测试遵循敏捷开发原则,强调测试与开发的紧密融合、团队协作及业务价值交付。其特点包括更强的协作、更短的周期、更灵活的计划及高效的自动化。相较于传统测试,敏捷测试具有加快产品上市时间、提升整体质量及简化流程降低成本的优势。
11 3