最近有个问题,新的项目下来,首先有个需求讨论会,对用户提出的需求进行分析,包括用户也会参加,面对一份用户提供的需求文档,对于研发人员来说,他们看完后会有很多疑问,有需求不够详细的地方,不过都是开发中的一些实现方法,只要这些解决了,开发人员明白了就可以做出设计,而后编码,而测试人员面对需求文档时,我却不清楚要做什么,除了了解需求,知道有什么功能外,还要从哪些方面考虑啊,目前的状态只是想设计页面出来才能有建议出来,还请高人指点一下,谢谢!
另外,用户的需求文档是不是要具体到每个输入框输入多少字,也就是说,这些具体的需求是由用户来定还是由开发人员来定啊,谢谢!

我认为了解需求文档可以用到测试计划和测试方案中，比如像知道系统的规模就可以预测需要多少人力资源等

同意楼上的说法
但是在需求讨论会中,主要是功能的实现问题,别人都在七嘴八舌的说着自己的观点,而作为虚拟用户的我们却在一旁边沉默,其实我们也在了解,也在听,但是总觉得缺少点什么,或者是我们还可以做什么呢

我们公司参加需求研讨会时，把需求说明书中，不详细的问题在会上提出来，本着用户至上的原则，尽量功能上与用户的需求保持一致

那意思就是说在需求讨论会上,测试人员与开发人员的工作都是相同的喽

我觉得需求讨论会上应该用你作为测试工程师的经验
对研发人员提出的实现方法作出评价和改进的建议
例如
针对客户的需求，研发人员选择了a方法来实现
但是你在以前的测试工作中发现a方法在测试环节中比较难以把握安全实用性，或者花费的时间较长
这时你要提出这个问题，以协助的身份来探讨是否可以换一个功能一样但更节省时间，更好控制风险的方法b。

毕竟研发人员看重的是如何实现，我们更关心的是使用，安全，稳定和时间的比值。
我也是刚做测试，希望自己的理解对你有些帮助

同意,你这样一说到是有些眉目了,那么我也应该引导研发人员去说出他的实现方法,因为我们现在的需求讨论初步大部分都是确定有什么样的功能,然后研发人员再设计页面,然后在进行讨论,听你这样说心里有底了,呵,谢谢!

支持

不用客气，大家互相帮助，都一个圈子的，没准哪天还是同事呢
但你要注意和他们沟通的方式，观察他们每个人不同的脾气和性格，不方便会上沟通的，可以私下沟通
让他们觉得你是在帮他们，而不是要替代他们主导会议
要学着和研发的同事交朋友，这样对工作有好处
毕竟如果你不主动让他们来了解你的工作，现在大多数人都不是真正了解测试的
祝你好运气