导语 之前提到,笔者刚换了一家公司,说一下笔者在开展工作过程中遇到的一些问题。 先介绍一下公司现在的情况。 目前产品的文档几乎没有,研发人员+测试人员中精通全部业务的没有,每个人都只了解自己负责的那一小块。 版本送测后,测试人员没有编写测试计划,也没有设计测试用例,都是靠个人能力进行测试。 每周都要进行新版本发布,而且经常有为了客户要求,版本在存在较大风险的情况下紧急上线。有时候,领导也会因为一些关键需求要求研发中心一定要按规定的时间上线。之前研发总监还有北京的测试经理跟领导说,有什么限制,
『阿常你好,请问在敏捷开发的项目中,你作为项目中唯一的测试人员如何制定相对符合的测试计划推动项目进程呀 ?』
本文摘取陈晓鹏(晨小菜公众号)敏捷/测试/DevOps专家 随着这几年敏捷概念和方法的流行,越来越多的组织和项目选择了敏捷开发模式。那么对于测试人员来说,究竟敏捷测试与传统测试有什么区别?测试人员在一个敏捷项目中需要如何转变才能适应当前这种流行的测试模式呢?请看下文介绍。
正在写DevOps培训总结的我看到了Rick Chen的文章,深表赞同,转发一下!原文地址
早在2009年,Lisa Crispin和Janet Gergory就写了一本书《Agile Testing: A practical Guide for testers and Agile Teams》,国内在2010年出了它的中文版本,在第1章就论述了敏捷测试的定义,侧重从测试的敏捷形式和“敏捷测试”的实践等来彰显敏捷测试,对敏捷测试和传统测试的区别进行了分析(虽然作者把传统测试局限于瀑布模型,这显然是不对的),让我们看到一些敏捷测试的特点,如图1所示。但作者也承认“敏捷测试对不同的人意味着不同的含义”。
敏捷的原则:尽早地给客户持续交付 有价值的 成果物。不断地反省调整、最有效的解决方案是面对面沟通。
前言 面试过几个应聘测试主管的应聘者,问到一个问题“你会如何接手一个新测试项目,你首先会做什么事,问哪些问题?”得到的答案几乎千篇一律:了解需求,做计划,然后设计用例,执行用例,最后提交报告……这样的答案,不能说错,但却不是我想听的。我想听到一些不一样的东西,准确的说是应聘者自己总结和思考过的东西,而不是网上流行的固定的那一套流程。 今天分享的主题是如何管理一个测试项目,跟上面的话题没有直接关系,不过也有借鉴价值。 管理一个测试项目大致可以分为事前、事
顾翔老师开发的bugreport2script开源了,希望大家多提建议。文件在https://github.com/xianggu625/bug2testscript,
在敏捷开发流程中,测试不再是瀑布试开发流程的一个环节,而是全程参与整个开发流程。通过各种方式来保证产品的质量,无论是原则中的“频繁交付”,还是对“可工作的软件”的度量,或是敏捷开发实践中的“测试驱动开发”,“行为驱动开发”,都离不开测试的支持。 当然,敏捷测试对测试人员提出了更高的要求,对测试人员来说也是新的挑战。
敏捷开发是一种以人为核心、迭代、循序渐进的软件开发方法。它强调团队合作、客户需求和适应变化。敏捷开发并不寻求在开始阶段就定义所有事情,而是寻求灵活地响应变化。敏捷开发被视为一种更加高效、灵活和可持续的软件开发方法,适用于现代快速变化的企业环境。
敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。借鉴一种新的模式的时候,最好能够批判性的吸收其精华的部分,不能全部照搬,照搬了反而会出问题。
我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的公司,被迫式的接触了许多“敏捷开发”,随着项目经历越来越多,慢慢的就开始有了更新的认识和想法。
瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型,瀑布式开发是一种老旧的计算机软件开发方法。瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
值得注意的是,YesDev中所定义和提倡的项目,是指在一定时间周期内完成的有限需求、任务和问题的集合,对应敏捷开发中的一次迭代或Scrumn的一个Sprint。除此之外,其他事务或技术专项也可以通过项目来进行统一管理和流转。简而言之,项目可以是:
这是通过一种敏捷的做事方法,可以让团队协作更紧密、工作效率更高,确保以可持续的速度频繁地交付客户所期望的业务价值。
1、瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型, 瀑布式开发是一种老旧的计算机软件开发方法。 瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。 步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。
敏捷软件开发,又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法,是一种能应对快速变化需求的软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发过程中人的作用。
引言:敏捷绝非某一种特定的开发方法,它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。
DevOps是当前软件行业最热门的话题,无论是互联行业,还是传统行业,大家都在拥抱DevOps,享受引入DevOps后带来的团队效能提升。但是也有不少的团队对DevOps的理解还存在误区,导致在实践过程中困难重重,甚至最终失败,总结失败的原因不外乎以下几点:
由于书是由英文书籍翻译,读起来会难免拗口,本次分享是由《敏捷软件开发》结合网上相关资料总结而成。
随着测试行业的进步,测试流程也在飞速的发展。最开始工作接触的就是瀑布模型,虽然测试工作做了很长的时间,在一家传统公司,做着传统的业务,测试流程并没有跟着行业发展而继续发展。为了解,也为不被IT行业所淘汰掉,机缘巧合开始学习敏捷 什么是瀑布模型,瀑布模型的特点 需求固定,反对更改需求 流程固定,开发测试流程清晰,设定具体流程的时间节点,比如开发多少周,测试多少周等等 📷 瀑布模型问题 📷 开发之前需要跟客户沟通,获取详细的需求 根据需求编写需求文档,编写测试计划...等等一系列文档 保证在整个开发过程
探索式软件测试是一种强大的黑盒测试思考方法,但却被广泛误解。在某些情况下,它可以比自动化测试更加有生产力。它是一种经过深思熟虑的测试方式,没有测试脚本,可以使你的测试超出各种明显已经测试过的场景。
很多公司请几个敏捷教练建立流程,把会议室的椅子都搬走宣布从今以后大家站着开会了,使用敏捷管理工具建立迭代、建需求、分任务,可是这真的就意味着敏捷了吗?
敏捷开发流程详解 1 敏捷开发流程 ü 敏捷软件开发核心是迭代式开发,增量交付。 ü 每一次迭代都建立在稳定的质量基础上,并作为下一轮迭代的基线,整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表(外部或内部)验收,提供需求是否满足的反馈。 ü 迭代型的方法就是将整个软件生命周期分成多个小的迭代,每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成,每一次迭代都可以生成一个稳定和被验证过的软件版本。 ü 迭代建议采用固定的周期(1-4)周,可以每个迭代周
现在开发软件都讲敏捷开发,何为敏捷开发?敏捷开发是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重做为软件开发中人的作用。但是现在敏捷开发又好几种方案,如:TDD、BDD、DDD 与 ATDD。
在我们开始尝试为大家描述软件测试工作的多种可能性之前,先来看看在现在所知最近代的开发模式中,测试人员还会继续存在吗?因为如果连测试工作本身都不存在了,我们也没必要进行后续的讨论了。 很多做测试的朋友问过这样一个问题:“现在敏捷开发模式中,自动化测试那么流行,而且连开发人员都开始做测试了,是不是以后就没有测试人员了?” 其实我在这里可以肯定的告诉大家现实并不是这样的。 首先我们需要讨论的是分工的问题。人类的工业化生产最初也是不分工的,但随着生产技术的复杂度提升,以及对于生产效率的更高要求,产生了分工;同样对于
【软件开发的周期:、需求分析、设计、实现、测试、安装部署、运行维护】 【软件测试的周期:、需求分析,测试计划,测试设计/测试开发,测试执行,测试评估】
软件工作的范围不仅仅局限在程序编写,而是扩展到了整个软件生命周期; 【软件开发的周期:、需求分析、设计、实现、测试、安装部署、运行维护】
YesDev是一款简易强大的研发协同工具,可以帮助每一个团队,提升产品研发效能,结合敏捷开发和DevOps双引擎,实现研发全流程扁平化协作和闭环管理,解码研发“黑洞”。它的作用和价值是帮助每一个产品研发团队,持续、稳定、高效交付更有价值的软件!
软件测试:为了发现软件产品中的各种缺陷,而对软件产品进行验证和确认的活动过程,此过程贯穿整个软件开发生命周期。 简单的说,软件测试是以发现错误为目的而执行的一个程序或系统的过程。
探索式测试(Exploratory Testing,简称ET)是一种自由的软件测试风格,强调测试人员同时展开测试学习、测试设计、测试执行和测试结果评估等活动,以持续优化测试工作。
随着敏捷软件研发过程的引入,敏捷测试也开始成为研发团队的重点关注对象。在行业内,有些企业正在做敏捷测试的尝试,有些也取得了不错的效果。
最近在给一位企业老板介绍YesDev时,PPT才讲了几分钟不到,然后稍微看了一下界面。这位老板就说:“没错!这就是我们一直想要的项目管理工具。我们做产品经理培训已经很多年,擅于前端抽象客户需求的分析和概要设计。但对于项目研发的实际管控,以及怎么把工时关联到需求,没找到合适的工具。自己研发,又划不来,也没这个时间精力”。
本文从以下九大功能对各个工具进行对比:测试需求管理、测试用例管理、测试套件管理、测试版本管理、测试计划管理、测试执行管理、缺陷管理、发布管理和分析报表。
今天继续和大家聊聊管理岗位方面的知识,在这篇文章中,我将先分析这个问题的意图和考察点,再给出当时的回答,以及思考后的回答,并说说还可以改进的点,希望能够对其他有志于从事测试管理岗位的同学有所帮助。
在软件工程中,测试和开发是两个核心的环节。这两个环节相互依赖,相互影响,构成了软件产品的整个生命周期。然而,在近年来,随着敏捷开发、持续集成、持续交付等先进开发模式的普及,一个新的角色——测试开发工程师,逐渐进入了我们的视野。他们的工作似乎同时涉及到了测试和开发两个领域,那么,测试开发是测试还是开发呢?
简介 工欲善其事,必先利其器。测试管理平台就是测试过程中的“器”,它是贯穿测试整个生命周期的工具集合,它主要解决的是测试过程中团队协作的问题,比如缺陷管理、用例管理、测试任务管理等。目前市面上比较流行的测试管理工具有QC、 Mantis、 BugZilla、TestLink、Redmine等。有开源软件,也有商业软件。这些软件的各自侧重点不同:比如Mantis、BugZilla偏重缺陷管理,TestLink则偏重测试用例管理,QC则更加全面,Redmine项目管理的概念又更强一些。下表从以下九大功能对各个工
作者:solinazhao 简介 测试管理平台是贯穿测试整个生命周期的工具集合,它主要解决的是测试过程中团队协作的问题,比如缺陷管理、用例管理、测试任务管理等。 目前市面上比较流行的测试管理工具有QC
元年科技,深耕中国企业服务20年,服务上千家大型企业集团,是国内管理会计、财务管理等专业领域的领导者,对金融、地产、零售快消、装备制造等行业有深刻的洞察和丰富的经验。 本文整理自元年科技研发流程总监周晓芳在TAPD思享汇上的分享,为大家分享元年科技如何通过TAPD标准化、规范化研发流程,如何通过TAPD量化质量管理,高效交付业务价值。 Part 1 元年科技敏捷项目管理背景和管理思路 随着企业数字化转型逐渐深化发展,元年科技的客户规模越来越大,对团队持续交付提出了更高的要求,元年科技开始在研发流程上面临以下
如今,软件交付的迭代速度越来越快,我们拥有为数不少的技术框架、开发工具、Web服务、自动化工作流等,为了推动更加收用户青睐的软件和服务。
世界正在见证敏捷方法在软件开发中的现在的流行。而软件测试也需要一种新的软件测试方法,该方法必须与快速发展的哲学敏捷开发保持一致。测试自动化并不是为敏捷团队服务而生的,
现在DevOps已经成了一个非常热门话题,但是又有谁真正理解了DevOps,可能少之又少。上周聆听了茹炳晟老师的在线课程,通过一张图我才发现真正理解了DevOps。
本文主要介绍了在敏捷开发流程中,如何在每个Sprint内进行交付物的定义和交付,包括燃尽图、冒烟测试、测试用例、测试报告、功能测试、测试计划、测试Bug列表和压力测试报告等交付物的详细定义和说明。同时,文章还提供了相关的参考和备注信息,以帮助读者更好地理解交付物的定义和说明。
在探讨测试左移和测试右移之前,我们先来聊一下传统的软件测试流程(瀑布模型)和目前很多公司在用的测试流程(敏捷模型)的区别。
领取专属 10元无门槛券
手把手带您无忧上云