功能测试人员如何转需求岗讨论

                     功能测试人员如何转需求岗讨论

    昨晚部门一哥们请吃饭，也宴请了部门几个兄弟姐妹一起吃饭，吃饭闲聊过程中，他们问到后面的职业规划问题，说想转需求分析，但是不清楚怎么做，我的观点是功能测试人员转需求，一看自己的恒心、决心、坚持、还有平台、以及导师引路，自己领悟。其实很简单，做为一个刚工作两三年的功能测试有这想法我真心喜欢，我们部门确实有很多同事跟我之后，慢慢受我影响，不会受外界**，能专心静心研究一门技术，例如现在我们部门有部分人员在业务需求分析、业务解决方案编写实施方面有自己的建树，成为各大开发部门争抢的人才，这也说明我的弱势，管理制度问题，我只能怨愤服从，她们自己没办法培养就通过管理漏洞抢人，不过我心里值得安慰的是，她们培养不起来的公司急需的业务人才，我这边都有也能培养，而我自己也是公司性能故障处理方面专家，自吹一把，我是因为工作时间长，十几年长期流转各种不同类型项目性能故障诊断分析优化，一直做这块通过经验解决各类生产性能故障，也兼职帮一些企业解决生产故障问题，算积累成精，不然我智商不行，天赋一般，而我们部门几个她们在工作七八年后，能走到这一步她们的天赋明显比较高，也肯学，听话，毕竟金融行业水深业广， 也说明我的培养管理有方?，当然我培养最多的是一些性能测试人员最终离职成为其他公司的部门经理或者上市公司的性能技术专家，霸气下自己大兵 。

    先唠嗑下，饭局中我是怎么跟他们说如何自学转需求分析，一般 一个测试人员在一个系统做功能测试一段时间接触最多不是一整块需求分析，而是零碎的需求分析然后在进行案例分析测试。而听到最多的抱怨是，业务人员“一句话需求”，搞得开发人员和测试人员理解存在歧义，最终发生缺陷，找业务人员理论确认是否是需求问题还是开发问题，其实就是“一句话需求”引发的“血案“，说现实点就是业务人员非需求人员，这方面不够专业，而做为需求人员就要把这句话转化成系统功能需求，或者如果是产品经理就要想办法把自己的想法转化成系统功能需求。做为测试人员最多的是把需求分解成测试范围，假如你想后期转需求，可以牺牲时间，先研究系统功能业务点，自学 AXURE,然后碰到这种一句话需求时，把这句话 分解到各场景，和用例里面。例如，业务人员邮件说“系统查询功能使用麻烦，想在查询后面添加清楚查询内容，避免查询后想要查询新数据，还要删除旧数据，在输入”，其实就是类似“重置” 按钮。但是开发人员接到需求后，就根据自己的理解 添加按钮，有的是“清除”、“重置”等名称五花八门，最终提交测试时，发现名称不一致、按钮有的放，查询后面，有的放页面最下方等等。这就是专业度不够导致“血案”，假如功能测试人员真心要转需求工程师，可以把这句话需求，利用时间写成这样：

正确的描述应该是：

     前置条件：系统各页面查询功能 后添加“重置”，点击“重置”，功能变成初始化状态

     预期结果：用户在查询控件输入查询内容后，在点击“重置”按钮，查询输入数据被清空。

     用例场景： 哪些查询页面交易功能，都要新增 该功能，如下：。。。。。。。。

     然后画一个原型图，让开发人员参考，这算是摸住需求的皮。

   这样慢慢的，公司接受你的做法，也知道你有这方面的能力，能了解该系统的功能细节，也肯花时间提升个人能力，为公司做贡献，会想办法留住人才，培养人才，当然最重要的是员工要有自己的合理的能实施的想法，也能担当责任才行。