测试人员如何应对需求变更(转).docx

测试人员如何应对需求变更(转)

第一篇：测试人员如何应对需求变更(转)需求频繁变更这个产生的主要原因是：1.前期需求调研工作没有做到位，在需求调研时没有真正深入了解用户需要什么东西？用户做这个东西的目的是什么？为什么要这么做？2.项目经理对项目掌控力度够，如果一个项目的需求一定情况向，尽可能避免在短时间里频繁变更，可以采用集中变更或者分阶段变更3.客户在最开始时自己也没搞清楚要做出什么样子？随着系统的成型上线，提出一些新想法等导致需求变更。4.客户就是上帝，所以有些变更时必须的测试人员如何面对变更？1．协调制定变更规范，比如说每次需求人员都会发出变更申请书，这样可以作为开发人员和测试人员工作的依据。如果这点也做不到的话，建议把发给开发人员的变更信息同时抄送给测试人员，使测试人员和开发人员保持信息基本一致2．在每次测试前，一个比较详细的测试测试任务列表单，同时注明本次测试的侧重点【变更哪些需求、新增了哪些需求】，找相关人员确认【可以抄送多人】3．良好的团队合作。对新的改动及时通知对方，短时间内开展最有效的团队协作及时沟通，需求相关人员和开发人员、测试人员做好即时沟通，第一时间知道需求的变更，及时做好测试策略更新。知道的越早对我们的影响越小，需要的测试成本也越低。4．及时整理并记录测试需求变更，在每次不论通过何种方式得到需求变更信息，都要及时记录，以便以后测试5．每天保持记录测试工作日志，主要包括【1.测试中遇到的问题及其解决方式（可以形成测试知识库）、2.记录测试任务及其工作成果（主要是记录今天做了什么？成果是什么？以便以后总结）、3.记录测试进度（记录个人或者团队的工作进度情况；这样时间长了就基本可以评估测试那个模块，那个流程，哪一类问题需要多长时间，以便对日后工作做一个计划）、4。记录测试问题总结等（对问题归类总结，时间长知识库、日后需要加强学习和注意的地方）】6．测试人员应该把需求变化当作是一种项目常态，平常心应对。任何项目要想安装预期规划发展那几基本上是做不到的，所以变更将是我们工作中的一个常态。注：本文转自网络，第二篇：产品经理如何应对非功能性产品需求变更产品经理如何应对非功能性产品需求变更令人烦恼的非功能性需求变更在软件开发中，大家都会遇到过这样的问题：客户的一个新想法，就推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些，毕竟功能性需求不实现的话，是会大大影响到软件产品的质量。但现在我所负责的这个开发项目中遇到的都是一些非功能性的变更,而且许多是看起来无关痛痒的、鸡毛蒜皮的变更。（1）什么是非功能性需求？在IEEE中，软件需求的定义是：用户解决问题或达到目标所需的条件或功能。一般包含业务需求、用户需求、功能需求、行业隐含需求和一些非功能性需求。业务需求反映了客户对系统、产品高层次的目标要求；功能需求定义了开发人员必须实现的软件功能。所谓非功能性需求，是指为满足用户业务需求而必须具有除功能需求以外的特性。包括系统性能、可靠性、可维护性、易用性和对技术和对业务适应性等。其中最常见的是软件界面、操作方便等一系列要求。（2）非功能性需求变更的特点让我们从客户角度和开发人员角度去看看非功能性需求的特点。首先，有些非功能性小需求从客户角度看起来工作量不大，但是实际上开发人员要耗费比较长的时间去完成这些小功能。其次，许多非功能性需求，如界面美观、操作方便等都是客户头脑一热、或领导一拍脑袋就部署下去的需求，往往是原来在需求分析阶段所没有注意的内容。其实，非功能性需求是常常被轻视，甚至被忽视的。原因是非功能性需求描述很困难，它很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚。在描述这类需求时候，我们经常采用软件性能要好、操作要方便、软件界面要美观大方等较模糊的描述词语。例如，易用性就同时涉及到美工和UI界面、人机工程、交互式设计、心理学、用户行为模式等内容。这类描述词语都是脱离了软件的执行环境，是对人和相关的场景的描述，因此很难体现到软件架构设计和具体的实现中。为什么非功能性需求变更会频繁发生？为什么非功能性需求不能固定下来呢？或定下来后就不许变了呢？通常有许多人会问这样的问题。实际上，当他变成了客户时，他可能就不会问这个问题了。（1）非功能性需求容易产生理解分歧在软件需求分析阶段，客户和开发人员对非功能性需求的理解呈现“大体上共识多，细节上差异多”的特点。一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关。即使通过反复沟通，但是以实践经验来看非功能性需求的描述还是永远不够清晰、不够明确的，主要是因为在这个阶段所谓的产品还只存在于大家的大脑构思中。作为一个客户，大多数情况下是不懂技术的，但他所需要的软件在他的心里还是有一个印象的。他会想象出软件的样子和功能，然后通过