因为之前测试有活，就开发和产品先开了

测试参与需求评审可以更早的理解需求，然后开发在开发功能的时候测试人员就可以着手去设计测试策略和用例了

要么一起开，要么先比开发早一步开，测试在评审更大的作用是完善需求

可是什么样的需求是看文档看不明白的呢？有必要牺牲测试的干活时间吗

新需求的完善是要靠测试来完成？这点我真是不太理解呀

这种 还是要一起开才行

我甚至觉得测试没有参与的必要

让开发自测最好

最好的方式：

step1：产品 + 开发 + 测试一起搞下需求宣讲。
step2：开发拉测试，产品过系分（如何实现需求的设计文档）
step3：测试拉开发，产品过测分（如何测试）

为了更好的验证开发确实按照产品的文档或者陈述去实现需求。
首先，信息的传递容易失真，早期测试介入，容易把控需求的完成度；
其次，开发的惰性，你不早点介入跟踪开发的进度，很大可能会遇到开发偷工减料、微变更需求、为了方便提交不可测试代码的情况，这时候带来的工作成本更高；
然后，测试左移，这个概念是鹅厂某分享主题，从需求层面发现 bug 或者不合理性，减少不必要的返工，也是提升效率的切入点；
最后，个人拙见，多了解点产品特征也没啥不好的，反正我每次参加这种会提出一堆问题，觉得自己这个测试的存在感很强，工作认同度也好多啦

测试有事，那是你们自己的责任，不赖流程

个人拙见~
1.需求评审会议应该是产品，开发，测试一起参与的，这样有利于测试清晰整个产品的架构和逻辑，以及可以评估下风险，对自己设计和编写用例有很大的帮助。
2.如果情况是测试有事没参与需求评审会议，那会后只需要给确定下来的需求文档到测试即可，并不需要再跟产品开多一次会，纯属浪费时间。测试对需求文档有疑问的地方，可以先记录下来，再找个时间跟产品确认即可。
3.我觉得你公司在需求评审会议时有要求测试参与，这点可以看得出公司对测试有一定的看重，而这个会议的质量得自己去把握，有的人喜欢别人直接告诉他怎么做，他就怎么做；有的人喜欢参与别人的讨论中，一起开启头脑风暴。至于利弊，我想你心里也应该有个数吧~
4.我从你的文字中看出了你的急躁，也看出了你似乎很忙碌？或许可以说是一种效率不高的表现？如果我说错那我道歉哈~其实你大可不必这么忿愤，每件事都有它的意义，耐心一点也许你会发现其中的好处，如果一点好处都没有，那就当做是放松自己咯~
希望对你有些帮助~

个人认为：测试肯定是需要参与需求评审的，只看文档 能了解所有的需求吗？
能了解到需求的细节吗？ 测试参与需求评审，可在评审过程中更加深入的了解需求，对需求提出一些建议或者意见
按照 LZ 的思维，那产品为什么要和开发评审呢？看文档不就可以？
最后个人认为。。。评审会议还是一起开比较好。。。

问题来了，为啥不是测试，产品，开发一起开需求评审。

关于是不是鸡肋，我个人认为非常有必要。 首先测试，开发，产品在需求评审会上，每个角色都会根据自己角色出发去考虑需求是否合理，站的角度不同， 再来测试其实往往是最熟悉产品功能的人，往往可以发现需求很多问题，最后磨刀不误砍柴工，越早发现问题，fix 的成本越低。

开发要做的是怎么实现需求，对业务的理解能力不如测试。测试参加需求评审可以提供更好的建议，也可以发现需求期隐藏的 BUG。
但是听你的说法，你们更像是产品在给讲需求，而不是做需求评审。

题主的想法好奇怪啊。别的人都是抱怨测试不被重视，需求或者变更总是最后一个才知道。导致有漏测或者临时的加班

你怎么是调过来的？觉得产品找你对需求反而是负担。。

当然，如果是资源很少，不想用开会这么重的方式，可以跟产品提意见，在工位简单过一下也是可以的。不至于这么吐槽吧。

测试什么会都不参与，只看文档测试，就不怕背锅吗

不是抱怨啦，只是我觉得当测试的话语权不足的时候，这样的方式是不是值得探讨，还有如果一定要让测试来背锅的话，其实跟测试有没有参与评审会是木有关系的~

目前我们也是这样的模式：
1、产品和开发过需求的会议，是让开发评估需求的可行性，其中还包括实体和数据流转的细节。
2、可行性会议通过后，产品需要按会议结果修改然后发布需求。
3、在需求发布出来后，测试需要看需求&理解需求。这时候分为 2 种情况：
a、需求文档足够详细，测试可以直接按现有需求文档写用例；
b、需求文档存在细节的疏漏，测试需要汇总然后发布给产品/开会讨论，让产品完善需求。
产品修改的需求都需要邮件通知给开发。
c、需求存在设计疏漏（毕竟测试是最了解现有系统的人），这个时候产品、开发、测试都需要开会讨论了。
在会上定下来最新的需求。

测试需求也是测试工作的一部分吧？
“测试只负责保证是否按需求实现”——你这个观点就是个伪命题，一个系统工程，怎么可能简简单单的就是分工？把需求疑问点消灭的初始阶段，这是需要整个软件工程参与者都参与的事情。

正因为测试话语权不足，才需要多多参与。不参与，别人怎么知道你测试厉害呢？

你能在开发产品测试一起的会议中，查漏补缺，力排众议，久而久之，你就是事实上的业务专家。

如果什么都不想参与，只想干好自己的活，何来话语权的提升。非职权的影响力就是要依靠这种

团队的日常交流共同的场合，一步一步建立的。另外，我表达的意思是多沟通，是可以减少背锅的哈。不是

说你参与了会议就不用背锅了

约莫你是没学过软件工程，你觉得需求谁都看得明白，是压根儿不知道大家思想上和理解上有多大差异

适应公司的文化就好，有些流程并不通用，毕竟是打工的只能提提意见，别太纠结。

你这个观点比楼主的还要让人觉得无厘头，消极到家了

并没有消极啊~~只是让人看开点，这种流程的东西不用太纠结，有时间多看看技术类的东西。

正常且灵活的流程，是产品 + 开发 + 测试一起需求评审。

哈哈哈，这个说法可以的！

难道不是一起开需求评审么？

@taflo 如果你以后职位能有上升的话，回头看估计你自己都会鄙视你现在说的话~
测试如果都这个心态的话，地位低真心怨不了别人。
目前团队里测试就是需求评审不提意见，一头包。

话不要说这么满。仔细想想谁是最应该也最有时间去调研需求？评审提意见有时间有精力当然要搞，但评审完就一定没问题？然后就有评审规则，标准等等出来。还是那句话有时间有精力当然要搞。
最后说一句在一个公司地位高低和你在什么团队是什么职位 “没有关系”，就看你为其他同事们（包括老板）能提供和提供多少服务而决定的。

讲得很中肯