2019-11-20 09:34:20 qq_44614026 阅读数 43
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10391 人正在学习 去看看 CSDN讲师

本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 2)。每天早上十点,在固定的时间和会议室里面,团队会举行站立会议。这时候,团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务,所遇到的困难和当天要完成的任务。同时,项目经理更新 Sprint Backlog(一张制作精良的 Excel 表格),并及时解决每个人所提出的问题。

在这里插入图片描述

测试人员需要具备的素质

测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号:测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求:

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力 -> 软件质量工程师

总结而言,有三方面的基本素质要求:代码编写(Coding)、测试 (Testing) 和分析 (Analysis)。

在很多其他的开发流程中,各个测试阶段对测试人员的能力有所不同;有时候侧重分析(比如系统配置测试),有时候侧重代码编写 ( 比如功能测试 )。但是,在敏捷开发流程中,测试人员需要结合这三方面来开展工作,只有这样才能真正反映敏捷测试的本质:简单而高效得应对变化。

测试人员的主要职责

在敏捷软件开发中,测试人员的职责有三个主要方面:

定义质量 (Define Quality)

这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流,从自己的经验出发,共同为产品功能制定质量要求。

交流缺陷(Communication)

敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能,测试人员应该抓住细节,寻找设计中的“missing door”;另外,开发人员使用单元测试来保证产品的基本质量,测试人员可以使用验收测试(Acceptance Test)来鉴定客户需求与实际成果之间的不一致性。

及时反馈 (Feedback):

敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。
这样一来,团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话,敏捷流程要求每天汇总质量问题。在我们的项目中,内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。
另外,我们的测试框架提供自助测试 (Self-assistant Test):通过点击测试用例列表中的某个具体用例,开发人员不需要中断测试人员的工作就可以重现缺陷。

敏捷开发中QA的职责之敏捷中的QA

QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst),主要基于以下几个方面的原因:

质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更恰当;

质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中的QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;

质量分析师更重视业务价值,关注业务价值的分析。

QA,质量分析师,显然与测试有关。敏捷中的QA,也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试,要求尽早测试、频繁测试,以及时提供反馈。敏捷测试要求团队对软件产品的质量负责,而不是某个带有QA头衔的特殊人员。 敏捷中的QA可以是参与敏捷测试的所有团队人员,而并不一定是特定的专职的测试人员。

这听起来是不是有点特别?跟传统开发模式下的测试人员是不是有些不一样?别急,我们先来看看敏捷中的QA是如何进行日常工作的。

敏捷QA的日常活动

从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示:

在这里插入图片描述

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。

在这里插入图片描述

在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。

在这里插入图片描述

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认

  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算

  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷

  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈

  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试

  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。

在这里插入图片描述

  • QA与业务分析人员结对:通常在业务分析师分析用户故事的时候,QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对,QA能够更好的理解领域知识,从而有利于定义合适的测试用例;QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。

  • QA与开发人员结对:QA和开发人员分别能给团队带来不同的技能集,认识到这一点很重要。
    作为一个团队,最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。
    通常在实现测试自动化的时候,QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高,有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分,而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。
    另一方面,QA通过与开发人员结对,编码能力也会相应有所提高,而开发人员通过与QA结对,测试意识也会增强,更有利于编写质量较高的产品代码,更有利于形成全功能团队。

  • QA与客户结对:客户是业务领域专家,通过与客户结对,QA能够更好的从终端用户的角度理解系统,从而定义或者增加更多的端到端的测试用例;
    一旦QA理解了领域知识和终端用户的观点,其业务价值分析能力会有所提高,在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段,QA通过与客户结对,帮助客户熟悉使用系统,在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同,以及敏捷测试对QA的要求有哪些。

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

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

传统测试人员 敏捷QA
单独的测试团队 多角色开发团队的一员
在开发流程后期才开始测试 测试贯穿于整个开发流中
通常是独立工作 QA和不同角色进行结对
被当作最后也是唯一的质量保证 关注并强调风险
缺乏与业务人员的直接沟通 和业务人员直接沟通
没有机会参与发布计划制定 参与发布计划的制定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 持续提供并获取反馈

