这个转变其实对测试人员来讲还是不错的。反正转变这件事情，转了之后你需要考虑的无非就是三点。 第一点就是软件层面，你首先需要去了解你做BA或者需求分析，大家都是常用什么软件来管理需求的，有哪些常用的系统等等。 第二点就是软性技能。比如你的沟通，理解能力，亲和力等等。这些你在做测试的时候基本上是得不到锻炼的。 第三点就是硬性技能，比如需求怎么整理，产品数据怎么分析，怎么去燥。怎么深入理解需求，很多时候深入理解需求还是要通过架构甚至代码来得到的。
无论是测试还是开发，总归是属于技术为主的领域，这两种分别都有直属的上升层面比如各自的主管PL、QA等等，这种都还是在技术领域内。 软件测试转需求有几个优势也是开发人员不具备的优势，首先测试人员应该是仅次于需求人员对于本公司业务知识和专业领域的了解，另外测试人员根据其工作的特性，对于细节的把握好，考虑的方面更加全面，具有多线思，在这一点上和需求分析师也是吻合的。 测试转需求也并不是一定好转，首先你要有专业知识的底蕴，然后你要具备比较强的沟通分析能力，毕竟要和客户沟通，第三，文字书写的能力，这一点上直截了当的说就是对开发和测试，相比你很清。
首先，了解产品业务。业务才是根本，不了解业务才能有效的将客户需求转化成开发要实现的模块。 其次，熟练使用产品，对产品的熟悉程度，决定你对需求深入分析的程度。 第三，善用工具，原型图怎么画，交互设计怎么实现，需求管理工具用哪个好？excel玩转了么？Visio封神了么？xmind怎么玩出花样？axure难道只能傻瓜式么？ 第四，善于沟通。既要能够准确精炼的表达自己的想法，又要能够快速响应他人的想法。 第五，技术能力，要能够用技术打压企图zaofan的开发，还要能用更专业的术语让客户觉得你很专业。 第六，会做人。跟各个部门打交道，不会做人全是闭门羹。
软件测试（英语：Software Testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
软件测试是伴随着软件的产生而产生的。早期的软件开发过程中软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证(SQA)的主要职能，包含软件质量评价的内容，Bill Hetzel在《软件测试完全指南》(Complete Guide of Software Testing)一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。”这个定义至今仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。
软件测试做需求分析我觉得是从技术到业务的一个转变，首先最好在做项目的时候逐渐积累一些业务知识，不至于上手时对一些名词不理解，其次也要总结下现在做测试的一些经验，尤其是测试时的关键技术知识，比如集成测试，压力测试并发测试等等，这样你可以把这些经历在以后做需求分析的时候都能考虑到，还有就是沟通，能把你的想法清楚的表达出来。最后重要的事情说三遍，学习业务，业务，业务。
软件测试在需求分析阶段，测试人员要做： 1.理解需求，参与审核需求文档 2.理解项目的目标、限制，了解用户应用背景 3.编写测试计划 4.准备资源。
