作为IT行业的一员,不论从事什么岗位,产品、开发或测试,项目实施中,大家都可能被问以下这些问题,相信你一定也有同感,下面谈谈当你被这些惊魂之问环绕时,可以做些什么。
★
被嫌弃
★
写出一份优秀的需求文档,以产品经理的本领,不算是一件困难的事情。但实际项目过程中,需求写得太简化,变更太频繁,开发和测试的抱怨和投诉会接踵而至,产品经理这样的经历一定不会少。
1.需求就这么两句话?
需求调研不可省:项目经理想要把需求分析全面,初期可以采用“访谈式”沟通,通过访谈、问卷调查、调研会等获取业务真实诉求;中期可以“诱导式”演示,通过原型演示等收集业务反馈意见;在上述阶段成果基础上,可以通过“确认式”评审与业务进行达成一致。
文档模板标准化:好的需求说明书模板可以帮助产品经理将需求分析得更完备,特别是容易遗漏的非功能性需求,如安全性需求、性能需求、报表需求等;项目过程中,可以根据反馈意见和常见问题,对模板进行持续升级。重要的事情是模板制定后一定要使用。
需求评审有底线:需求文档是开发、测试阶段最核心的输入之一,开发和测试人员在参加需求评审时,针对需求描述不完整、有歧义、一笔带过的现象,主动提出评审意见,避免实施过程中自己对需求进行猜测和加工,带来各种返工。
1.这么简单的功能也出错?
3.这个BUG为什么测不出来?
这一定是大多数测试都最怕遇到的灵魂拷问,漏测虽说是测试心中永远的痛,但只要不回避问题,不急于撇责甩锅,就是优秀的测试。
漏测分析第一步:遇到生产问题,测试最先做的是第一时间组织测试复现和漏测分析,使用根因分析方法(5WHY、鱼骨图等)分析各个环节存在的问题,制定相应改进措施,不断反省改进,才能提高。
测试案例最核心:测试人员在案例设计中做到全覆盖各业务场景是防止漏测的关键。我们遇到最多的漏测原因就是场景覆盖遗漏,这里推荐使用思维导图的方式对业务场景的各个分支进行梳理并有针对性地设计案例;同时,要设计相应端到端测试案例,避免多个单场景测试时通过,但多场景多系统组合串联时就会出现问题。
测试执行是保障:成功的测试离不开有效的执行,同样的一组案例,在不同的测试人员手中,测试结果应是一样的,实际上多数会存在差异。可能体现在发现BUG数、BUG单闭环跟进、回归验证等多个方面;测试执行做得好离不开一个词就是“严谨”,预置条件、测试数据、测试环境、测试步骤、预期输出等测试执行活动都离不开“严谨”,一切“勉强凑合”“得过且过”的行为都不该出现在测试过程中。
优培东方送你一张WBS词典:
项目名称: 准备日期:
工作包名称: | WBS编号: | ||||||||
工作描述: |
|||||||||
里程碑: 1. 2. 3. |
到期日: | ||||||||
编号 | 活动 | 资源 | 人 工 | 物 资 | 总成本 | ||||
小时 | 单价 | 合计 | 数量 | 成本 | 合计 | ||||
质量需求: |
|||||||||
验收标准: |
|||||||||
技术信息: |
|||||||||
合同信息: |