大家熟悉的测试工作(也是传统的瀑布式),是接到项目后参与需求评审,然后根据需求文档写写用例和准备脚本,等开发提测之后正式开始测试、提bug、回归,测试通过后就结束了,项目交给运维上线,之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么问题,但缺点是:

  • 测试过程是在一定时间间隔内发生的,测试人员必须等待产品完全构建才能找到错误和故障。不可否认,花费的时间超过了可以商定的时间;
  • 测试同学非常被动:当需求质量、开发质量差的时候,你只能被动接受,结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期;
  • Bug的成本在后期是非常高的,需要花费很多精力和时间去修复。甚至严重的情况是产品都不能按时发布,导致很大的损失。
  • 很有可能一个线上问题裸奔了几个月,最后是业务方先发现才排查到是Bug导致,由于影响时间过长给公司造成的损失巨大,还被质疑为什么这么明显简单的问题上线之后没人发现。
2019-09-02 15:52:34 newdreamIT 阅读数 43
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10391 人正在学习 去看看 CSDN讲师

在敏捷开发流程中,测试不再是瀑布试开发流程的一个环节,而是全程参与整个开发流程。通过各种方式来保证产品的质量,无论是原则中的“频繁交付”,还是对“可工作的软件”的度量,或是敏捷开发实践中的“测试驱动开发”,“行为驱动开发”,都离不开测试的支持。 当然,敏捷测试对测试人员提出了更高的要求,对测试人员来说也是新的挑战。

敏捷测试人员的定义:专业的测试人员,适应变化,与技术人员和业务人员展开良好的协作,并理解利用测试记录需求和驱动开发的思想。敏捷测试人员往往具有优秀的技术能力,知道如何与他人合作以实现自动化测试,同时也擅长探索性测试,他们希望了解客户在做什么,以此更好地理解客户的软件需求。

在这里插入图片描述

既然是测试驱动敏捷项目,那么很显然反馈在敏捷团队中占据重要的地位。

敏捷方法中,测试人员如何在其中体现价值?

1、先在需求讨论上,测试人员可以站在客户角度上来阐述自己的观点,和产品人员、开发人员等进行充分的交流和讨论,使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

2、开发过程中,测试人员不仅扮演“用户代表”角色,而且可以及时提供更全面的质量反馈,包括代码质量、接口一致性等。测试人员不写代码,可以参与代码复审(code review),将质量问题及时提交给项目组,保证在产品构造的整个过程中质量受到足够的关注,提高质量改进的持续性和可视性。

3、试人员还是可以参与单元测试。即使单元测试由开发人员做,测试人员可以推进开发人员进行单元测,检查单元测试状态,如确保单元测试达到80%以上覆盖率,以及帮助开发人员开发出具有良好可测试性的代码。

4、使在敏捷方法中,集成测试、端到端(end-to-end)测试、性能测试等是不可少的。因为在敏捷方法中,往往将一个大的系统开发分解成多个小的子系统(模块/组件),集成测试和端到端(end-to-end)测试显得更重要。测试人员在功能测试上工作量会降低,但在这些测试上发挥更大的作用。

5、着迭代的不断深入,回归测试的工作量很大,这也是测试人员的用武之地。 测试人员可以针对稳定的产品特性开发自动化测试脚本,这也是一种持续的努力,使回归测试自动化。

6、试人员对缺陷进行分析,总结出一些规律,帮助开发人员建立良好的习惯,改进代码的质量。

7、用敏捷测试,不要再写几十页的测试计划书,而是在每个迭代周期,写出一页纸的测试计划,将测试要点列出来。

8、敏捷测试中,可能不需要测试用例,而是针对use case 或user story直接进行验证,并进行探索性测试。而节约出来的时间,用于开发原有功能的自动化测试脚本,为回归测试服务。自动化测试脚本将代替测试用例,成为软件组织的财富。

