敏捷测试：反学习的关键
上一篇 / 下一篇 2012-04-10 09:50:48 / 个人分类：杂谈
——作者不明
当QA团队和管理层刚刚开始运用敏捷的实践的时候，他们通常会遇到如何将传统的并且在他们脑海里已经根深蒂固的思想和实践忘掉的问题。
下面是一些从QA的角度出发，在实施敏捷实践之前需要忘却的一些关键点：
●测试团队需要是独立团队，并且能够获得足够的授权才能变得高效
● 如果没有独立的测试策略和测试计划的话是很难进行测试管理的
● 在敏捷sprint中无法与用V模型
● 只有能够发现BUG的时候才能够体现测试的价值
● 测试自动化不是必须的，而且只有在回归测试的时候才需要
● 在一个sprint中是无法进行系能测试等非功能性测试的
● 测试必须按照：计划、规格、执行和完成的顺序进行
● 只要代码能够实现所需的功能，测试团队就不用计较代码的质量
接下来让我们来把上面的这些观点一个一个地审视一遍：
测试团队需要是独立团队，并且能够获得足够的授权才能变得高效
传统上来说，测试团队可能有以下这些组织结构：没有独立的测试团队依靠开发人员进行测试；测试人员在开发团队里面；由公司中专门的部门来进行测试——甚至可能是把测试外包出去。通常来说，测试团队希望能够直接汇报给高级项目主管，而不是报告给开发团队或者TL。他们的初衷是希望在提交BUG的时候不会被TL阻挠。
在敏捷思想中，测试人员必须是团队中的一员。他们应该专注的是，在没人任何技术债务的前提下，在每个sprint结束的时候交付质量过关的可交付产品，从而满足团队承诺的代办列表项的“完成”条件。测试人员要向敏捷团队汇报，而且要对PO和业务需求负责。
如果没有独立的测试策略和测试计划的话是很难进行测试管理的
通常测试策略的文档都是集团级的，公司级的或者是部门级的，至少也是产品级的。很少有人会为一个单独的项目设立测试策略，除非这个项目要持续很多年，所以为某个项目专门设立的策略通常会记录在该项目的测试计划里。
在敏捷项目中，测试方法可以记录在发布计划中，而针对每个sprint的测试活动应该在sprint计划会议的时候记录下来，因此很有可能不需要独立的测试计划。然而，拥有高于项目层面的测试计划是非常有用的，尤其在公司在向敏捷转型的过程中。在测试策略中，可以记录测试的实践、和在集团或者分公司中需要遵循的规则。然后，敏捷团队可以在为项目的发布计划定义的测试方法中应用其中的一些实践。
在敏捷sprint中无法与用V模型
在sprint中，验证和检查都是通过敏捷实践来实现的，例如验证需求已经按照INVEST的形式记录；编写和评审涌现的文档和简单设计；评审视图建模；举行每日站会；进行持续集成；进行代码重构；利用自动化测试进行开发测试和验收测试；增进和PO以及客户的交流。
下图中展示了敏捷中的V模型和传统的V模型关于验证和检查之间的区别：
传统上，独立的测试团队专注于黑盒测试，而对底层的测试不屑一顾。然而，在敏捷项目中，测试人员在自动化开发测试和验收测试中扮演着非常重要的角色。敏捷测试通常是持续性的，而非阶段性的。敏捷的测试人员需要懂得设计以及了解代码层面的知识才能更有效地在一个sprint中进行测试。通常开发人员主导单元测试，而敏捷测试团队参与部分的底层测试以及主导自动化测试。
只有能够发现BUG的时候才能够体现测试的价值
测试的价值不光在于检测出多少个BUG，还在于能够保证可交付的产品的质量是足够好的。敏捷团队需要忘记从前那套以找BUG个数为上的思想。团队可能以为找到越多的BUG就证明绩效越高，结果导致了系统中记录了很多琐碎的BUG。
敏捷测试团队直接对产品待办列表项目的状态负责，也就是说，如果一个代办列表项没有通过测试的话就不能认为其已经完成。敏捷测试团队要多利用各种展示板来展示各个代办列表项的状态。
测试自动化不是必须的，而且只有在回归测试的时候才需要
自动化测试不是可有可无的，相反，自动化测试是非常重要的部分，尤其是需要加快一个产品推向市场的时间的时候。一个以最高速率前行的敏捷团队，会应用持续集成、自动化开发测试、自动化验收测试等工程实践。如果没有了自动化测试和工具的使用，那么团队就不能称之为敏捷团队。
在一个sprint中是无法进行系能测试等非功能性测试的
有时候，有可能无法在一个sprint中完成系统性能测试等非功能性测试。然而，这个问题可以通过在发布计划中加入一个单独的发布sprint来解决。发布sprint可以用来进行非功能性需求的测试，也可以进行一轮验收测试来验证在BUG修复后系统还能正常运行。如果有实施持续集成和自动化测试的话，那么也许就不需要严谨的集成测试了。
测试必须按照：计划、说明书、执行和完成的顺序进行
虽然计划、说明书、执行和完成都和敏捷测试息息相关，但是我们需要记住的是敏捷测试是一个持续性的过程，而不是阶段性的。例如，当一个待办列表项已经标志为完成的时候，很有可能另外一个待办列表项还处于编写说明书的阶段。有些团队会在把当前待办列表项的测试用例都用自动化实现了以后才将该项标识为“完成”。
不需要为已发现的BUG写新的测试用例
在传统上，如果测试团队在探索性测试的过程中发现了BUG，团队并不会回过头来为这个BUG创建一个新的测试用例。不这么做的一个关键原因是，改变测试文档的流程需要改变计划好的测试基准。然而，适应变化正式敏捷框架的一个基础组成部分。在敏捷测试中，如果一个BUG没有对应的测试用例，那么就要为这个BUG编写新的测试用例，然后再把新的测试用例添加到自动化测试中。
只要代码能够实现所需的功能，测试团队就不用计较代码的质量
这个观点和上面的“独立的测试团队不需要做白盒测试”是相关的。以前独立的测试团队只专注在黑盒测试，只要代码能够实现需要的功能，代码质量就不是他们所关心的问题。但是，如果测试团队能够在测试或者验证阶段就能够找到代码级别的技术债务的话，这对整个项目所带来的价值是相当可观的。这也是敏捷测试人员需要改变的关键观念之一。
测试流程改进模型并不适用于敏捷测试
实际上，我们确实有办法能够用标准的行业模式来衡量和改进敏捷测试。测试流程的改进方法，如TPI NEXT，主张在敏捷环境中利用对关键领域的优先级排序来对业务驱动的测试流程进行改进。这就是把敏捷的原理和专门的领域对应起来的敏捷测试思想。
结论
虽然，进行测试的具体方法和在瀑布式、迭代式和敏捷中在原则上没有很大的区别，但是在敏捷的思想中包含了很多新的方法另团队能够更高效地达到期望的结果。敏捷本身更多的是敏捷的实践，而不是流程。
TAG:
我的栏目
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | |||||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | |||
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | |||
| 16 | 17 | 18 | 19 | 20 | 21 | 22 | |||
| 23 | 24 | 25 | 26 | 27 | 28 | 29 | |||
| 30 | |||||||||
我的存档
数据统计
- 访问量: 3274476
- 日志数: 1640
- 建立时间: 2011-12-07
- 更新时间: 2019-12-24
