测试人员遇到不断变化的项目需求该如何应对?

需求频繁变更这个产生的主要原因是:

1.前期需求调研工作没有做到位,在需求调研时没有真正深入了解用户需要什么东西?用户做这个东西的目的是什么?为什么要这么做?

2.项目经理对项目掌控力度够,在项目的需求一定情况下,没有采用集中变更或者分阶段变更;

3.客户在最开始时自己也没搞清楚要做出什么样子?随着系统的成型上线,提出一些新想法等导致需求变更。

4.客户就是上帝,所以有些变更是必须的。

测试人员如何面对变更?

1. 协调制定变更规范,比如说每次需求人员都会发出变更邮件,这样可以作为开发人员和测试人员工作的依据。如果这点也做不到的话,建议把发给开发人员的变更信息同时抄送给测试人员,使测试人员和开发人员保持信息基本一致;

2. 了解需求变更的范围,及时整理并记录测试需求变更,在每次不论通过何种方式得到需求变更信息,都要及时记录,并及时通知相关人员确认;

3. 确保团队明白需求变更所涉及到的风险,特别是在迭代后期阶段。

4. 如果可能,通过协商或者实行下一个迭代的更改,将需求变化控制在一个很小的幅度;

5. 在每次测试前,一个比较详细的测试测试任务列表单,同时注明本次测试的侧重点【变更哪些需求、新增了哪些需求】,找相关人员确认

6. 每天保持记录测试工作日志,主要包括【1.测试中遇到的问题及其解决方式(可以形成测试知识库)、2.记录测试任务及其工作成果(主要是记录今天做了什么?成果是什么?以便以后总结)、3.记录测试进度(记录个人或者团队的工作进度情况;这样时间长了就基本可以评估测试那个模块,那个流程,哪一类问题需要多长时间,以便对日后工作做一个计划)、4。记录测试问题总结等(对问题归类总结,时间长知识库、日后需要加强学习和注意的地方)】

7. 测试人员应该把需求变化当作是一种项目常态,平常心应对。任何项目要想安装预期规划发展那几基本上是做不到的,所以变更将是我们工作中的一个常态。

时间: 2024-10-18 16:27:18

测试人员遇到不断变化的项目需求该如何应对?的相关文章

测试人员为什么要深入到项目实现中去?

(“马蜂窝技术”公众号原创内容,ID: mfwtech) 一个项目从需求确定到最后上线,通常来说流程是这样的: 「测试」作为一个项目质量保证角色,在上面的整个流程中均有参与.而用例设计.项目测试环节更像测试的主场,PRD 的评审测试人员也会发表很多自己的观点,对项目的技术评审虽然测试人员也有参与,但也不如前两个环节的参与程度深. 其实,一个优秀的测试人员应该深入到项目的每一个环节中去发现问题,提出自己的观点,保证项目质量.那么要真正深入到项目实现中,测试应该怎么做呢? 一.Review 接口定义

软件测试-测试人员相关能力需求

测试人员相关能力需求: 测试需要发挥其主动性: action:产品面向用户,从需求阶段开始需要介入,明确每个需求的意义,确切的说要比需求分析师更了解对应的需求在产品中的使用 关注前期的需求分析和讨论 参与需求评审 target:根据产品需求合理的设计测试方案和安排测试时间 测试用例设计: 注:用例是指导测试工作,也是测试人员必须工作. action:测试维度:业务,用户,方法 形成用例管理,测试用例评审,后期执行中不段更新维护 关注测试流程: 项目进度把控:协助经理把控项目 缺陷跟踪,针对遗留缺

【转】测试思考——测试人员需要具备哪些素质?

之前写的文章,今天分享出来 测试人员需要具备哪些素质? 测试人员需要具备哪些技能? 软件测试知识:测试计划.测试方案.编写用例.提交bug.跟踪bug,编写测试报告 测试工具的使用 操作系统 编写代码的能力 数据库知识 业务知识.网络知识. 除了这些必备的技能,我们还需要什么样的素质呢? 一.主动沟通    过去我是做传统ERP软件的测试,因为ERP软件已经很成熟,所以他的需求文档一般也都很完善,很细致,需求变更也不会太多.所以我们完全可以按照需求文档进行测试,与开发电话沟通就OK,只要我们bu