9、寻找工具、技能或者实践以实现更大的价值。敏捷开发的短期迭代更易于尝试新事物,以验证是否值得长期采用。学习新技能和提高专业技能水平对敏捷测试人员非常重要。可利用各种免费的资源提高专业技能。

10、团队文化贯彻于敏捷测试理念。当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试自动化,测试人员就会获得全新的视角。自动化测试很困难,但是当整个团队都在为此努力时就会简单得多。当大家具有多重技能和多层次视角时,任何测试问题都会更容易解决。

新梦想总结:对于一个敏捷测试人员,要乐于收集和分享信息,与客户或者产品负责人协作以帮助他们充分展示自已的需求,从而得到他们需要的功能,同时向所有人提供项目进展的反馈。乐于学习新技能和面对新挑战,不会仅仅局限于测试问题。这不只是测试人员的特征,所有敏捷团队人员都应具有。一名优秀的测试人员并不惧怕参与一场设计讨论,提供有且于测试性或者构建更良好方案的建议。

2015-05-22 00:01:31 u011790275 阅读数 2589
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10391 人正在学习 去看看 CSDN讲师

敏捷开发下,开发人员应该多花点时间,好好的深读这几本书……

光只是学会程序语言、单元测试框架对提升开发效率与产品质量,不仅是毫无帮助,反而会因滥用单元测试与无架构可言的代码,而对开发的效率与产品的质量,产生莫大且永恒的伤害。

这几本书,将能开启咱们大家的智慧;使咱们能从管理产品的复杂度着手,不仅使产品代码可适应变化,更可使单元测试代码可适应变化。

从这些书所获得的知识,是敏捷开发下,开发人员所必需具备的基本功

基本功具备了,敏捷开发下,开发人员最重要的是要能拥有决策的能力;产品的任何部份都设计,和产品都没设计,或者,产品的任何部份都单元测试,和产品都没单元测试,都是会对产品质量造成极大的伤害的。

所以,在敏捷开发下,能否高效的开发出产品,不在于你,做了多大而全的设计,也不在于你,写了多高覆盖率的单元测试。而是完全取决于你,能做出多少有价值的决策

所以,在敏捷开发下,咱们大家应将脑袋多多用于 “思考”,千万别只是用来 “生产”。




2010-09-24 16:33:00 bihailan123 阅读数 659
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10391 人正在学习 去看看 CSDN讲师

 今天浏览51testing,有个讨论是“敏捷开发中,测试人员的工作成绩如何体现”,想想我们公司的项目不就是敏捷开发吗?需求不确定,经常改,做的差不多了,产品就交付,用户再提意见,再修改。看到有个人的回答比较好,引入过来,怕以后找不到了。

敏捷方法在软件开发中受到青睐,特别是在互联网应用服务系统的开发中,越来越多的公司采用敏捷方法,包括XP、Scrum、Lean、Crystal、FDD等。具体的敏捷方法在操作时有一些区别,但基本思想是一致的,如客户至上、拥抱变化、缩短迭代周期、自我组织等。在敏捷方法中,流程相对灵活,强调沟通,通过充分的沟通来及时解决问题,由于沟通充分,文档不是很重要,而且有可能不采用Word等独立的文件格式,而是采用Wiki、空间等web内容方式。在敏捷方法中,需求变化比较快、产品开发周期很短(一、两周),给软件测试带来很大的挑战!例如,功能测试的自动化实现就比较困难,没有足够时间开发自动化测试脚本,要花大量时间讨论产品特性,及时进行产品的验收测试。自动化测试,更多的是在单元测试这个层次上实现。而单元测试自动化、持续集成等一些关键实践,开发人员能发挥更大的作用,而测试人员难以很好地发挥作用。在敏捷方法中,开发人员的主导作用更明显,讨论需求、实现需求,再修改需求、再实现、再重构,不断完善产品,测试人员容易边缘化。甚至在Crystal方法中,可以不需要测试人员,开发人员能承担所有技术性的工作。
在敏捷方法中,测试人员的价值又如何体现?

