测试小故事24:寻找需求的真相
2017-04-18 23:36
253 查看
经典的需求理解图示。
相同的需求,不同的人理解各不相同。
是什么造成对于需求理解的不同:行业知识、行业背景、工作的环境、生活的经历、问题的痛点、思考的方式。。。。。。
面对需求,林林总总的不同,造成了不同人对于需求的描述、原型设计的不同。
面对需求,有你理解的一面,有我理解的一面,更重要的是有真实需求的一面。
软件开发过程中,面对需求的问题争议存在一个特殊的角色:仲裁,也就是对需求进行最终确认和拍板。
软件开发过程中,开发与测试之间的争执总是聚焦于:
1.是不是BUG?
你说是BUG,我理解的不是,需求说了算。。。对不起需求的真相在被不断的描述中已经变异了
2.BUG要不要改?
你说改,我认为不影响不需要改,需求说了算。。。需求的真相还没有被真正的描述出来呢
无论怎么解释,判断的依据依旧是:需求。
需求有哪些?显示需求 + 隐式需求
依图不难发现,显示需求的理解尚且会有不同的描述,何况隐式需求呢?理解不同造成评判标准的不同
既然需求这么不靠谱,软件开发过程又能做什么呢?总结一句:
破解需求理解的不同,我们需要的不仅仅是信息量,不仅仅是沟通,更需要多维度的思考和观察。
1.理解和明确原始需求的真相。锤子和凿子的需求并不是锤子和凿子本身,可能真正的需求只是最后凿出来的那个洞。知道了真正的原始需求后,实现需求只是手段和方法的不同。
2.针对不同的角色用专业的语言描述需求。对客户讲需求用行业语言而不是讲C++、JAVA或是操作系统、数据库,对开发讲需求用设计、模块、MVC的模式讲解,而不是用高深和专业的行业语言。真正靠近不同角色,用行业形像化的思维才能真正讲通需求。
3.用不同的方法、不同的方式描述需求,寻找描述间的漏洞,不断修正。日常沟通中,当彼此不理解或是出现偏差时,最好的办法就是从不同的角度重新描述问题,直至彼此达成一致。 Let's us check it again.
相关文章推荐
- 测试小故事20:停不下来的需求变化
- 一款很好用的,免费的外网映射工具Ngrok 国内版,可以满足基本的开发测试需求
- 用Rational工具管理中小项目需求与测试
- 论测试人员为什么需要参加需求评审
- 在 OpenStack 云中测试 Fedora 24 Beta
- 自动测试如何选择自动化测试框架_机器擅长回归测试,人类善于寻找Bug _Pekka Klärck
- 独立思考者模型:寻找潜藏在表象背后的真相
- 从需求到测试
- 测试小故事55:软件测试悖论
- Python:实用抓图工具开发介绍(含需求分析、设计、编码、单元测试、打包、系统测试、发布各环节)
- RUP测试过程实践之测试需求与测试用例
- 外挂辅助技术-分析任务等级需求并测试
- [原创]如何寻找软件测试职位
- 需求不明确情况下如何建立测试用例
- 测试的首要条件----明确需求
- 如何在需求不明确的情况下保证测试质量
- 如何根据需求设计测试用例
- 寻找以下公司的实际控制人。有合作需求。
- 24_Shell语言――――if条件判断之字符测试
- HBase0.94.2-cdh4.2.0需求评估测试报告1.0之二