机房收费系统——项目需求说明书

不管是学习什么材料,还是初步了解一个系统的时候,想学习新东西,听到最多的就是要了解需求,如果需求理解偏差了,那你的系统将变的面目全非. 软件需求说明书 1引言 1.1编写目的 需求分析人员与用户进行多次的需求分析调查后,提出的一份比较详细的软件需求说明书,这份说明书可以表现出软件的功能.性能.开发条件等 并且在文档完成之后需要用户进行阅读,看是否将需求表达完全,进而补充说明. 本文档的预期读者有用户.项目管理人员.文档编写人员.需求分析人员等 1.2背景 说明: a.  待开发的软件系统的名称:

关于全功能团队及测试人员的发展

这两天部门内部在讨论全功能团队的相关东西,希望后续能慢慢的实施起来.这里全功能团队的概念,简单来说就是希望能够减少团队的规模,加快产品交付的节奏,类似于敏捷开发模式中的小步快跑,能够频繁的有版本上线运行.总体方向来说是好的,这套东西很多互联网公司也玩的很顺畅,但是在华为,最起码在我所在的部门内,还非常缺乏这方面的积累和氛围.整个研发的运作模式和管理层都是从传统的运营商转型过来的,团队庞大,低效,笨重...等等一系列的缺点. 关于这种团队模式的优缺点,如何根据自身的项目实际来运作,以及在这种模式下

开发人员与测试人员的那些事

关于开发人员和测试人员的关系,人们阐述了很多,讨论了很多,争论了很多.而貌似一旦这两者坐在一起,对峙便开始了,两者间的争论多于相互认同.显然,这不利于实现两者合作的目标——向用户提供价值.(推荐学习零基础学习软件测试基础篇) 下面我们来分析一下其中的原因: 史前时期 在最开始,不存在测试人员, 只有开发人员.软件开发人员和软件项目的其他人员比起来并没有特别大的不同.从经济角度考虑,专门成立测试人员是行不通的:开发软件的时间如此昂贵,为测试人员分配时间显得很浪费. 没有专门人员检查工作,软件开发人

51Testing专访史亮:测试人员在国外

不久前,我接受了51Testing的访问,讨论了软件测试的一些问题.以下是全文. 1.史亮老师,作为我们51Testing的老朋友,能和我们说说您最近在忙些什么吗? 自2011年起,我加入Microsoft Office部门,参与了Microsoft Office 2013的研发,主要工作是测试Windows版本的Office产品.目前,我正参与研发下一代的Microsoft Office,主要工作是测试产品和开发测试辅助工具. 今年,我的新书<软件测试实战>问世.这本书基于一个很朴素的想法:

您不是专业测试人员的10个理由!

为什么测试人员在某些组织中没有得到专业治疗. 你是专业测试员吗? 如果您在空闲时间阅读与质量保证相关的文章以提高您的测试技能,那么您将成为确定为专业测试人员的小型(并且希望增长)工程师. 在镜子里寻找答案 说实话,无论我们不被视为(测试)专业人士,我们都没有优先考虑像专业测试人员那样行事. 基于我有限的经验,无论我在哪里看到测试人员认真对待他们的工作并努力提高智慧,我还看到他们如何受到尊重以及他们的工作如何受到赞赏,这归功于它为本组织带来的价值. 所以说到这一点: 您不是专业测试人员的10个主要

测试人员如何把控项目进度

项目背景简介 项目代称 K项目 项目成员 6人(1个测试猿的窘境:  1.需求文档不明确?  2.提测时间不明确?  3.项目进度不明确?  4.我是谁?我该干嘛?  想必每个测试猿都会遇到以上的窘境,版本到项目快截止时才提测,最后项目延误了,又要默默的背锅?  项目进行了半个月,依然没有我什么事儿,我真的不想国庆加班啊,去年就已经安排了今年的国庆节行程,怎么可能延误,必须要改变现状了··· 一.主动沟通,抛出问题 主动找研发经理沟通,抛出问题,提出解决方案:迈出这一步我也是三思而后行.  1.