AgileTest
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Agile testing(敏捷测试)基本上是伴随着敏捷开发的概念成长起来的,但在受关注程度上,远远不及敏捷开发本身。自然,开发队伍从数量和活跃度上来讲大于测试队伍,是其中的一个原因;除了这个原因之外,“敏捷测试究竟如何在项目中发挥作用”这个问题可能也是导致敏捷测试概念的流行度远远不如敏捷开发的原因之一。
敏捷测试和传统测试观点最大的不同在这几个地方:
1.敏捷测试并不倾向于严格区分开发和测试角色,全体工程师对于质量具有同等的责任,
测试任务由开发和测试工程师共同完成;
2.敏捷测试的迭代周期很短,为了在很短的迭代周期中完成测试任务,要求建立“足够好”
的验收测试,建立足够的自动化测试;
3.敏捷测试不严格依赖于文档(需求,设计等),测试角色必须和其他成员以及客户有
良好的沟通,以保证建立的质量标准符合用户的需求,以及能够使用项目中的相关知识建立合理的测试框架;
4.关于底层测试和关于代码质量是敏捷测试中的一个非常好的实践。
其中,对传统测试观点最大的冲击是第1和第3点,打破测试角色和开发角色之间的严格限定,用沟通而不是文档作为建立测试的基础,这些的确会让一个熟悉传统测试环境的测试工程师骤然间不知所措。
敏捷测试的要点之一就是,不依据于角色而是依据于任务来考虑整个开发过程中的测试。但是,对一个开发组织来说,组织中一定存在开发工程师和测试工程师的角色划分,作为一个敏捷团队中的测试工程师,他的主要工作职责是什么呢?或者说,他可以在哪些工作上发挥自己的作用呢?
敏捷过程中与测试相关的任务很多,概括说来有如下一些:
1.建立不同级别的测试验收标准(也就是test suite),包括单元测试、集成测试、系
统测试等各个层面的验收标准;
2.推动整个组织的质量文化,保证整个组织的成员在质量责任与目标方面达成一致;
3.通过技术或是管理的手段,保证产品、代码具有良好的可测试性;
4.通过自动化测试手段缩短每个产品发布周期中测试所需的时间;
5.与客户沟通确认客户可接受的软件质量标准,并建立针对此标准的验收测试;
6.深入了解应用系统和业务需求,通过探索性测试方法设计有效的测试用例,发现产品
中的缺陷;
7.建立对整个团队可见的质量度量体系,保证整个团队能够随时看到产品的质量度量值。
这些工作都可以是敏捷团队中测试工程师角色的工作任务,但显然,在现实中,不太可能要求所有这些工作都由测试工程师来承担─同时,让测试工程师承担全部这些工作任务也并不合理,某些工作由开发工程师角色,或是由开发工程师和测试工程师共同承担更为合理。
接下来,把列出的这7项工作更详细的划分成“测试工程师必须完成的工作”,“测试工程师需要去推进的工作”,以及“能为项目带来巨大价值的工作”。
1.测试工程师必须完成的工作:
1.与客户沟通确认客户可接受的软件质量标准,并建立针对此标准的验收测试;
2.深入了解应用系统和业务需求,通过探索性测试方法设计有效的测试用例,发现
产品中的缺陷;
3.建立系统和用户验收级别的测试验收标准;
4.通过自动化测试手段缩短每个产品发布周期中测试所需的时间;
2.测试工程师需要去推进的工作:
0.推动低层次测试(单元测试和接口级别的测试)的进行。低层次是测试对于需要
快速发布的敏捷开发来说至关重要,但在大部分国内的软件组织中,开发测试都
需要经过不断的推动才能被最终执行下去,测试工程师具有相关的测试技巧,
并且能够用翔实的统计数据表明低层次测试的必要性,是最好的推动低层次测试
的人选;
1.推动整个组织的质量文化,保证整个组织的成员在质量责任与目标方面达成一致。
这一点对于敏捷组织来说也是至关重要的;在许多传统的软件开发组织中,经常
能看到开发和测试之间的扯皮,针对一个遗漏的缺陷,大家考虑第一件事不是
如何去修复,如何去防止,而是首先“追究责任”─在敏捷过程中,需要一个非常
不同的环境:也即,质量责任是由所有工程师共同承担的,对于出现的问题,
重要的是解决和预防。
3.能为项目带来巨大价值的工作
0.建立对整个团队可见的质量度量体系,保证整个团队能够随时看到产品的质量度
量值。保证产品质量度量的可见可以让整个团队清楚的看到我们现在正在工作的
产品与我们期望交付的产品在质量上还有多大的差距,这样整个团队可以以质
量度量作为指示,集中精力工作在这些差距上,从而可以尽快的发布“可工作”
的产品。“验收测试的通过度”,“单元测试的通过率”,“功能完成情况”等等项
目都可以是质量度量中的度量项。
1.通过技术或是管理的手段,保证产品、代码具有良好的可测试性。良好的可测试
性对于产品的维护,自动化测试的进行都是非常有利的─我觉得,甚至可以武断
的说,如果一个应用系统没有良好的可测试性,就很难期望可以在该项目上设
置良好的测试框架。测试工程师一般不参与具体的设计工作和代码实施工作,但
测试工程师可以推动开发工程师在设计和实现时尽可能的考虑可测试性设计,
另一方面,测试工程师也可以通过测试覆盖率这个质量及时发现应用中可测试性
不强的地方,推动开发工程师的改进。
当然,要完成这些工作,和传统的QA工程师相比,敏捷过程对测试工程师提出了更好的技能上的要求。
一个敏捷项目中的测试工程师应该具有这样一些技能:
1.良好的沟通和协作能力;
2.良好的设计和代码能力,至少可以和开发工程师在同一水平上讨论具体的设计和代码
实现;
3.快速学习和总结的能力(运用探索性测试发现缺陷);
4.对自动化测试有深刻的理解(至少要能清楚的认识到自动化测试不等于UI自动化测
试,也不等于用自动化测试工具进行录制和回放);
5.快速的风险分析和判断能力(在许多情况下都不会有足够的时间开展full regression,
如何判断风险和决定相应的对策至关重要)。