我们常说测试人员要有用户思维，用户思维怎么来？
其实很多时候，用户自己也不知道到底想要什么，更遑论将想要的功能准确清晰的描述出来。从根本上来说，他们只是希望服务商能开发出某个功能，解决自己目前所遇到的问题；更甚至有些功能用户也没有想到，直到我们开发出来他才惊觉这样好用！（后者也是我们常说的创新，这样的功能，要么应做成产品宣传亮点，要么支持用户引导，要么就做在用户极易操作到的位置。）
在这样的背景下，我们要想站在用户的角度去思考，就必须先明确以下几个问题：
1.目标用户是谁？内部使用还是推向市场？
2.用户核心诉求是什么？希望解决什么问题？
3.调研目的是什么？了解用户行为，还是别人有的我都要有？
只有知道目标用户是谁，我们才能假设场景，思考用户可能遇到的问题；只有知道用户核心诉求，我们才能避免理解出入，一次性提供用户满意的软件。
但现实是，面对一个需求，我们基层测试人员对目标用户，需求背景，需求价值，都是一无所知的，甚至连需求负责人，也只是看着别人有，就要求我们也做成这样，其提供的需求文档中所谓的临床意义，都是千篇一律的复制粘贴。
需求评审虽然会有，但需求评审及后续需求确认中，往往我们问的更多的也是，A功能具体应该怎么实现？进入A功能后是否支持B功能？A功能应不应该支持B操作等细节问题，很少会去问，为什么要做这个功能？
其实我有问过几次，如果是一手需求负责人，一般是能解释原因的，这样的功能问题确认频次会降低很多，后续返工或产生偏差的概率也很小，但对于一些因人员变动交接出去的需求点，现任需求负责人也是凭空猜测，不知晓背景；再者，如果需求点多了，一条一条去问为什么要做，对双方也是一种时间和情绪消耗。
有没有好的办法解决？目前的一个想法是，部门间进行协同，用户需求文档中，要求主要体现需求点背景及需求点目的；开发需求中，要求主要体现需求点的具体细节及实现。
网友评论