1、首先在需求讨论上,测试人员可以站在客户角度上来阐述自己的观点,和产品人员、开发人员等进行充分的交流和讨论,使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

2、在开发过程中,测试人员不仅扮演“用户代表”角色,而且可以及时提供更全面的质量反馈,包括代码质量、接口一致性等。测试人员不写代码,可以参与代码复审(code review),          将质量问题及时提交给项目组,保证在产品构造的整个过程中质量受到足够的关注,提高质量改进的持续性和可视性。

3、测试人员还是可以参与单元测试。即使单元测试由开发人员做,测试人员可以推进开发人员进行单元测,检查单元测试状态,如确保单元测试达到80%以上覆盖率,以及帮助开发人员开发出具有良好可测试性的代码。

4、即使在敏捷方法中,集成测试、端到端(end-to-end)测试、性能测试等是不可少的。因为在敏捷方法中,往往将一个大的系统开发分解成多个小的子系统(模块/组件),集成测试和端到端(end-to-end)测试显得更重要。测试人员在功能测试上工作量会降低,但在这些测试上发挥更大的作用。

5、随着迭代的不断深入,回归测试的工作量很大,这也是测试人员的用武之地。 测试人员可以针对稳定的产品特性开发自动化测试脚本,这也是一种持续的努力,使回归测试自动化。测试人员对缺陷进行分析,总结出一些规律,帮助开发人员建立良好的习惯,改进代码的质量。

而且:
在敏捷方法中,我们也要采用敏捷测试不要再写几十页的测试计划书,而是在每个迭代周期,写出一页纸的测试计划,将测试要点列出来。
在敏捷测试中,可能不需要测试用例,而是针对use case 或user story直接进行验证,并进行探索性测试。而节约出来的时间,用于开发原有功能的自动化测试脚本,为回归测试服务。自动化测试脚本将代替测试用例,成为软件组织的财富。
所以:
敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试)  + 原有功能的自动化测试 (回归测试)
    理想情况下,测试人员具有很好的编程能力,可以和开发人员进行角色互换。在当前版本开发(/迭代周期)中担任测试人员角色,在下一个版本开发(/迭代周期)中担任开发人员角色,而开发人员则担任测试人员角色,让开发人员深刻地理解用户的需求角度来考虑系统功能的设计,这样会更好地保证产品的质量,沟通的障碍也会消除,开发的效率会有很大的提高。这也是对测试人员的一个挑战。
    敏捷测试也是一个持续测试的过程,而这持续测试的基础是具备一个灵活的、开放的自动化测试框架。项目采用敏捷方法,要获得成功,项目组中每个人都有很强的质量意识,具有质量的主人翁精神,特别是开发人员,每时每刻提醒自己——“质量是构建出来的”,与客户或产品设计人员进行充分沟通,遵守高度一致的质量标准。

http://www.51testing.com/html/21/318121-217281.html

2012-04-05 12:27:12 iteye_4001 阅读数 14
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10391 人正在学习 去看看 CSDN讲师
敏捷开发的目的是在保证开发质量的前提下提高开发效率。敏捷开发需要有两个前提,团队人员对所应用的技术有比较全面深入的了解;开发及测试人员对软件的业务逻辑有全面深入的了解。换句话说,一个项目或者一个产品发展到一定阶段之后,可以根据实际情况逐步过渡敏捷开发的方法上来。
一般来说,敏捷开发有以下特征:
1、团队规模比较小,10人左右是比较合适的。
2、团队内部强调沟通,包括经常性的standup meeting和就某个技术、需求问题的讨论,讨论方式包括面对面、电话和邮件。
3、文档特别是开发人员撰写的文档大幅减少,如果只是在现有技术框架下添加一个新的业务功能,甚至不需要标准的设计文档和功能描述文档,当然详细的使用手册或者online help还是需要的。
4、单元测试以及UI自动测试的应用,可以显著增强软件质量。特别是对于开发周期比较长的软件来说,自动测试可以大大减轻QA人员进行回归测试的工作量。

敏捷开发,SIT测试

阅读数 252

没有更多推荐了,返回首页