敏捷中的QA

发表于:2013-2-06 10:09

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:林冰玉    来源:51Testing软件测试网采编

分享:

  敏捷QA与传统测试人员有何不同

  我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:

传统测试人员

敏捷QA

单独的测试团队

多角色开发团队的一员

在开发流程后期才开始测试

测试贯穿于整个开发流中

通常是独立工作

QA和不同角色进行结对

被当作最后也是唯一的质量保证

关注并强调风险

缺乏与业务人员的直接沟通

和业务人员直接沟通

没有机会参与发布计划制定

参与发布计划的制定

  从上表的对比可以看到,敏捷QA是特殊的,主要体现在:

  ● 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。

  ● 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。

  ● 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。

  ● 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。

  ● QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

  这些特殊性对敏捷QA也提出了更高的要求,需要做到:

  ● 具有丰富的产品知识和对用户业务目标的准确了解

  ● 对不同系统和数据库所用到的技术知识的了解

  ● 和不同角色以及客户进行有效沟通

  ● 主动验证质量目标并及时说出自己的想法

  ● 编写测试计划,列出需要执行的活动并进行估算

  ● 自动化测试的能力和对测试工具的基本了解

  ● 在团队内部进行知识分享,协助整个团队参与到测试活动中来

  ● 持续提供并获取反馈

33/3<123
100家互联网大公司java笔试题汇总,填问卷领取~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2023
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号