敏捷软件测试的七个关键成功要素(2)

　　自动化回归测试是团队的工作。整个团队应该选择每种测试适合的工具。提前考虑测试将帮助开发人员为了便于测试自动化来设计代码。使用敏捷测试象限和测试自动化金字塔来帮助你自动化各种类型的测试。

　　记住从简单入手。你会惊讶地发现一些基本的自动化冒烟测试或者自动化单元测试会发生很大作用。

　　测试自动化是团队的工作。开始时很艰苦，需要克服很大的痛苦。如果你管理开发或者测试团队，确保在时间、培训和激励上提供了足够的支持。如果你是没有自动化测试的团队的测试人员，开发人员疯狂地编写代码以至于不会停下来考虑测试，那么你会面临很大的挑战。尝试从管理层和团队成员中获取支持以开始小规模的自动化工作。

　　提供并获取反馈

　　反馈是敏捷的核心价值。敏捷的短期迭代可以提供持续的反馈以帮助团队运转正常。测试人员通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供反馈。

　　敏捷方法允许团队获取有关构建中软件的反馈。这是关键。故事代表了测试人员和分析人员向开发人员提供反馈的工作单元。迭代发布有助于团队外部的反馈。大多数敏捷实践都创建了反馈循环使团队应用。

　　测试人员也需要反馈。你怎么知道从客户手里拿到了预期行为的正确例子?你怎么知道编写的测试用例正确地反映了这些例子?开发人员通过查看你收集的例子和你创建的测试能够理解应该编写什么代码吗?

　　一个最有价值的技能是学习如何寻求自己工作的反馈。询问开发人员是否得到了足够的信息以理解需求并且是否能够指导编码。询问客户是否理解质量标准。花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。

　　构建核心实践的基础

　　持续集成

　　每一个开发团队都需要代码管理和持续集成。如果不知道自己在测什么，就无法有效地测试，如果无法配置代码你根本无法测试。所有团队成员需要至少每天一次导入自己的工作。每一次集成必须通过自动化构建验证，其中包括提供软件状态快速反馈的测试。

　　实现持续集成过程应该是软件开发团队中优先级最高的事情。如果团队没有每日构建验证的版本，停止手里的工作，开始构建。就是这么重要。一开始并不要求太高。如果你有很大的系统需要集成，肯定会更具挑战性。通常来说没有那么困难，市面上存在很多优秀的工具，开源的、商业的。

　　测试环境

　　没有可控的测试环境就无法有效地测试。你需要知道部署了什么版本，使用的数据库模式是什么，其他人是不是正在更新，其他进程是否运行在那台机器上。

　　硬件总是越来越便宜，开源软件越来越多。团队必须投资以有效地执行自动化和手动探索性测试。如果测试环境出现问题，赶紧说出来，让全队一起解决。

　　管理技术债务

　　即使优秀的软件开发团队在感觉到时间压力之后，也会忽视重构或者快速解决问题修补缺陷。随着代码越来越混乱和难以维护，更多的缺陷出现，很快团队的速度就慢了下来，因为要解决缺陷才能添加新的功能。团队必须不断地评估技术债务的数量，并努力减少和避免。

　　大家经常说：“我们的管理层不会给我们时间做这些，没有时间重构，日程很紧”。但是，我们可以很容易举一个业务用例来显示增长的技术债务如何耗费公司的成本。衡量代码和缺陷率哪些会导致技术负债变为对底线的影响存在很多办法。仅仅指出不断下降的速度就足够了。业务需要软件开发团队保持持续的生产力。他们不得不减少期望功能的范围以保证足够的时间来进行良好的、测试规范的代码设计和优秀实践，如持续小规模重构。

　　自动化回归测试的良好覆盖率是最小化技术债务的关键。如果缺少，那就在每个迭代中拿出时间来构建自动化测试，规划一个“重构迭代”以升级或添加必要的工具，编写测试并进行重构。在每个迭代中花时间通过测试指导代码，重构必要的代码，添加丢失的自动化测试。对这件工作要重视。长期来看，团队能够变得更快。

　　增量工作

　　敏捷团队能够生产高质量代码的一个原因是他们小规模地工作。故事代表了几天的工作量，每个故事被分解成小增量，按步构建。测试可以针对一小块，并且随着功能聚集再增量测试。

原文转自：http://www.ltesting.net